TCP的鏈接狀態詳解

TCP的鏈接創建於鏈接釋放分別採用的是三次握手協議與四次握手協議。對應的狀態有：

1.tcp的鏈接創建與釋放過程：

2.TCP的狀態：

LISTEN：偵聽來自遠方的TCP端口的鏈接請求

SYN-SENT：再發送鏈接請求後等待匹配的鏈接請求，客戶機在鏈接請求發送後，等待服務器端的確認狀態

SYN-RECEIVED：再收到和發送一個鏈接請求後等待對方對鏈接請求的確認，服務器端接受都客戶機的鏈接請求後的發出確認包後，進入SYN-RECEIVED狀態

ESTABLISHED：表明一個打開的鏈接

FIN-WAIT-1：等待遠程TCP鏈接中斷請求，或先前的鏈接中斷請求的確認，客戶端發送鏈接中斷請求後將FIN至一，並進入FIN-WAIT-1狀態

FIN-WAIT-2：從遠程TCP等待鏈接中斷請求，客戶端收到FIN報文

確認後進入此狀態

CLOSE-WAIT：等待從本地用戶發來的鏈接中斷請求，服務器對客戶機的鏈接中斷請求的確認後進入CLOSE-WAIT狀態

CLOSING：等待遠程TCP對鏈接中斷的確認

LAST-ACK：等待原來的發向遠程TCP的鏈接中斷請求的確認

TIME-WAIT：等待足夠的時間以確保遠程TCP接收到鏈接中斷請求的確認

CLOSED：沒有任何鏈接狀態

3.狀態剖析：

創建鏈接協議（三次握手）

（1）客戶端發送一個帶SYN標誌的TCP報文到服務器。這是三次握手過程當中的報文

（2）服務器端迴應客戶端的，這是三次握手中的第2個報文，這個報文同時帶ACK標誌和SYN標誌。所以它表示對剛纔客戶端SYN報文的迴應；同時又標誌SYN給客戶端，詢問客戶端是否準備好進行數據通信。

（3）客戶必須再次迴應服務段一個ACK報文，這是報文段3。

鏈接終止協議（四次握手）

因爲TCP鏈接是全雙工的，所以每一個方向都必須單獨進行關閉。這原則是當一方完成它的數據發送任務後就能發送一個FIN來終止這個方向的鏈接。收到一個FIN只意味着這一方向上沒有數據流動，一個TCP鏈接在收到一個FIN後仍能發送數據。首先進行關閉的一方將執行主動關閉，而另外一方執行被動關閉。

（1）TCP客戶端發送一個FIN，用來關閉客戶到服務器的數據傳送（報文段4）。

（2）服務器收到這個FIN，它發回一個ACK，確認序號爲收到的序號加1（報文段5）。和SYN同樣，一個FIN將佔用一個序號。

（3）服務器關閉客戶端的鏈接，發送一個FIN給客戶端（報文段6）。

（4）客戶段發回ACK報文確認，並將確認序號設置爲收到序號加1（報文段7）。

●CLOSED:這個沒什麼好說的了，表示初始狀態。

●LISTEN:這個也是很是容易理解的一個狀態，表示服務器端的某個SOCKET處於監聽狀態，能夠接受鏈接了。

●SYN_RCVD:這個狀態表示接受到了SYN報文，在正常狀況下，這個狀態是服務器端的SOCKET在創建TCP鏈接時的三次握手會話過程當中的一箇中間狀態，短暫，基本上用netstat你是很難看到這種狀態的，除非你特地寫了一個客戶端測試程序，故意將三次TCP握手過程當中最後一個ACK報文不予發送。所以這種狀態時，當收到客戶端的ACK報文後，它會進入到ESTABLISHED狀態。

●SYN_SENT:這個狀態與SYN_RCVD遙想呼應，當客戶端SOCKET執行CONNECT鏈接時，它首先發送SYN報文，所以也隨即它會進入到了SYN_SENT狀態，並等待服務端的發送三次握手中的第2個報文。SYN_SENT狀態表示客戶端已發送SYN報文。

●ESTABLISHED：這個容易理解了，表示鏈接已經創建了。

●FIN_WAIT_1:這個狀態要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態的真正含義都是表示等待對方的FIN報文。而這兩種狀態的區別是：FIN_WAIT_1狀態其實是當SOCKET在●ESTABLISHED狀態時，它想主動關閉鏈接，向對方發送了FIN報文，此時該SOCKET即進入到●FIN_WAIT_1狀態。而當對方迴應ACK報文後，則進入到FIN_WAIT_2狀態，固然在實際的正常狀況下，不管對方何種狀況下，都應該立刻迴應ACK報文，因此FIN_WAIT_1狀態通常是比較難見到的，而FIN_WAIT_2狀態還有時經常能夠用netstat看到。

●FIN_WAIT_2：上面已經詳細解釋了這種狀態，實際上FIN_WAIT_2狀態下的SOCKET，表示半鏈接，也即有一方要求close鏈接，但另外還告訴對方，我暫時還有點數據須要傳送給你，稍後再關閉鏈接。

●TIME_WAIT:表示收到了對方的FIN報文，併發送出了ACK報文，就等2MSL後便可回到CLOSED可用狀態了。若是FIN_WAIT_1狀態下，收到了對方同時帶FIN標誌和ACK標誌的報文時，能夠直接進入到TIME_WAIT狀態，而無須通過FIN_WAIT_2狀態。

●CLOSING:這種狀態比較特殊，實際狀況中應該是不多見，屬於一種比較罕見的例外狀態。正常狀況下，當你發送FIN報文後，按理來講是應該先收到（或同時收到）對方的ACK報文，再收到對方的FIN報文。可是CLOSING狀態表示你發送FIN報文後，並無收到對方的ACK報文，反而卻也收到了對方的FIN報文。什麼狀況下會出現此種狀況呢？其實細想一下，也不可貴出結論：那就是若是雙方几乎在同時close一個SOCKET的話，那麼就出現了雙方同時發送FIN報文的狀況，也即會出現CLOSING狀態，表示雙方都正在關閉SOCKET鏈接。

●CLOSE_WAIT:這種狀態的含義實際上是表示在等待關閉。怎麼理解呢？當對方close一個SOCKET後發送FIN報文給本身，你係統毫無疑問地會迴應一個ACK報文給對方，此時則進入到CLOSE_WAIT狀態。接下來呢，實際上你真正須要考慮的事情是察看你是否還有數據發送給對方，若是沒有的話，那麼你也就能夠close這個SOCKET，發送FIN報文給對方，也即關閉鏈接。因此你在CLOSE_WAIT狀態下，須要完成的事情是等待你去關閉鏈接。

●LAST_ACK:這個狀態仍是比較容易好理解的，它是被動關閉一方在發送FIN報文後，最後等待對方的ACK報文。當收到ACK報文後，也便可以進入到CLOSED可用狀態了。

有人會問到兩個問題：

1.爲何在客戶端收到服務器端對於請求報文的確認後還要作一次確認呢？？？？

主要是爲了防止已經失效的鏈接請求報文段忽然有傳到了服務器端，何爲「失效的鏈接請求報文段」。咱們假設一種狀況，若是A向B發送了請求報文，可是沒有發送到B而是在網絡中滯留了，A會從新發送此報文，併到達B而且創建了鏈接，傳輸數據完成後並釋放了鏈接。當此失效的報文再一次到達B後，服務器端就會又一次覺得A發送了創建鏈接的報文，併發送確認，若是沒有第三次握手，B發送完確認後，此TCP鏈接就會創建成功。而這並非A所但願的，因此A會不予回覆，B會一直處於等待A發送數據的狀態，形成B資源的浪費。

2.爲何在釋放連接的過程當中TIME-WAIT要設定爲2MSL時間？？？？

（1）。保證A發送的最後一個確認關閉的報文可以到達B以實現B的正常退出。若是A對於B發送的FIN+ACK報文的確認在網絡中丟失，B會因超時重傳FIN+ack報文，A等待2MSL時間能夠保證收到此重傳報文，並對此報文作出回覆。

（2）。防止已失效的報文出如今本次鏈接中。A等待2MSL時間能夠保證在這段時間內產生的全部的報文都會在網絡中失效，這樣不會對下一次的鏈接形成影響。