TCP是面向鏈接的協議（計算機網絡——運輸層），每個運輸鏈接包括鏈接創建、數據傳送和鏈接釋放。運輸鏈接的管理就是使運輸鏈接的創建和釋放都能正常進行。TCP鏈接採用的是CS模式，主動發起的鏈接的應用進程叫客戶（Client），被動等待鏈接的應用進程叫服務器（Server）。在TCP鏈接創建過程當中須要解決如下三個問題：緩存

（1）要使每一方可以通知對方的存在；服務器

（2）要容許雙方協商一些參數（如最大窗口值、是否使用窗口擴大選項和時間戳選項等）；網絡

（3）可以對運輸實體資源（如緩存大小、鏈接表中的項目等）進行分配。spa

1、鏈接創建——三次握手

TCP鏈接創建的過程如上，主機A是客戶應用進程，B運行服務器應用程序。初始狀態，兩端的TCP進程都屬於CLOSED （關閉）狀態。B的TCP服務器先建立傳輸控制塊TCB，準備接受客戶進程的請求，而後就處於LISTEN（監聽）狀態，等待客戶請求。.net

（1）第一次握手：A主動打開鏈接， 建立傳輸控制模塊TCB，而後向B發出請求報文段。TCP報文段首部的同步位SYN=1，同時選擇一個初始序號seq=x。TCP規定，SYN報文段不能攜帶數據，但要消耗掉一個序號。此時，TCP客戶進程處於同步已發送（SYN-SENT）狀態。計算機網絡

（2）第二次握手：B收到請求報文段後，若是贊成鏈接，則向A發送確認。確認報文段中，SYN=1，ACK=1，確認號是ack=x+1，同時也爲本身選擇一個初始序號seq=y。這個報文段也不能攜帶數據，一樣要消耗掉一個序號。此時TCP服務進程處於同步收到（SYN-RCVD）狀態。blog

（3）第三次握手：TCP客戶程序收到B的確認後，再次向B發送確認。確認報文段ACK=1，確認號ack=y+1，而本身的序號seq=x+1。TCP規定，ACK報文段能夠攜帶數據，但若是不攜帶數據則不消耗序號。此時，TCP鏈接已經創建，A進入已創建鏈接（ESTABLISHED）狀態。進程

B收到A的確認後，也進入已創建鏈接（ESTABLISHED）狀態。資源

疑問：爲什麼A（客戶端應用進程）還要再發一次確認呢？（第三次握手）get

考慮以下一種場景：A向B發送鏈接請求，可是因爲某種緣由（在某個網絡節點長時間滯留）致使在A和B以前的一次TCP鏈接已經釋放後的某個時間，該鏈接請求才到達B。若是沒有第三次握手，B在收到這個遲到的鏈接請求後，會誤認爲A又請求創建鏈接，就又會創建鏈接。假定有第三次握手，即使以前的某個鏈接請求到達B，只要B沒有收到A的第三次握手確認，TCP鏈接就不會創建。

2、鏈接釋放——四次揮手

數據傳輸結束後，雙方均可以釋放鏈接。 如今A和B都處於ESTABLISHED狀態。

（1）第一次揮手：A的應用進程先先其TCP發送鏈接釋放報文段，並中止發送數據，主動關閉鏈接。A把鏈接釋放報文段首部的終止控制位FIN=1，序號seq=u（序號等於前面已經傳送過的數據的最後一個字節的序號+1）。此時A進入終止等待1（FIN-WAIT-1）狀態。TCP規定，FIN報文段不能攜帶數據，也消耗一個序號。

（2）第二次揮手：B收到鏈接釋放報文段後發出確認，確認號ack=u+1，序號seq=v（序號等於前面已經傳送過的數據的最後一個字節的序號+1）。此時B進入關閉等待（CLOSE-WAIT）狀態。TCP服務進程此時應通知高層應用進程，A到B這個方向的鏈接就釋放了，此時TCP鏈接處於半關閉狀態。即A已經沒有數據要發送了，但若是B要發送數據，A仍要接收。即，B到A方向的鏈接並未關閉。A收到B的確認後，進入終止等待2（FIN-WAIT-2）狀態，等待B發出鏈接釋放報文段。

（3）第三次揮手：若是B已經沒有數據發送給A，其應用進程將通知鏈接釋放。B發出的鏈接釋放報文段FIN=1，序號seq=w（半關閉狀態B可能又發送了一些數據給A，若是沒有，則序號seq=v+1），B必須重複發送已經發送過的確認號ack=u+1（由於B收到的A的報文段的最後一個序號始終是u）。此時B進入最後確認（LAST-ACK）狀態，等待A的確認。

（4）第四次揮手：A收到B的鏈接釋放報文段後，必須發出確認。ACK=1，確認號ack=w+1，本身的序號seq=u+1。而後本身進入時間等待（TIME-WAIT）狀態。通過時間等待計時器（TIME-WAIT timer）設置的時間2MSL後，A進入CLOSED狀態。

MSL指的是最長報文段壽命（Maximum Segment Life），RFC793建議爲2分鐘。2MSL即4分鐘。

疑問：爲何A在TIME-WAIT狀態必須等待2分鐘呢？

一方面是爲了保證A發送的最後一個ACK報文段可以到達B。這個ACK報文段有可能丟失，所以處於LAST-ACK狀態的B收不到對本身以前已經發送的ACK和FIN報文段的確認。B會超時重傳這個ACK+FIN報文段，A就會再次發送一次ACK確認報文段，再啓動計時2MSL。A發送完最後一個確認ACK後當即關閉TCP鏈接，若是ACK報文丟失，A收不到B重傳的ACK+FIN，也就不會重傳ACK確認報文段，這樣B應用進程的TCP鏈接就沒法關閉。

另外一方面，是防止上一節三次握手過程當中的無效的因爲網絡緣由遲到的鏈接請求報文出如今本鏈接過程當中。A發送完最後一個ACK確認報文段後，等待2MSL時間，就會使本鏈接持續時間內所產生的全部報文段都從網絡中消失。