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

Why the Massive Delay for HTTP Client

When I apply the filter : ip.addr == 95.1.1.50 && ip.addr ==95.1.1.104,

There is a massive delay shown at packet 2327. I'm really struggling to get my head around this. Could anyone set me in the right direction?

The capture file is at:

https://drive.google.com/file/d/0B6vUPsqTPCf8aFRYMGVuZ0dIa28/view?usp=sharing

Many thanks, JW

delay client http long

asked 17 Dec '15, 05:55

joewoody
6●2●2●3
accept rate: 0%

edited 17 Dec '15, 09:30

grahamb ♦
19.8k●3●30●206

Here's a capture that represents what we would consider "normal" behaviour using the same filter - ip.addr == 95.1.1.50 && ip.addr ==95.1.1.104

https://drive.google.com/file/d/0B6vUPsqTPCf8SmZHMm9Rc2ZEYWM/view?usp=sharing

In this instance, the application loads up resonably quickly. However, we have a server at .87. When we turn this server off this is when we see the massive delays as in the original capture file. Spinning this server back up returns us to normality. Now, there's nothing in the captures to suggest the server at .87 is involved in any way at all. I've captured at the client (.50), appserver (.104) and also the server at .87. As I've said - with the server at .87 turned on, behaviour is normal.

However, with this server turned off and the proxy turned off in the client browser - the application loads normally.

With the server off and the proxy ON in the client browser - this consistently produces a 80-90 second delay in the loading of the application. The proxy server is at .88. Again, and I'm relatively new to this, there's nothing untoward showing in the captures. It appears that the proxy server is somehow interfering - but I can't think why!

Thanks, JW

(17 Dec '15, 14:07) joewoody

2 Answers:

You have to look for the answer at the application level, as everything looks just fine at TCP level.

Frame 2327 contains an initial packet establishing a new TCP session towards 95.1.1.104:8888 (as it contains a SYN flag), and the previous session from the same client has been closed in a normal (i.e. not emergency) way.

What is unusual is that it was the server (.104) who has initiated the closure by sending a FIN flag, quite soon after the session has been used for the last time (in particular, to transport the 304 response to the GET). This might possibly be explained by existence of a very aggressive firewall in the path, which would terminate idle TCP sessions after 5 seconds of inactivity.

It can also be seen that the machine running the client application opens a new session for each request instead of reusing an already existing one, as sessions from two different tcp ports of that machine overlap in time. But this may be because two different instances of the client application are running there, or because there is actually a private subnet with several machines which is NATed to 95.1.1.50. In short, not enough information about the network topology to explain these induced questions.

answered 17 Dec '15, 07:17

sindy
6.0k●4●8●51
accept rate: 24%

Now, there's nothing in the captures to suggest the server at .87 is involved in any way at all.

I dare to disagree with this statement. When you apply a display filter (ip.addr == 95.1.1.50 and ip.addr == 95.1.1.104) or arp.src.proto_ipv4 == 95.1.1.50 on your first capture (...withoutDC...), you can see that 95.1.1.50 desperately needs to send something to 95.1.1.87 (probably a request for some data as well). The .50 starts sending arp requests asking for .87's MAC - first of them is in frame 885, and most of all arp requests the .50 has been sending since getting the 304 response to its GET /forms/java/frmall.jar until sending its GET /forms/java/plumbsicons.jar were for the .87. On the contrary, it is true that in your other capture (...withDC...), there is no exchange between 95.1.1.50 and 95.1.1.87 at all.

So as said, I would concentrate at the application level. I suppose that the .50 needs some information from the .87 to be able to send the GET /forms/java/plumbsicons.jar to .104, but when the .87 is running, it gets that information sooner than you start the capture. So if the .87 is down, the .50 spends the time between the GET requests attempting to obtain that information, and sends the GET /forms/java/plumbsicons.jar only after these attempts have timed out.

It should help your understanding a lot to know what kind of information the .50 needs from the .87. To learn that, you have to capture the .50's exchange with both the .87 and the .104 right from .50's boot. This means that the capture should be taken

either at the .87 and .104 simultaneously,
or using another machine and a monitoring port of a switch (or a tap) "at the .50's cable".

The reason is that as we don't know any details yet, we must assume that the exchange between .50 and .87 may take place already before you would be able to run the Wireshark capture on the .50 itself.

(19 Dec '15, 09:16) sindy

I am suspecting that you are proxying your application to an intermediate devices so that you can analyse the request and response that is being passed between the client and server. Here is a few things that I see from the packet capture,

.50 is a client & .104 is the server
Capture is taken from the client .50
Tcp being closed by the server after 5 secs of inactivity. The idle-timeout looks to be the HTTP keepalive timer.

alt text

From the latency point of view, these test was done from a LAN setup.
I'd suggest that you take two captures (one at the client and another at the server side). This is to make sure that the Acknowledgement that the client sent in fact reached the server.
You will need to know what is expected flow of request & response behavior of this application. Is it that the application server is still processing data while the timer has just timed out? Or, all the expected response is already sent back to the client and the next request didn't go out in a timely manner from the client? What is expected after packet 4561 (after the HTTP 200 is completed -sent by the server)?

answered 17 Dec '15, 09:38

hunghoong
11●3
accept rate: 0%