While troubleshooting another thing, I've noticed an odd pattern of TCP closes.
Packets: http://www.cloudshark.org/captures/7590ec4e6bef
What's happening is that the last few packets of the close sequence are getting retransmitted for some odd reason. The pattern is in the cloudshark link, but for posterity here is a summary:
- Source -> Syn
- Dest -> Ack
- Source -> SynAck
- Data
- Data
- Source -> Fin/Ack
- Dest -> Psh/Ack (6)
- Dest -> Fin/Ack
- Source -> Ack (7)
- Source -> Ack (8)
- [At this point the connection should be closed on both sides. But it isn't.]
- [+200ms] Dest -> Fin/Ack
- Source -> Ack (8 & 12)
Something on the Destination system is waiting 200ms before reissuing the Fin/Ack packet. This is pretty consistent across multiple transactions. More damning, this pattern replicates on both sides of the transaction: it shows up in captures on both hosts. It isn't as simple as the Fin/Ack packet getting dropped somewhere and getting retransmitted. Or maybe it is getting dropped, but on a level above where tcpdump
operates.
The 200ms delay makes me think TCP Delayed Ack is involved here, but I'm having trouble figuring out why it would.
Is above tcpdump even a thing?
Is this a normal connection pattern for RHEL6 systems?