Understanding tcptraceroute versus http response

Posted by kojiro on Server Fault See other posts from Server Fault or by kojiro
Published on 2013-10-18T15:11:37Z Indexed on 2013/10/18 15:56 UTC
Read the original article Hit count: 252

Filed under:
|
|
|

I'm debugging a web server that has a very high wait time before responding. The server itself is quite fast and has no load, so I strongly suspect a network problem. Basically, I make a web request:

wget -O/dev/null http://hostname/
--2013-10-18 11:03:08-- http://hostname/
Resolving hostname... 10.9.211.129
Connecting to hostname|10.9.211.129|:80... connected. 
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘/dev/null’

2013-10-18 11:04:11 (88.0 KB/s) - ‘/dev/null’ saved [13641]

So you see it took about a minute to give me the page, but it does give it to me with a 200 response.

So I try a tcptraceroute to see what's up:

$ sudo tcptraceroute hostname 80
Password:
Selected device en2, address 192.168.113.74, port 54699 for outgoing packets
Tracing the path to hostname (10.9.211.129) on TCP port 80 (http), 30 hops max
 1  192.168.113.1  0.842 ms  2.216 ms  2.130 ms
 2  10.141.12.77  0.707 ms  0.767 ms  0.738 ms
 3  10.141.12.33  1.227 ms  1.012 ms  1.120 ms
 4  10.141.3.107  0.372 ms  0.305 ms  0.368 ms
 5  12.112.4.41  6.688 ms  6.514 ms  6.467 ms
 6  cr84.phlpa.ip.att.net (12.122.107.214)  19.892 ms  18.814 ms  15.804 ms
 7  cr2.phlpa.ip.att.net (12.122.107.117)  17.554 ms  15.693 ms  16.122 ms
 8  cr1.wswdc.ip.att.net (12.122.4.54)  15.838 ms  15.353 ms  15.511 ms
 9  cr83.wswdc.ip.att.net (12.123.10.110)  17.451 ms  15.183 ms  16.198 ms
10  12.84.5.93  9.982 ms  9.817 ms  9.784 ms
11  12.84.5.94  14.587 ms  14.301 ms  14.238 ms
12  10.141.3.209  13.870 ms  13.845 ms  13.696 ms
13  * * *
…
30  * * *

I tried it again with 100 hops, just to be sure – the packets never get there. So how is it that the server does respond to requests via http, even after a minute? Shouldn't all requests just die? I'm not sure how to proceed debugging why this server is slow (as opposed to why it responds at all).

© Server Fault or respective owner

Related posts about networking

Related posts about routing