（六）：TCP的鏈接創建與釋放過程

一：    TCP的三次握手即鏈接的創建

用三次握手創建TCP鏈接，如圖示：

如圖，假設A運行的是TCP客戶程序，而B運行的是TCP服務器程序。

最初兩端的TCP進程都處於CLOSED(關閉)狀態。

注意：A主動打開鏈接，B被動打開鏈接。

    B的TCP服務器進程先建立傳輸控制塊TCB，準備接受客戶進程的鏈接請求。而後服務器進程就處於LISTEN(偵聽)狀態，等待客戶的鏈接請求。若有，即作出響應。

    A的TCP客戶進程也是首先建立傳輸控制塊TCB，而後向B發送鏈接請求報文段。這時候首部中的同步位SYN=1，同時選擇一個初始序號seq=x。TCP規定，SYN報文段即SYN=1的報文段不能攜帶數據，但要消耗掉一個序號。這是，TCP客戶進程進入SYN-SENT（同步已發送）狀態。

   B收到鏈接請求報文段後，如贊成創建鏈接，則向A發送確認。在確認報文段中應把SYN位和ACK位都置1，確認號是ack+1，同時也爲本身選擇一個初始序號seq=y。請注意，這個報文段也不能攜帶數據，但一樣要消耗掉一個序號。這時，TCP服務器進程進入SYN-RCVD（同步已收到 ）狀態。

   TCP客戶進程收到B的確認後，還要向B給出確認。確認報文段的ACK置1，確認號是ack=y+1，而本身的序號seq=x+1。TCP的標準規定，ACK報文段能夠攜帶數據。但若是不攜帶數據則不消耗序號。在這種狀況下，下一個數據報文段的序號還是seq=x+1。這時候，TCP鏈接已經創建。A進入ESTABLISHED（已創建鏈接）狀態。

    當B收到A的確認後，B也進入已創建鏈接狀態。

    爲何A還要發送一次確認呢？

    這主要是爲了防止已失效的鏈接請求報文段忽然又傳送到了B，於是產生錯誤。

 

 

二：    TCP的四次揮手即鏈接的釋放

TCP釋放鏈接的過程，四次揮手，如圖示：

        

               

    數據傳輸結束後，通訊的雙方均可釋放鏈接。

    如今A 和 B都處於創建鏈接狀態即ESTABLISHED。A的應用進程先向其TCP發出鏈接釋放報文段，並中止在發送數據，主動關閉TCP鏈接。A把鏈接釋放報文段首部的終止控制位FIN置1，其序號seq=u，它等於前面已傳送過的數據的最後一個字節的序號加1。.這時A進入FIN-WAIT-1（終止等待1）狀態，等待B的確認。

    請注意，FIN報文段即便不攜帶數據，它也消耗掉一個序號。

    B收到 鏈接釋放報文段後即發出確認，確認號是ack=u+1,而這個報文段本身的序號是v，等於B前面已傳送過的數據的最後一個字節的序號加1。而後B就進入CLOSE-WAIT（關閉等待）狀態。

    TCP服務器進程這時應通知應用進程，於是從A到B這個方向的鏈接就釋放了。

    注意：這時的TCP鏈接處於半關閉（half-close）狀態。即A已經沒有數據要發送了，但B若發送數據，A仍要接收。也就是說，從B到A這個方向的鏈接並未關閉，這個狀態可能會持續一些時間。

    A收到來自B的確認後，就進入FIN-WAIT-2(終止等待2）狀態。等待B發出的鏈接釋放報文段。

    若B已經沒有要向A發送的數據，其應用進程就通知TCP釋放鏈接。這時B發出的鏈接釋放報文段必須使FIN=1。現假定B的序號w（在半關閉狀態，B可能又發送了一些數據）。B還必須重複上次已發送的確認號ack=u+1。這時B就進入LAST-ACk（最後確認）狀態，等待A的確認。                                                                      

    A在收到B的鏈接釋放報文段後，必須對此發出確認。在確認報文段中把ACK置1，確認號ack=w+1，而本身的序號是seq=u+1。而後進入到TIME-WAIT（時間等待）狀態。

    注意：如今TCP鏈接尚未釋放掉。必須通過時間等待計時器TIME-WAIT設置的時間2MSL後，A才進入到CLOSED狀態。時間MSL叫作最長報文段壽命。    

    當A進入到時間等待狀態後，要通過必定的時間才能進入CLOSED狀態。才能開始下一個鏈接的創建。

    當A撤下相應的傳輸控制塊TCB後，就結束了此次的TCP鏈接。

    爲何A在TIME-WAIT時間等待狀態必須等待一段時間了。好比說等待2MSL。

第一：

        爲了保證A發送的最後一個ACK報文段可以到達B。這個ACK報文段有可能丟失，於是使處在LAST-ACK狀態的B收不到對已發送的FIN+ACK報文段的確認。B會超時重傳這個FIN+ACK報文段，而A就能在2MSL時間內收到這個重傳的FIN+ACK報文段。接着A重傳一次確認，從新啓動2MSL計時器。最後，A和B都正常進入到CLOSED狀態。若是A在TIME-WAIT狀態不等待一段時間，而是在發送完ACK報文段當即釋放鏈接，那麼就沒法收到B重傳的FIN+ACK報文段。於是也不會在發送一次確認報文段，這樣，B就沒法正常進入到ClOSED狀態。

第二：

        防止以前提到過的「已失效的鏈接請求報文段「出如今本鏈接中。A在發送完最後一個ACK報文段後，在通過時間2MSL，就可使本鏈接持續的時間內所產生的全部報文段都從網絡中消失，這樣就可使下一個新的鏈接中不會出現這種舊的鏈接請求報文段。

 

    注意：

        B只要收到了A發出的確認，就進入了CLOSED狀態。一樣，B在撤銷相應的傳輸控制塊TCB後，就結束了此次的TCP鏈接。能夠發現，B結束TCP鏈接的時間要比A早一些。