奇数 TCP 终止序列

Question

在对另一件事进行故障排除时，我注意到 TCP 关闭的奇怪模式。

数据包：http : //www.cloudshark.org/captures/7590ec4e6bef

发生的事情是，由于某种奇怪的原因，关闭序列的最后几个数据包被重新传输。该模式在 cloudshark 链接中，但对于后代，这里是一个摘要：

1. 源 -> 同步
2. 目标 -> 确认
3. 源 -> SynAck
4. 数据
5. 数据
6. 来源 -> Fin/Ack
7. 目标 -> Psh/Ack (6)
8. Dest -> Fin/Ack
9. 来源 -> 确认 (7)
10. 来源 -> 确认 (8)
11. [此时应该关闭两侧的连接。但事实并非如此。]
12. [+200ms] Dest -> Fin/Ack
13. 来源 -> 确认（8 & 12）

在重新发出 Fin/Ack 数据包之前，目标系统上的某些东西正在等待 200 毫秒。这在多个事务中非常一致。更糟糕的是，这种模式在事务的双方都复制：它出现在两个主机上的捕获中。它不像 Fin/Ack 数据包在某处被丢弃并被重新传输那么简单。或者，也许这是越来越下降了，但在一个水平之上，其中tcpdump工作。

200 毫秒的延迟让我认为这里涉及 TCP 延迟确认，但我无法弄清楚为什么会这样。

是上面tcpdump的甚至一件事？

这是 RHEL6 系统的正常连接模式吗？

Answer 1

请注意，您捕获的帧 #2 中的 PSH/ACK 数据包携带 37 个字节的数据。它不是对来自 10.232.16.133 的 FIN 请求的响应。响应在第 3 帧中，对它的 ACK 在第 5 帧中。

现在似乎发生的是最后一个 ACK​​ 没有到达目的地，因此在帧 #3 中发送的 FIN/ACK 在帧 #6 中重新传输。您在这里看到的 ~200 毫秒延迟不是延迟确认，而是更可能是重传超时。您应该能够通过查看来自连接另一端的数据包捕获来验证这一点，您永远不会看到最后一个 ACK​​ 到达。

如果您在所有连接上（并且可能在两个方向上）一致地看到这种行为，我想到的一个解释是路径中的某些状态保持数据包过滤器正在吞噬最后一个 ACK​​。