TCP：半關閉連接上的數據

我正在實現一個TCP堆棧，並遇到半關閉連接的問題。TCP：半關閉連接上的數據

我的實現充當服務器端。客戶端建立連接，然後發送一些數據，然後發送「FIN」消息。然後服務器確認來自客戶端的數據，發送一些自己的數據，然後關閉它的一半連接（發送「FIN」）。

問題是，客戶端不會確認服務器在半關閉連接上發送的數據，也不會收到其最終的「FIN」消息。根據netstat，客戶端處於狀態FIN_WAIT2。在服務器不發送任何數據的相同情況下，事情會順利進行。有問題的客戶端是netcat，所以我認爲問題在我的端:)

屏幕快照可用here。實際的PCAP文件可用here。

我的問題是，一般情況下，我應該期望在半關閉連接上發送數據的ACKS;特別是，我在上面的例子中做了什麼錯誤。

任何幫助將不勝感激！

來源

2013-10-23 Guy Katz

從對等角度來看，你不知道它是半關閉連接。客戶端可能已經完全關閉了連接，在這種情況下，端口位於您身邊的CLOSE_WAIT位置，同時端口位於FIN_WAIT_2位置，但對等方會向您的發送發送RST而不是ACK。您的鏈接下載.exes，就我而言，這可能是病毒。有沒有其他方法可以使它們可用？ – EJP

感謝您的評論。我更新了鏈接 - 希望他們現在能正確顯示。 –

截圖中的最後一行是第一個PSH的ACK。還有更多嗎？ – EJP

也許服務器應該在FIN/ACK中發送ACK = 2561而不是2562？

來源

2013-10-24 00:33:31 Den

我剛剛嘗試使用2561而不是2562.這產生了類似的結果 - 客戶端重複它的[FIN，PSH，ACK]消息，但是序列號爲2562 - 所以我認爲2562是正確的認爲首先（FIN計爲1個字節）。 EJP，我在我之前的回覆中犯了一個錯誤。 Netstat表示，在原始問題（acking 2562）中，客戶端處於FIN-WAIT-2。當使用2561時，它處於FIN-WAIT-1。 –

是的，我錯了：它應該是2562.顯然，客戶端不想因爲未知原因來確認您的數據。您可以嘗試重新傳輸數據並查看會發生什麼情況。 – Den

FIN-WAIT-2意味着它看到了ACK，所以序列號必須正確，但這也意味着它沒有在同一個段中看到FIN。如果FIN計數爲1個字節，那麼LEN應該是1？

來源

2013-10-24 21:58:36 EJP

我認爲「LEN」不是數據包中的實際字段 - 只是wireshark告訴你tcp段包含多少個字節。 FIN是標題中的一個標誌，而不是一個實際的字節，所以我認爲0是正確的。我同意你的評估，即客戶忽略鰭。這個問題似乎在更早的時候開始，當它沒有確認fin之前發送的任何數據。這是我原來的問題的一部分 - 我是否應該期望客戶端確認這些數據，並且已經關閉了它的連接？ –

是的，你應該期待所有數據的ACK。 – EJP

TCP：半關閉連接上的數據

回答

相關問題