TCP的三次握手與四次揮手

• 2019 年 10 月 3 日
• 筆記

TCP報文段的首部格式

序列號seq：佔4個位元組，用來標記數據段的順序，TCP把連接中發送的所有數據位元組都編上一個序號，第一個位元組的編號由本地隨機產生；給位元組編上序號後，就給每一個報文段指派一個序號；序列號seq就是這個報文段中的第一個位元組的數據編號。

確認號ack：佔4個位元組，期待收到對方下一個報文段的第一個數據位元組的序號；序列號表示報文段攜帶數據的第一個位元組的編號；而確認號指的是期望接收到下一個位元組的編號；因此當前報文段最後一個位元組的編號+1即為確認號。

確認ACK：佔1位，僅當ACK=1時，確認號欄位才有效。ACK=0時，確認號無效。TCP規定，在連接建立後所有傳送的報文段都必須把ACK置為1。

同步SYN：連接建立時用於同步序號。當SYN=1，ACK=0時表示：這是一個連接請求報文段。若同意連接，則在響應報文段中使得SYN=1，ACK=1。因此，SYN=1表示這是一個連接請求，或連接接受報文。SYN這個標誌位只有在TCP建產連接時才會被置1，握手完成後SYN標誌位被置0。

終止FIN：用來釋放一個連接。FIN=1表示：此報文段的發送方的數據已經發送完畢，並要求釋放運輸連接

PS：ACK、SYN和FIN這些大寫的單詞表示標誌位，其值要麼是1，要麼是0；ack、seq小寫的單詞表示序號。

TCP三次握手

第一次握手：建立連接時，客戶端發送syn包（syn=j）到伺服器，並進入SYN_SENT狀態，等待伺服器確認；SYN：同步序列編號（Synchronize Sequence Numbers）。

第二次握手：伺服器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時伺服器進入SYN_RECV狀態；

第三次握手：客戶端收到伺服器的SYN+ACK包，向伺服器發送確認包ACK(ack=k+1），此包發送完畢，客戶端和伺服器進入ESTABLISHED（TCP連接成功）狀態，完成三次握手

TCP四次揮手

1）客戶端進程發出連接釋放報文，並且停止發送數據。釋放數據報文首部，FIN=1，其序列號為seq=u（等於前面已經傳送過來的數據的最後一個位元組的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態。 TCP規定，FIN報文段即使不攜帶數據，也要消耗一個序號。

2）伺服器收到連接釋放報文，發出確認報文，ACK=1，ack=u+1，並且帶上自己的序列號seq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態。TCP伺服器通知高層的應用進程，客戶端向伺服器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了，但是伺服器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。

3）客戶端收到伺服器的確認請求後，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態，等待伺服器發送連接釋放報文（在這之前還需要接受伺服器發送的最後的數據）。

4）伺服器將最後的數據發送完畢後，就向客戶端發送連接釋放報文，FIN=1，ack=u+1，由於在半關閉狀態，伺服器很可能又發送了一些數據，假定此時的序列號為seq=w，此時，伺服器就進入了LAST-ACK（最後確認）狀態，等待客戶端的確認。

5）客戶端收到伺服器的連接釋放報文後，必須發出確認，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態。注意此時TCP連接還沒有釋放，必須經過2∗∗MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的TCB後，才進入CLOSED狀態。

6）伺服器只要收到了客戶端發出的確認，立即進入CLOSED狀態。同樣，撤銷TCB後，就結束了這次的TCP連接。可以看到，伺服器結束TCP連接的時間要比客戶端早一些。

常見面試題

1. 為什麼連接的時候是三次握手，關閉的時候卻是四次握手？

因為當Server端收到Client端的SYN連接請求報文後，可以直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連接時，當Server端收到FIN報文時，很可能並不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端所有的報文都發送完了，我才能發送FIN報文，因此不能一起發送。故需要四步握手。

2. 為什麼不能用兩次握手進行連接？

這主要是為了防止已失效的連接請求報文段突然又傳到了B，因而產生錯誤。

現假定一種異常情況，即A發出的第一個連接請求報文段並沒有丟失，而是在某些網路節點長時間滯留了，以致延誤到連接釋放後的某個時間才到達B。本來這是一個早已失效的報文段。但B受到此失效的連接請求報文段後，就誤以為是A又發出一次新的連接請求，於是就向A發出確認報文段，同意建立連接。假定不採用第三次報文握手，那麼只要B發出確認，新的連接就建立了。

由於現在A並沒有發出建立連接的請求，因此不會理睬B的確認，也不會向B發送數據，但B卻以為新的運輸連接已經建立了，並一直等待A發來的數據。B的許多資源就這樣白白浪費了。

採用三次握手連接，可以防止上述現象的發生。例如在剛才的異常情況下，A不會向B的確認發出確認，B由於收不到確認，就知道A並沒有要求建立連接，於是B就不會再建立連接。

3. 為什麼TIME_WAIT狀態需要經過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？

• 第一，為了保證A發送的最後一個ACK報文段能夠到達B。假設網路是不可靠的，有可以最後一個ACK丟失。所以TIME_WAIT狀態就是用來重發可能丟失的ACK報文。在Client發送出最後的ACK回復，但該ACK可能丟失。Server如果沒有收到ACK，將不斷重複發送FIN片段。所以Client不能立即關閉，它必須確認Server接收到了該ACK。Client會在發送出ACK之後進入到TIME_WAIT狀態。Client會設置一個計時器，等待2MSL的時間。如果在該時間內再次收到FIN，那麼Client會重發ACK並再次等待2MSL。所謂的2MSL是兩倍的MSL(Maximum Segment Lifetime)。MSL指一個片段在網路中最大的存活時間，2MSL就是一個發送和一個回復所需的最大時間。如果直到2MSL，Client都沒有再次收到FIN，那麼Client推斷ACK已經被Server成功接收，則結束TCP連接。
• 第二，防止「已失效的連接請求報文段」出現在本連接中。A在發送完最後一個ACK報文段後，再經過時間2MSL，就可以使本連接持續的時間內所產生的所有報文段都從網路中消失。這樣就可以使下一個新的連接中不會出現這種舊的連接請求報文段。

4. 如果已經建立了連接，但是客戶端突然出現故障了怎麼辦？

TCP還設有一個保活計時器，顯然，客戶端如果出現故障，伺服器不能一直等下去，白白浪費資源。伺服器每收到一次客戶端的請求後都會重新複位這個計時器，時間通常是設置為2小時，若兩小時還沒有收到客戶端的任何數據，伺服器就會發送一個探測報文段，以後每隔75分鐘發送一次。若一連發送10個探測報文仍然沒反應，伺服器就認為客戶端出了故障，接著就關閉連接。