奇數 TCP 終止序列

在對另一件事進行故障排除時，我注意到 TCP 關閉的奇怪模式。

數據包：http ://www.cloudshark.org/captures/7590ec4e6bef

正在發生的事情是由於某種奇怪的原因，關閉序列的最後幾個數據包正在重新傳輸。該模式在 cloudshark 連結中，但為了後代，這裡是一個摘要：

1. 來源 -> 同步
2. 目的地 -> 確認
3. 來源 -> SynAck
4. 數據
5. 數據
6. 來源 -> Fin/Ack
7. 目的地 -> Psh/Ack (6)
8. 目的地 -> 鰭/確認
9. 來源 -> 確認 (7)
10. 來源 -> 確認 (8)
11. $$ At this point the connection should be closed on both sides. But it isn’t. $$
12. $$ +200ms $$目的地 -> 鰭/確認
13. 來源 -> Ack (8 & 12)

目標系統上的某些東西在重新發出 Fin/Ack 數據包之前等待 200 毫秒。這在多個事務中非常一致。更糟糕的是，這種模式在事務的雙方都複製：它出現在兩個主機上的擷取中。它不像 Fin/Ack 數據包在某處被丟棄並被重新傳輸那麼簡單。或者它可能正在下降，但在執行的水平之上tcpdump。

200 毫秒的延遲讓我覺得這裡涉及 TCP 延遲確認，但我無法弄清楚為什麼會這樣。

以上 tcpdump甚至是一回事嗎？

這是 RHEL6 系統的正常連接模式嗎？

請注意，您擷取的第 2 幀中的 PSH/ACK 數據包攜帶 37 個字節的數據。這不是對來自 10.232.16.133 的 FIN 請求的響應。響應在第 3 幀中，對它的 ACK 在第 5 幀中。

現在似乎發生的事情是最後一個 ACK 沒有到達目的地，因此在第 3 幀中發送的 FIN/ACK 在第 6 幀中重新傳輸。您在此處看到的約 200 毫秒延遲不是延遲確認，而是更可能是重傳超時。您應該能夠通過查看來自連接另一端的數據包擷取來驗證這一點，您永遠不會看到最後一個 ACK 到達。

如果您在所有連接上（並且可能在兩個方向上）始終看到這種行為，我想到的一個解釋是路徑中的一些狀態保持數據包過濾器正在吞噬最後一個 ACK。

引用自：https://serverfault.com/questions/577185