This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Weird issue HTTP

0

Hi wireshark support

Our customer encountered a strange problem when communicating with HTTP to a website. The website is www.yano.co.jp

When accessed from client enviroment it takes exactly 21seconds till 200 OK comes back. Any other site loads very quickly.

We took a packet capture and saw an exactly 21s delay between the server ACK and server PUSH packet. 21 seconds delay

565 14.783319000    157.7.166.61    172.16.0.82 TCP 54  80→60242 [ACK] Seq=1 Ack=485 Win=6912 Len=0
714 35.117559000    157.7.166.61    172.16.0.82 TCP 492 [TCP segment of a reassembled PDU]

Whole communication

546 14.686363000    172.16.0.82 157.7.166.61    TCP 66  60242→80 [SYN] Seq=0 Win=65535 Len=0 MSS=1360 WS=256 SACK_PERM=1

554 14.728453000    157.7.166.61    172.16.0.82 TCP 66  80→60242 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=4


556 14.728758000    172.16.0.82 157.7.166.61    TCP 54  60242→80 [ACK] Seq=1 Ack=1 Win=262144 Len=0


562 14.729638000    172.16.0.82 157.7.166.61    HTTP    538 GET / HTTP/1.1


565 14.783319000    157.7.166.61    172.16.0.82 TCP 54  80→60242 [ACK] Seq=1 Ack=485 Win=6912 Len=0


714 35.117559000    157.7.166.61    172.16.0.82 TCP 492 [TCP segment of a reassembled PDU]

What could be the reason for this delay ?

This 21s delay is only for this site and only from customer enviroment. The site can be accessed quickly from another internet line.

Also we accessed the site from the nearest L3 device with telnet 157.7.166.61 80 and saw the same 21s delay.

What could the cause for this exaclty 21 seconds delay between ACK and PUSH ACK.

Thank you for the support.

asked 02 Feb ‘15, 02:43

AdiA10's gravatar image

AdiA10
6●1●1●2
accept rate: 0%

edited 02 Feb ‘15, 03:18

grahamb's gravatar image

grahamb ♦
19.8k●3●30●206

This is not “Wireshark support”, but we try to help when we can of course. Do you have control over the slow website, or is it outside of your reach?

(02 Feb ‘15, 02:49) Jasper ♦♦

Thanks for the reply.

We don’t have control over the website. We can touch only the client side.

We are suspecting some device in the middle between clients L3 device and the server.

Thanks.

(02 Feb ‘15, 03:44) AdiA10

yeah, problems like this usually show up when there is a load balancer or traffic shaper in front of the actual servers, and something is broken in the balancing process. That way the delay can happen to some connections, but not to others.

Problem is, if you’re not in control of the server side, you can’t do much about it except inform them and have them check.

(02 Feb ‘15, 03:55) Jasper ♦♦

Thanks Jasper.

The strange thing is that every time the delay is exactly 21 seconds.

Any check that I can do from the client side.

Thanks.

(02 Feb ‘15, 04:02) AdiA10

Any other checks that I can do from the client side?

Thank you.

(02 Feb ‘15, 04:11) AdiA10

Not really, no. If there’s just a 21 second gap where the client can only wait you’re out of luck.

(02 Feb ‘15, 04:18) Jasper ♦♦

Thanks.

Can this be relatEd to the tcp_synack_retries parameter ? Server is Apache.

Value Time of retransmission Total time to keep half-open connections in the backlog queue 1 in 3rd second 9 seconds 2 in 3rd and 9th second 21 seconds 3 in 3rd , 9th and 21st second 45 seconds

(02 Feb ‘15, 04:34) AdiA10

I don’t see how the tcp_synack_retries parameter could have anything to do with a delay after a GET request, since this parameter is only relevant to the Three Way Handshake - which is established already when the problem shows up.

(02 Feb ‘15, 06:03) Jasper ♦♦

you’re right.

was tired.

Thanks again for your help.

(02 Feb ‘15, 06:07) AdiA10

sure, no worries ;-)

(02 Feb ‘15, 07:41) Jasper ♦♦
showing 5 of 10 show 5 more comments