面試必問：TCP 的三次握手與四次揮手，你真的搞懂了嗎？

時間 2020-12-03

原文原文鏈接

請看圖：程序員

序列號seq：佔4個字節，用來標記數據段的順序，TCP把鏈接中發送的全部數據字節都編上一個序號，第一個字節的編號由本地隨機產生；給字節編上序號後，就給每個報文段指派一個序號；序列號seq就是這個報文段中的第一個字節的數據編號。面試

確認號ack：佔4個字節，期待收到對方下一個報文段的第一個數據字節的序號；序列號表示報文段攜帶數據的第一個字節的編號；而確認號指的是指望接收到下一個字節的編號；所以當前報文段最後一個字節的編號+1即爲確認號。算法

確認ACK：佔1位，僅當ACK=1時，確認號字段纔有效。ACK=0時，確認號無效安全

同步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小寫的單詞表示序號。

三次握手過程理解

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

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

第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=k+1），此包發送完畢，客戶端和服務器進入ESTABLISHED（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鏈接的時間要比客戶端早一些。

常見面試題

爲何鏈接的時候是三次握手，關閉的時候倒是四次握手？

答：由於當Server端收到Client端的SYN鏈接請求報文後，能夠直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。可是關閉鏈接時，當Server端收到FIN報文時，極可能並不會當即關閉SOCKET，因此只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端全部的報文都發送完了，我才能發送FIN報文，所以不能一塊兒發送。故須要四步握手。

爲何TIME_WAIT狀態須要通過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？

答：雖然按道理，四個報文都發送完畢，咱們能夠直接進入CLOSE狀態了，可是咱們必須假象網絡是不可靠的，有能夠最後一個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已經被成功接收，則結束TCP鏈接。

爲何不能用兩次握手進行鏈接？

答：3次握手完成兩個重要的功能，既要雙方作好發送數據的準備工做(雙方都知道彼此已準備好)，也要容許雙方就初始序列號進行協商，這個序列號在握手過程當中被髮送和確認。

如今把三次握手改爲僅須要兩次握手，死鎖是可能發生的。做爲例子，考慮計算機S和C之間的通訊，假定C給S發送一個鏈接請求分組，S收到了這個分組，併發送了確認應答分組。按照兩次握手的協定，S認爲鏈接已經成功地創建了，能夠開始發送數據分組。

但是，C在S的應答分組在傳輸中被丟失的狀況下，將不知道S 是否已準備好，不知道S創建什麼樣的序列號，C甚至懷疑S是否收到本身的鏈接請求分組。在這種狀況下，C認爲鏈接還未創建成功，將忽略S發來的任何數據分組，只等待鏈接確認應答分組。而S在發出的分組超時後，重複發送一樣的分組。這樣就造成了死鎖。

若是已經創建了鏈接，可是客戶端忽然出現故障了怎麼辦？

答：TCP還設有一個保活計時器，顯然，客戶端若是出現故障，服務器不能一直等下去，白白浪費資源。服務器每收到一次客戶端的請求後都會從新復位這個計時器，時間一般是設置爲2小時，若兩小時尚未收到客戶端的任何數據，服務器就會發送一個探測報文段，之後每隔75分鐘發送一次。若一連發送10個探測報文仍然沒反應，服務器就認爲客戶端出了故障，接着就關閉鏈接。