TCP的三次握手四次揮手，估計大家都聽過。但是真的能把每一步說明白的人比較少。我還記得在之前面試的時候被面試官一頓問，然后一臉懵B... 都是大學沒好好上課 ，這篇文章就跟大家講講到底這三握四揮是在搞什么飛機。

三次握手

握手是指的雙方進行連接的操作。

三次握手（圖片來自網絡）

為什么是三次握手

確認通信能力

我們要明白，如果需要進行通信，首先需要保證的是雙方都具有發信和收信能力。在不知雙方能力狀態下進行的通信都是無法保證可靠性和通信效率的。那么通信雙方如何確認對方的通信能力呢？

A請求B進行連接。（B已確認B的收信能力和A的發信能力）

B返回ACK相應。（A已確認雙方的收發能力）

A返回ACK并建立連接。（B確認雙方收發能力） 上面可以看到，至少是進行三次握手，才能確認雙方能力。

防止產生臟數據連接

網絡通信情況復雜，不可能保證每一消息都能正常到達其目的地。在TCP連接中，TTL的網絡報文的生存時間一般都會比TCP的連接超時時間要長。這樣就有可能出現一個問題。A在發送第一次連接請求時，可能網絡擁塞，導致數據包未短時間內到達。到達超時時間后，A又發送了一次連接請求，這次正常進行連接。連接結束斷開后，A的第一次連接請求到達B，B返回ack。如果是兩次握手，A通過當前的狀態，直接拒絕B的請求，但B會單方面認為連接已經建立，實際上并不是...

每一次握手到底是傳輸了什么？

想知道除了ip和端口號，每次傳輸的信息是什么，我們首先得知道TCP傳輸信息的結構。

TCP報文結構（圖片來源于網絡）

第一次握手

• 首先會將TCP的header部分的控制位（上圖的flags）中的SYN置為1。表示希望建立連接。
• 還有一個重要的數據，seq，即序號。這個東西是干嘛用的呢？這個涉及到TCP安全性和可靠性，與ack即確認號緊密相關。TCP在傳輸數據時，如果數據比較大，會進行拆分操作，將大數據拆成一個個小的數據包。序號就是在這個時候用的。我們必須要知道這個包的順序是什么，才能把真正的數據在服務端還原。seq的順序并不是從0或者1開始的，而是一個隨機值。因為如果序號從1開始，那么整個通信的過程非常容易被預測。正因為是隨機的，所以對方不知道你的seq，所以我們需要在開始收發數據之前，將seq先發送給對方。序號的初始值的傳遞就是通過SYN=1的操作傳遞的。

客戶端此時處于同步狀態，即可以建立連接。服務端處于監聽狀態。

第二次握手

• 標志位。因為已經收到了客戶端的建立連接請求。所以必須要發送ack，以告知客戶端自己已經收到消息。所以ACK的標志位要置為1，且SYN也是1，因為還未建立連接。
• seq。同第一次握手一樣，也是一個隨機值（TCP為全雙工，所以雙方都需要保留seq方便處理數據包）。
• ack。是對客戶端發過來的序列號進行計算得到的。

服務端處于SYN接收狀態。

第三次握手

• 標志位。此時只需要ACK=1。SYN已經不需要了，雙方已經同步完seq等信息。
• seq。可以說是第二次握手收到的ack。
• ack。是對第二次握手收到的序列號進行計算得到的。用以告知已收到二次握手信息。

客戶端處于連接建立狀態，服務端收到信息之后也會進入連接建立狀態，雙方可以進行通信。

四次揮手

TCP連接在數據傳輸完成之后需要關閉，不然會一直占用系統資源。TCP的連接關閉需要四次通信才行，分手也是個麻煩事兒。

為什么四次才能斷開連接呢？

分手這件事情，兩邊都說明白，分別斷開即可。但是想要確認對方都要斷開，那么一次兩次是不夠的。

四次揮手（圖片來自網絡）

我們還是拿A、B來舉例。假設A要主動斷開和B的連接。

A發送斷開請求。（需要等待B的回復，不然B未收到消息 就單方面的斷開有點不負責任。超時重傳）

B收到請求并回復A。（B收到請求后，很傷心，但是沒有辦法，只能斷開連接，但是B是被動的接收斷開，所以需要通知其應用程序做關閉準備）

B這邊準備完了，通知A可以斷開了。

A回復B，我收到消息了，斷開連接吧。

請求發送的信息是什么？

關閉連接抓包

關閉由哪方開始？

答案是哪邊都可以，無論是客戶端還是服務器端，都可以主動發起關閉請求。發起關閉請求的前提是數據發送完畢，不一定非得等待對方確認完成。

第一次揮手

假設客戶端發起關閉請求。那么客戶端發完消息后，會進入FIN_WAIT階段。此處已經無法再發送應用程序消息，只能處理關閉相關信息。

第二次揮手

服務端收到第一次揮手消息后，返回收到消息的ack。服務端會進入CLOSE_WAIT階段。這個階段是等待關閉階段，通知應用程序發送剩余數據，處理現場信息，關閉相應資源。

第三次揮手

你應該有點好奇為什么第三次揮手和第二次揮手都是同一個服務。第二次主要是一個ack響應，第三次主要是一個服務端關閉通知消息。兩者目的不同。等到三次揮手完畢，那么服務端會進入LAST_ACK狀態，即等待最后客戶端（主動發起關閉的一方）的ack確認。

第四次揮手

第四次揮手是主動發起關閉的一方A，對被動關閉一方B的FIN消息的確認。第四次信息發送完成后，A會進入TIME_WAIT階段，而不是直接刪除套接字。具體原因我們在下面講。收到第四次揮手信息后，B會直接進行關閉操作。

為什么會有TIME_WAIT？

還是那句話，網絡并不是一個理想世界，任何異常情況都有可能發生。為了保證TCP連接能夠正常關閉，主動發起關閉方不能直接刪除套接字，而是需要經過一段時間等待。這個時間一般是2MSL(Maxumun Segment Lifetime 最大報文生存時間)。原因如下

• 確認被動關閉方能夠正常進入關閉狀態。假設B未收到A最后的一個ack，會再次發送FIN消息(第三次揮手)，如果A已經CLOSE了，那么B就會一直重試發送。所以A必須要進行一段時間的等待。
• 防止失效請求。假設A關閉了此次連接，又重新在原來的端口號上開啟了新的連接。原來在網絡上發送的一些包（已失效但未超過ttl）到來之后，無法進行區分是否是正常的包，導致數據混亂。

舉個例子來證明沒有TIME_WAIT的情況。

A斷開了，并且刪除了套接字。

B沒有收到A的最后一次ack，導致FIN重發。

A重新開啟了新的套接字新的連接，但是這個套接字和之前刪除的套接字擁有相同的端口號。

B后來重發的FIN會錯誤的跑到新的套接字，導致A開始執行斷開操作。

所以TIME_WAIT也是為了防止上面的誤刪除。

總結

在并發量很高的時候，熟悉TCP的原理和參數調優變得尤為重要。我們關注的不僅僅是幾次握手、幾次揮手，也應該關注一些細節，細節決定成敗。更應該多問問為什么如此設計，能解決什么問題。

后續

后續主要是與大家分享討論一下對TCP的滑動窗口機制和可靠性保障的理解。如果有時間，可以跟大家分享一下TCP的參數等配置相關內容。

一個分享Java后端知識的原創公眾號

總結

以上是生活随笔為你收集整理的tcp 二次握手时延_一篇搞懂TCP的三次握手 四次挥手的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。