Delay between two HTTP requests in a common TCP.flow (between 10 - 30 seconds)

This morning I captured the traffic also on the server. There is the same number of request and response... Also, I can see many retransmission Client Side...

Any iRules involved? What type of Virtual Server please?

 

What tcpdump syntax too please? PVA can sometimes mean you don't get all the traffic which can be very confusing.

 

I have no irules involved on this virtual server. This is an http application runnin on port 80 built with the template "HTTP application" where i changed a few things on the HTTP profile:

 

• Add x-forwarded-for HTTP-header
• No Caching

The tcpdump syntax are :

 

• Server Side (Linux Redhat Server): tcpdump -B 4096 -s0 -ni eth0:nnn 'port 16073 or icmp' -w
• On the BigIP : tcpdump -s0 -ni 0.0:nnn '(host 129.195.246.121 and port 80) or ((host 129.195.112.65 or host 129.195.112.77) and port 16073) or icmp' -w
• Client Side: use of wireshark on windows - no filter

It seems no traffic is lost, but on the client side, i see many retransmission. I tried a few changed on the tcp profile, but nothing thing to help.

 

Great, thank you. Not sure what the :nnn is all about but otherwise looks good.

 

If you only see retransmissions on the client side using Wireshark I will assume these are spurious and probably related to NIC offload or something similar.

 

Can you be more specific about when the delay occurs please? The 10-30s delay is between two requests? Does that mean the client is waiting for a response to request 1 before sending request 2?

 

What browser, what server software please?

 

I'm not an expert in capture explanation, but it seems the delay is between an ack to a HTTP response (200 OK) and an http request. So the client doesn't seems to wait for a response...

 

I tested with chrome, ie and firefox and the result is the same.

 

After a few more try and some difficulty to read the tcpdump capture from the BigIP, it seems only the response received on the client capture has some delay.

 

So, on the BigIP and the server, the request and the response are fine, but on the client, i see a delay of 10-30s.

 

Also, on the bigip, the capture is very difficult to read as some part seems to be missing. On some capture, wireshark doesn't understand or translate the HTTP response (200 OK), but if i look at the multiple TCP packet, i can see the "200 OK" anyway...

 

Depending on how much content is downloaded and the bandwidth available between the F5 and the client, there will be a delay in seeing the HTTP response on the client. It may take 10-30 seconds for the response to get to the client, so the client will see a 10-30 second delay.

 

If you are using a port other than 80 for HTTP traffic, Wireshark will not interpret the traffic as HTTP and thus will not show HTTP request/response. In Wireshark you can go to Edit/Preferences/Protocols, then select HTTP and add what ever ports you are using for HTTP traffic. I am assuming you are using 16073 since this is one of the ports you are capturing traffic on.

 

As i told in my messages, the content is pretty small (17KB for example). On chrome or Firefox, i can see the transfer of the small packet taking a long time. If i access the application directly, it goes well.

 

About wireshark, the client side is using port 80. also, wireshark seems to decode well the traffic on port 16073 as http, but it seems some packet are not complete.

 

17KB would be more than one packet, more like 10 or 11. I'm still rather confused about when the delay occurs, from a TCP perspective. Rather than go round in circles with that lets just do a general check.

Firstly, can you confirm what TCP profiles you are using on your Virtual Server and whether they are set to default settings or not. Also confirm that Nagle is turned off.

Secondly can you check the MTU configured on the VLANs involved and let us know.

Thirdly, can you do a ping from the client to the Virtual Server using a 1500 payload size. In Windows this would be

ping -l 1500 x.x.x.x

. If that doesn't work, keep dropping the size down by 20 till it does. Obviously, note if the time is excessive.

If would also be good to do the same from the server to the F5 if possible?

To answer all the question :

 

• The TCP profile are the one by default (BigIP version 10.2.2 tcp_lan_optimized)
• The mtu configured on the vlan for the bigip is 1500
• The naggle algorithm is disabled
• The ping from the client or the server are fine with option -l 1500 (client side) or -s 1500 (server side - Linux redhat)