TCP的三次握手與四次揮手理解

• TCP的三次握手與四次揮手理解
  • 一、TCP三次握手
    • 1.1 三次握手過程
    • 1.2 三次握手過程分析
  • 二、TCP四次揮手
    • 2.1 四次揮手過程
    • 2.2 四次揮手過程分析
  • 三、常見問題

一、TCP三次握手

1.1 三次握手過程

建立TCP連線時，需要客戶端和伺服器共傳送3個包。

• 第一次：客戶端傳送初始序號x和syn=1請求標誌
• 第二次：伺服器傳送請求標誌syn，傳送確認標誌ACK，傳送自己的序號seq=y，傳送客戶端的確認序號ack=x+1
• 第三次：客戶端傳送ACK確認號，傳送自己的序號seq=x+1，傳送對方的確認號ack=y+1

1.2 三次握手過程分析

• 第一次：客戶端傳送請求到伺服器，伺服器知道客戶端傳送，自己接收正常。SYN=1,seq=x
• 第二次：伺服器發給客戶端，客戶端知道自己傳送、接收正常，伺服器接收、傳送正常。ACK=1,ack=x+1,SYN=1,seq=y
• 第三次：客戶端發給伺服器：伺服器知道客戶端傳送，接收正常，自己接收，傳送也正常.seq=x+1,ACK=1,ack=y+1

上面分析過程可以看出，握手兩次達不到讓雙方都得出自己、對方的接收、傳送能力都正常的結論的。

二、TCP四次揮手

2.1 四次揮手過程

• 第一次揮手：客戶端發出釋放FIN=1，自己序列號seq=u，進入FIN-WAIT-1狀態
• 第二次揮手：伺服器收到客戶端的後，發出ACK=1確認標誌和客戶端的確認號ack=u+1，自己的序列號seq=v，進入CLOSE-WAIT狀態
• 第三次揮手：客戶端收到伺服器確認結果後，進入FIN-WAIT-2狀態。此時伺服器傳送釋放FIN=1訊號，確認標誌ACK=1，確認序號ack=u+1，自己序號seq=w，伺服器進入LAST-ACK（最後確認態）
• 第四次揮手：客戶端收到回覆後，傳送確認ACK=1，ack=w+1，自己的seq=u+1，客戶端進入TIME-WAIT（時間等待）。客戶端經過2個最長報文段壽命後，客戶端CLOSE；伺服器收到確認後，立刻進入CLOSE狀態。

2.2 四次揮手過程分析

• 第一次：客戶端請求斷開FIN,seq=u
• 第二次：伺服器確認客戶端的斷開請求ACK,ack=u+1,seq=v
• 第三次：伺服器請求斷開FIN,seq=w,ACK,ack=u+1
• 第四次：客戶端確認伺服器的斷開ACK,ack=w+1,seq=u+1

三、常見問題

【問題1】為什麼連線的時候是三次握手，關閉的時候卻是四次握手？

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

【問題2】為什麼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】為什麼不能用兩次握手進行連線？

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

現在把三次握手改成僅需要兩次握手，死鎖是可能發生的。作為例子，考慮計算機S和C之間的通訊，假定C給S傳送一個連線請求分組，S收到了這個分組，併發送了確認應答分組。按照兩次握手的協定，S認為連線已經成功地建立了，可以開始傳送資料分組。可是，C在S的應答分組在傳輸中被丟失的情況下，將不知道S 是否已準備好，不知道S建立什麼樣的序列號，C甚至懷疑S是否收到自己的連線請求分組。在這種情況下，C認為連線還未建立成功，將忽略S發來的任何資料分 組，只等待連線確認應答分組。而S在發出的分組超時後，重複傳送同樣的分組。這樣就形成了死鎖。

【問題4】如果已經建立了連線，但是客戶端突然出現故障了怎麼辦？

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