?參考答案：

我們都知道 TCP 是面向連接的，三次握手就是用來建立連接的，四次握手就是用來斷開連接的。

三次握手

先上圖：

白話文理解

1. 我能主動給你打·電話嗎？
2. 當然可以啊！那我也能給你打電話嗎？
3. 可以的呢，建?連接成功！

我們來看一下三次握手的過程：

• 一開始，客戶端和服務端都處于 CLOSED 狀態。客戶端主動打開連接，服務端被動打開連接，結束CLOSED 狀態，開始監聽，進入 LISTEN 狀態。

一次握手

• 客戶端會隨機初始化序號（client_isn），將此序號置于 TCP 首部的「序號」字段中，同時把 SYN 標志位置為 1 ，表示 SYN 報文。接著把第一個 SYN 報文發送給服務端，表示向服務端發起連接，該報文不包含應用層數據，之后客戶端處于 SYN-SENT 狀態。

二次握手

• 服務端收到客戶端的 SYN 報文后，首先服務端也隨機初始化自己的序號（server_isn），將此序號填入 TCP 首部的「序號」字段中，其次把 TCP 首部的「確認應答號」字段填入 client_isn + 1, 接著把 SYN 和 ACK 標志位置為 1。最后把該報文發給客戶端，該報文也不包含應用層數據，之后服務端處于 SYN-RCVD 狀態。

三次握手

• 客戶端收到服務端報文后，還要向服務端回應最后一個應答報文，首先該應答報文 TCP 首部 ACK 標志位置為 1 ，其次「確認應答號」字段填入 server_isn + 1 ，最后把報文發送給服務端，這次報文可以攜帶客戶到服務器的數據，之后客戶端處于 ESTABLISHED 狀態。

好了，經過三次握手的過程，客戶端和服務端之間的確定連接正常，接下來進入ESTABLISHED狀態，服務端和客戶端就可以快樂地通信了。

這里有個動態過程的圖示：

這里有個小細節，第三次握手是可以攜帶數據的，這是面試常問的點。

那么為什么要三次握手呢？兩次不行嗎？

• 為了防止服務器端開啟一些無用的連接增加服務器開銷
• 防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤。

由于網絡傳輸是有延時的(要通過網絡光纖和各種中間代理服務器)，在傳輸的過程中，比如客戶端發起了 SYN=1 的第一次握手。

如果服務器端就直接創建了這個連接并返回包含 SYN、ACK 和 Seq 等內容的數據包給客戶端，這個數據包因為網絡傳輸的原因丟失了，丟失之后客戶端就一直沒有接收到服務器返回的數據包。

如果沒有第三次握手告訴服務器端客戶端收的到服務器端傳輸的數據的話，服務器端是不知道客戶端有沒有接收到服務器端返回的信息的。服務端就認為這個連接是可用的，端口就一直開著，等到客戶端因超時重新發出請求時，服務器就會重新開啟一個端口連接。

這樣一來，就會有很多無效的連接端口白白地開著，導致資源的浪費。

這個過程可理解為：

還有一種情況是已經失效的客戶端發出的請求信息，由于某種原因傳輸到了服務器端，服務器端以為是客戶端發出的有效請求，接收后產生錯誤。

所以我們需要“第三次握手”來確認這個過程：

通過第三次握手的數據告訴服務端，客戶端有沒有收到服務器“第二次握手”時傳過去的數據，以及這個連接的序號是不是有效的。若發送的這個數據是“收到且沒有問題”的信息，接收后服務器就正常建立 TCP 連接，否則建立 TCP 連接失敗，服務器關閉連接端口。由此減少服務器開銷和接收到失效請求發生的錯誤。

數據傳輸?

四次揮手?

白話文理解

1. 我們分?吧
2. 收到分?的信息
3. 好吧，分就分吧
4. ?，那就到這?了

為了防?最終的 ACK 丟失，發送 ACK 后需要等待?段時間，因為如果丟包服務端需要重新發送 FIN 包，如果

客戶端已經 closed ，那么服務端會將結果解析成錯誤。 從?在?并發??連接的場景下會有?量端?被占

?

雙方都可以主動斷開連接，斷開連接后主機中的「資源」將被釋放。

上圖是客戶端主動關閉連接 ：

一次揮手

• 客戶端打算關閉連接，此時會發送一個 TCP 首部 FIN 標志位被置為 1 的報文，也即 FIN 報文，之后客戶端進入 FIN_WAIT_1 狀態。

二次揮手

• 服務端收到該報文后，就向客戶端發送 ACK 應答報文，接著服務端進入 CLOSED_WAIT 狀態。

三次揮手

• 客戶端收到服務端的 ACK 應答報文后，之后進入 FIN_WAIT_2 狀態。等待服務端處理完數據后，也向客戶端發送 FIN 報文，之后服務端進入 LAST_ACK 狀態。

四次揮手

• 客戶端收到服務端的 FIN 報文后，回一個 ACK 應答報文，之后進入 TIME_WAIT 狀態
• 服務器收到了 ACK 應答報文后，就進入了 CLOSED 狀態，至此服務端已經完成連接的關閉。
• 客戶端在經過 2MSL 一段時間后，自動進入 CLOSED 狀態，至此客戶端也完成連接的關閉。

每個方向都需要一個 FIN 和一個 ACK，因此通常被稱為四次揮手。

為什么要揮手四次？?

• 關閉連接時，客戶端向服務端發送 FIN 時，僅僅表示客戶端不再發送數據了但是還能接收數據。
• 服務器收到客戶端的 FIN 報文時，先回一個 ACK 應答報文，而服務端可能還有數據需要處理和發送，等服務端不再發送數據時，才發送 FIN 報文給客戶端來表示同意現在關閉連接。

從上面過程可知，服務端通常需要等待完成數據的發送和處理，所以服務端的 ACK 和 FIN 一般都會分開發送，從而比三次握手導致多了一次。

為什么客戶端在 TIME-WAIT 階段要等 2MSL？?

為的是確認服務器端是否收到客戶端發出的 ACK 確認報文，當客戶端發出最后的 ACK 確認報文時，并不能確定服務器端能夠收到該段報文。

所以客戶端在發送完 ACK 確認報文之后，會設置一個時長為 2MSL 的計時器。

MSL 指的是 Maximum Segment Lifetime：一段 TCP 報文在傳輸過程中的最大生命周期。

2MSL 即是服務器端發出為 FIN 報文和客戶端發出的 ACK 確認報文所能保持有效的最大時長。

服務器端在 1MSL 內沒有收到客戶端發出的 ACK 確認報文，就會再次向客戶端發出 FIN 報文：

• 如果客戶端在 2MSL 內，再次收到了來自服務器端的 FIN 報文，說明服務器端由于各種原因沒有接收到客戶端發出的 ACK 確認報文。

客戶端再次向服務器端發出 ACK 確認報文，計時器重置，重新開始 2MSL 的計時。

• 否則客戶端在 2MSL 內沒有再次收到來自服務器端的 FIN 報文，說明服務器端正常接收了 ACK 確認報文，客戶端可以進入 CLOSED 階段，完成“四次揮手”。

所以，客戶端要經歷時長為 2SML 的 TIME-WAIT 階段;這也是為什么客戶端比服務器端晚進入 CLOSED 階段的原因。

這里同樣有個動態過程的圖示：

文章出自：??前端餐廳???，如有轉載本文請聯系前端餐廳ReTech今日頭條號。

github：https://github.com/zuopf769