TCP狀態轉移

在前一篇文章已經介紹了tcp協議的三次握手和四次揮手。總的來說，tcp通訊過程包括三個步驟：建立tcp連線（三次握手）、資料傳輸、終止tcp連線（四次揮手）。但是在這個通訊過程中，有非常複雜的狀態問題，下面就來了解一下進行tcp協議通訊時候的狀態轉移。

tcp協議根據連線時接收到報文的不同型別，採取相應動作也不同，還要處理各個狀態的關係，如當收到握手報文時候、超時的時候、使用者主動關閉的時候等都需要不一樣的狀態去採取不一樣的處理。在lwip中，為了實現tcp協議的狀態描述，定義了11種連線時候的狀態：

static
const char *
const tcp_state_str=
;

具體見下圖：

紅色虛線：表示伺服器的狀態轉移。

黑色實線：表示客戶端的狀態轉移。

順便再提一點不太常見的tcp協議狀態轉移，主要是針對伺服器端的（綠色那條）：

伺服器在收到syn握手報文後，再收到了客戶端的rst報文，那麼它會重新進入監聽狀態，再重新等待連線。

一般說來，無論何時乙個報文段發往基準的連線出現錯誤，tcp都會發出乙個復位報文段（這裡提到的基準的連線是指由目的 ip位址、目的埠號、源 ip位址和源埠號都是已知的連線。

此外產生復位的另一種常見情況是當連線請求到達時，目的埠並沒有在監聽中，當乙個資料報到達目的埠時，它將產生乙個icmp埠不可達的資訊，同時tcp協議將進行復位，當然啦，在lwip中這些icmp埠不可達報文都會被丟棄的，也不用管那麼多。

第一次看這個轉移圖的時候，可能很多人都有疑惑，為什麼要有乙個time_wait狀態？為什麼不能直接到達closed狀態？

每個具體tcp連線的實現必須選擇乙個tcp報文段最大生存時間msl（maximum segment lifetime），就如ip資料報中的ttl字段表示報文在網路中生存的時間一樣。msl是任何報文段被丟棄前在網路內的最長時間，這個時間是有限的，為什麼需要等待呢？我們知道ip資料報是不可靠的，而tcp報文段是封裝在ip資料報中，tcp協議必須保證發出的ack報文段是正確被對方接收，因此處於該狀態的主機必須在這個狀態停留最長時間為2倍的msl，以防最後這個ack丟失，因為tcp協議必須保證資料能準確送達目的地。

假設沒有time_wait這種狀態。現實中，網路環境不是理想的。在資料報傳輸的過程中，難免會有一些延時啊、丟包啊的情況發生。如果在客戶端的最後乙個確認報文段發出去之後，由於某種原因，沒有到達服務端，服務端在超時後，就會向客戶端重新發乙個 fin 報文段，請求重傳這個已經丟失的確認報文段。但由於在客戶端，連線實際上已經斷開，埠已經關閉。那麼在客戶端收到這個報文段後，會向服務端傳送乙個rst報文段請求重連（這也是為什麼我要在前面講解rst的原因），而此時伺服器收到這個rst報文段後，會認為是錯誤的，因為在伺服器看來都沒斷開連線，它所期望收到的是確認報文段。所以這個時候客戶端是不允許直接close關閉了事的，因此它需要等待伺服器確認了，再close。

再假設一下：如果沒有time_wait這種狀態，客戶端在關閉連線後，再次成功建立新的連線，客戶端任然可能會收到伺服器的最後乙個確認報文段，但是由於序號不同（重新建立連線時的序號是隨機的，這點很重要，要記住），客戶端會要求服務端重傳資料報，這樣，連線就必然會混亂出錯。而在time_wait這種狀態等待一段時間是為了讓本次連線的時間內所產生的所有報文都從網路中消失，使得下乙個新的連線不會出現舊的報文。

而time_wait狀態的等待時間一般是2mal，並且客戶端連線的埠沒有釋放，這樣，讓前乙個連線的報文段有足夠的時間被處理或者丟棄，也就不會出現這個問題。

這才是tcp協議優雅且可靠的終止連線方式啊！太強大了，我得膜拜一下~

TCP狀態轉移

TCP狀態轉移

TCP狀態轉移

TCP狀態轉移

相關推薦