有一些網絡基礎的同學都知道TCP連接需要三次握手，斷開需要4次握手。但是如果要說TCP連接建立和斷開過程中，連接狀態是如何變化的，估計很難說出具體情況，下面我們看一張圖，描述了TCP連接狀態變化過程：
TCP連接狀態變化
這裡有幾個問題需要注意：
1、為什麼建立連接時還需要第3次確認
- 主要防止已經失效的連接請求報文突然又傳送到了服務器，從而產生錯誤。
2、為什麼關閉連接是4次握手
- 關閉連接時，服務器收到對方的FIN報文時，僅僅表示對方不再發送數據了但是還能接收數據，而自己也未必全部數據都發送給對方了，所以己方可以立即關閉，也可以發送一些數據給對方後，再發送FIN報文給對方來表示同意現在關閉連接，因此，己方ACK和FIN一般都會分開發送，從而導致多了一次。
3、為什麼客戶端在TIME-WAIT階段要等2MSL
- 保證客戶端發送的最後一個ACK報文能夠到達服務器，因為這個ACK報文可能丟失。如果服務器已經發送了FIN+ACK報文請求斷開了，但還沒有收到客戶端的回應，服務器會認為自己發送的請求斷開報文丟失，於是服務器又會重新發送一次；而客戶端就能在這個2MSL時間段內收到這個重傳的報文，接著給出回應報文，並且會重啟2MSL計時器。
- 防止類似與“三次握手”中提到了的“已經失效的連接請求報文段”出現在本連接中。客戶端發送完最後一個確認報文後，在這個2MSL時間中，就可以使本連接持續的時間內所產生的所有報文段都從網絡中消失。這樣新的連接中不會出現舊連接的請求報文。
熟悉tcp連接狀態變化過程，對一些網絡定位很有幫助；在linux服務器上面，通過netstat命令可以看到服務器當前所有TCP連接和狀態，比如敲下如下命令看到的結果（關於netstat命令的使用可以通過幫助文檔去學習）：
<code>netstat -anltp | less Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 1548/php-fpm: maste tcp 0 0 0.0.0.0:17902 0.0.0.0:* LISTEN 503/sshd tcp 0 0 127.0.0.1:63791 0.0.0.0:* LISTEN 30946/redis-server tcp 0 0 172.27.0.2:80 10.241.193.251:64636 SYN_RECV - tcp 0 0 172.27.0.2:80 10.174.169.193:14651 SYN_RECV - tcp 0 0 172.27.0.2:80 10.117.181.16:29235 SYN_RECV -/<code>
分享到:
