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

Spike in HTTP + lots of TCP out of order



Problem: The users experience a frequent disconnection. We have run wireshark on the PC of the user who was complaining. During the capture, he was connected to a few servers (setup explanation coming below) and claims his database connectivity & his SSH connections got disconnected. The wireshark capture also shows a lot of HTTP traffic originating from this user going out onto the internet.

Link to sanitised file:

Setup: UserPC (Wireshark Running) -> Cisco Layer 2 Switch -> CoreSwitch -> IDS/IPS -> Core Firewall -> DMZ Firewall -> Perimeter IDS/IPS -> Perimeter Firewall -> Internet

User Connections: 1. Connected to servers in the server VLAN (Database, SSH, ERP etc.) 2. Connected to websites on the internet

Review of Capture: There is a spike in HTTP Traffic for 4-5 seconds. Second 1 - 130000 bytes Second 2 - 160000 bytes Second 3 - 550000 bytes Second 4 - 300000 bytes Second 5 - 150000 bytes

During this time, there is a spike in TCP out of order packets (mainly due to HTTP). And the user experienced a network issue at this time. How should we analyse this situation?


asked 02 Oct '14, 19:56

raymondw's gravatar image

accept rate: 0%

edited 13 Oct '14, 21:25

2 Answers:


The out of order packets are due to the IDS/FW/Proxy sending to you using a reduced MSS of 1360 while receiving data at a MSS 1460 from the internet. This leads to 2 segments being sent to you: one with 1360 bytes and one with 100 bytes.
The majority of small (100 bytes) segments arrive earlier than the logically preceding 1360 bytes causing lots of gap reports being sent upstream.
I don't see any 'disconnects' in the trace though.
I would suggest to figure out who is adjusting the MSS of your SYN packets to 1360 on their way to the proxy.

Regards Matthias

answered 14 Oct '14, 08:48

mrEEde's gravatar image

accept rate: 20%


Hard to say without a look at the capture itself, because even though there is a lot of scenario description it does not really help that much. Something like "there is a spike for x seconds" is way to unspecific for any conclusion.

My advice would be either to post a capture, e.g. at Cloudshark (sanitize it first if necessary, e.g by using TraceWrangler) and have someone here look at it.

If you can't do that you'll have to look for signs of trouble in your capture, e.g. by searching for TCP reset packets that indicate session problems. The trouble with that is that you need some experience to do that because there are resets that are perfectly normal and expected. You can also try to filter on "tcp.analysis.flags" to see if you have interesting expert symptoms - but still, a skilled analyst is often required to tell which ones are important and which can be ignored.

answered 03 Oct '14, 03:50

Jasper's gravatar image

Jasper ♦♦
accept rate: 18%

Thank you Jasper.

I will sanitize and upload at cloudshark in a day. Thanks for the suggestion.

I have already seen the "tcp.analysis.flags". I didn't feel there was anything wrong with that. But, will look at it again, just in case.

(05 Oct '14, 04:11) raymondw

Hi Jasper,

I have uploaded the sanitized trace file in cloudshark. Can I send you the link to the file?


(08 Oct '14, 01:34) raymondw

Edit your question with the link.

(08 Oct '14, 02:37) grahamb ♦