socket編程中常見問題–《二》

1） socket 用戶端 FIN_WAIT_2，而裝置端顯示CloseWait

這個原因是伺服器端沒有及時CloseSocket；

下面講解下socket的斷開流程：

TCP報文段首部格式：

序號：本報文段所發送的資料的第一個位元組的序號。

確認號ack：期待收到對方下一個報文段的第一個資料位元組的序號

確認ACK：佔1位，僅當ACK=1時，確認號欄位才有效。ACK=0時，確認號無效

同步SYN：串連建立時用於同步序號。當SYN=1，ACK=0時表示：這是一個串連請求報文段。 若同意串連，則在響應報文段中使得SYN=1，ACK=1。因此，SYN=1表示這是一個串連請求，或串連接受報文。終止FIN：用來釋放一個串連。FIN=1表示：此報文段的發送方的資料已經發送完畢，並要求釋放運輸串連;

 

還要再發送一次確認是為了，防止已失效的串連請求報文段突然又傳到了B，因而產生錯誤。

已失效的報文段：正常情況下：A發出串連請求，但因為丟失了，故而不能收到B的確認。於是A重新發出請求，然後收到確認，建立串連，資料轉送完畢後，釋放串連，A發了2個，一個丟掉，一個到達，沒有“已失效的報文段”，但是，某種情況下，A的第一個在某個節點滯留了，延誤到達，本來這是一個早已失效的報文段，但是在A發送第二個，並且得到B的回應，建立了串連以後，這個報文段竟然到達了，於是B就認為，A又發送了一個新的請求，於是發送確認報文段，同意建立串連，假若沒有三次的握手，那麼這個串連就建立起來了（有一個請求和一個回應），此時，A收到B的確認，但A知道自己並沒有發送建立串連的請求，因為不會理睬B的這個確認，於是呢，A也不會發送任何資料，而B呢卻以為新的串連建立了起來，一直等待A發送資料給自己，此時B的資源就被白白浪費了。但是採用三向交握的話，A就不發送確認，那麼B由於收不到確認，也就知道並沒有要求建立串連。

 

TIME_WAIT 是主動關閉 TCP
串連的那一方出現的狀態，系統會在 TIME_WAIT 狀態下等待 2MSL（maximumsegment lifetime）後才能釋放串連（連接埠）。

 

CLOSE_WAIT 是被動關閉 TCP 串連時產生的，如果收到另一端關閉串連的請求後，本地不關閉相應通訊端就會導致本地通訊端進入這一狀態。如果存在大量的 CLOSE_WAIT，說明用戶端並發量大，且伺服器未能正常感知用戶端的退出，也並未及時 close
這些通訊端。