什麼會導致連接掛起在close_wait狀態

在CentOS 7系統上，C++應用程序在連接掛起時處於close_wait狀態，守護程序停止響應網絡通信。我的理解是內核處理TCP堆棧管理並負責收集這些連接。什麼會導致連接掛起在close_wait狀態

什麼可能導致這些連接掛掉，我應該在這個軟件中尋找哪些類型的錯誤？例如，might the application be failing to shut down the socket, or might something else be going on?

來源

2017-06-20 James Shewey

列舉的原因太多。嘗試通過使用像Wireshark這樣的工具檢查數據包跟蹤來縮小問題範圍。 – user4581301

Wireshark顯示連接關閉，但不清楚爲什麼守護程序會停止響應，並且如果close_wait是症狀或問題原因的一部分。 –

如果所有正確的握手都完成了，Linux應該將這個端口停留在TIME_WAIT幾分鐘，以確保沒有丟失的數據包遲到。你確定收到終止請求的一方發送了FIN嗎？ – user4581301

在CLOSE_WAIT狀態下看到連接的那一端運行的軟件沒有關閉套接字（例如，在從另一端接收FIN後顯式調用close（））。

CLOSE_WAIT狀態表示連接處於半關閉狀態，即另一端關閉了連接的一側，但是這不是。這在TCP中是完全有效的，因爲連接是全雙工的。

在此序列圖中，服務器在接收到FIN後進入CLOSE_WAIT狀態，並且將保持在該狀態，直到它調用關閉。

來源

2017-06-20 14:46:10

您確定您沒有將TCP狀態圖中的FIN_WAIT狀態與Linux內核中的CLOSE_WAIT狀態混爲一談嗎？ –

是的，CLOSE_WAIT是一個TCP狀態，實際上FIN_WAIT不是（有FIN_WAIT1和FIN_WAIT2）。請看[RFC 793的第3.2節]（https://tools.ietf.org/html/rfc793#section-3.2），第20-22頁。 –

@JamesShewey FIN_WAIT正在終止交易。 CLOSE_WAIT是收到終止等待的一方，直到同意終止併發送它的FIN爲止。換句話說，連接已經收到FIN，已經確認FIN，但還沒有發送FIN。在上圖中，它是被動方的「讀取返回0」和「關閉」之間的空間。訣竅是找出FIN無法發送的原因。你的程序是否保持在套接字上？ – user4581301

什麼會導致連接掛起在close_wait狀態

回答

相關問題