在排除其他问题的同时，我注意到TCPclosures了一个奇怪的模式。
数据包： http ： //www.cloudshark.org/captures/7590ec4e6bef
发生什么事是因为一些奇怪的原因，closures序列的最后几个数据包被重新传输。 这个模式是在云端链接，但为了后代这里是一个总结：
在重新发送Fin / Ack数据包之前，Destination系统上的某些东西正在等待200ms。 这在多个交易中是非常一致的。 更糟的是，这种模式在交易的双方都复制：它在两个主机上都有捕获。 这并不像Fin / Ack数据包在某个地方掉落并重新传输那么简单。 或者也许它正在下降，但在tcpdump运行的上面 。
200ms的延迟让我觉得TCP Delayed Ack在这里涉及到，但是我很难搞清楚为什么会这样。
上面的tcpdump甚至是一件事情？
这是RHEL6系统的正常连接模式吗？
请注意，捕获帧＃2中的PSH / ACK数据包携带37个字节的数据。 这不是对来自10.232.16.133的FIN请求的响应。 响应在帧＃3之后，ACK在帧＃5中。
现在似乎正在发生的是这个最后的ACK没有到达目的地，所以在帧＃3中发送的FIN / ACK在帧＃6中被重新发送。 您在这里看到的〜200 ms延迟不是延迟确认，而更可能是重新传输超时。 您应该能够通过查看连接另一端的数据包捕获来validation这一点，在这种情况下，您永远不会看到最后一个ACK到达。
如果你在所有的连接上（也可能是在两个方向上）看到这种行为，那么我想到的一个解释是path中的一些状态保持包filter正在吞咽最后的ACK。