 | 1 | initial version |
Hey @balcee, Thank you for the captures. Due to the fact that the delay tooks mostly about 15-25 seconds, and the capture itself contains only 20 seconds of traffic, it was a little bit difficult to find a conversation, which outbound (WAN) and inbound (LAN) traffic is included in the capture. But I've found one :)
The file HK_Bluecoat_190520_0845.cap contains a HTTP request from the client 10.88.129.242 for www.gstatic.com in TCP stream 399. The proxy receives the request and ACKs it immediatly. But it tooks about 17 seconds until the client receives the HTTP response from the proxy.
When we look onto the WAN side, we will find the outgoing traffic for www.gstatic.com in TCP stream 1950. Due to the frame time it was send out 17 seconds later as the request was received on the LAN side. The HTTP response from gstatic.com comes immediatly, so the WAN line is not the issue here. The frame time of the external HTTP response from gstatic.com is nearly the same, as the frame time of the internal HTTP response that the client 10.88.129.242 receives from the proxy. That means the way back is also fine.
The captures of the DNS traffic are from another time range, so I was not able to find the matching DNS request for this connection. But all DNS responses are more or less fast, so I don't think that this is the cause for the delays.
In my opinion the Bluecoat proxy is the cause, because he delayed the outgoing request for unknown reason. I recommend to check the logs again. There must be a hint why the proxy delayed the outgoing request.
Copyright Wireshark Foundation, 2017-2023 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
