在排除故障时,我注意到TCP关闭的奇怪模式.
数据包：http://www.cloudshark.org/captures/7590ec4e6bef
发生的事情是,由于一些奇怪的原因,关闭序列的最后几个数据包正在重新传输.模式是在cloudshark链接,但对于后代这里是一个摘要：
>来源 – > SYN
>目的地 – >确认
>来源 – > SYNACK
>数据
>数据
>来源 – > FIN /确认
>目的地 – > Psh / Ack(6)
>目的地 – > FIN /确认
>来源 – >确认(7)
>来源 – >阿克(8)
> [此时连接应在两侧关闭.但事实并非如此.
> [200ms] Dest – > FIN /确认
>来源 – > Ack(8& 12)
目标系统上的某些内容在重新发送Fin / Ack数据包之前等待200ms.这在多个事务中非常一致.更糟糕的是,这种模式在交易的两边复制：它出现在两个主机上的捕获中.它并不像Fin / Ack数据包在某处丢弃并重新传输那么简单.或者它可能会被丢弃,但是会高于tcpdump运行的水平.
200毫秒的延迟让我觉得TCP Delayed Ack在这里涉及,但我很难弄清楚它为什么会这样.
是不是tcpdump甚至是一件事？
这是RHEL6系统的正常连接模式吗？
解决方法
请注意,捕获的帧#2中的PSH / ACK数据包携带37个字节的数据.它不是对10.232.16.133的FIN请求的响应.响应在帧#3之后,ACK到帧#5.
现在似乎正在发生的是最后一个ACK没有到达目的地,因此帧#3中发送的FIN / ACK在帧#6中被重传.你在这里看到的~200 ms延迟不是延迟的ack,而是重传超时的可能性.您应该能够通过查看连接另一端的数据包捕获来验证这一点,在该连接中您永远不会看到最后一个ACK到达.
如果你在所有连接上(并且可能在两个方向上)都一致地看到这种行为,那么我想到的一个解释是,路径中的某些状态保持数据包过滤器正在吞咽最后一个ACK.
