redhat – 奇数TCP终止序列

在排除故障时,我注意到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系统的正常连接模式吗？

解决方法

现在似乎正在发生的是最后一个ACK没有到达目的地,因此帧#3中发送的FIN / ACK在帧#6中被重传.你在这里看到的~200 ms延迟不是延迟的ack,而是重传超时的可能性.您应该能够通过查看连接另一端的数据包捕获来验证这一点,在该连接中您永远不会看到最后一个ACK到达.

如果你在所有连接上(并且可能在两个方向上)都一致地看到这种行为,那么我想到的一个解释是,路径中的某些状态保持数据包过滤器正在吞咽最后一个ACK.

（编辑：衡阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!