?參考答案：

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

三次握手

先上圖：

白話文理解

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

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

• 一開始，客戶端和服務(wù)端都處于 CLOSED 狀態(tài)。客戶端主動打開連接，服務(wù)端被動打開連接，結(jié)束CLOSED 狀態(tài)，開始監(jiān)聽，進入 LISTEN 狀態(tài)。

一次握手

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

二次握手

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

三次握手

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

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

這里有個動態(tài)過程的圖示：

這里有個小細節(jié)，第三次握手是可以攜帶數(shù)據(jù)的，這是面試常問的點。

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

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

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

如果服務(wù)器端就直接創(chuàng)建了這個連接并返回包含 SYN、ACK 和 Seq 等內(nèi)容的數(shù)據(jù)包給客戶端，這個數(shù)據(jù)包因為網(wǎng)絡(luò)傳輸?shù)脑騺G失了，丟失之后客戶端就一直沒有接收到服務(wù)器返回的數(shù)據(jù)包。

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

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

這個過程可理解為：

還有一種情況是已經(jīng)失效的客戶端發(fā)出的請求信息，由于某種原因傳輸?shù)搅朔?wù)器端，服務(wù)器端以為是客戶端發(fā)出的有效請求，接收后產(chǎn)生錯誤。

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

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

數(shù)據(jù)傳輸?

四次揮手?

白話文理解

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

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

客戶端已經(jīng) closed ，那么服務(wù)端會將結(jié)果解析成錯誤。 從?在?并發(fā)??連接的場景下會有?量端?被占

?

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

上圖是客戶端主動關(guān)閉連接 ：

一次揮手

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

二次揮手

• 服務(wù)端收到該報文后，就向客戶端發(fā)送 ACK 應(yīng)答報文，接著服務(wù)端進入 CLOSED_WAIT 狀態(tài)。

三次揮手

• 客戶端收到服務(wù)端的 ACK 應(yīng)答報文后，之后進入 FIN_WAIT_2 狀態(tài)。等待服務(wù)端處理完數(shù)據(jù)后，也向客戶端發(fā)送 FIN 報文，之后服務(wù)端進入 LAST_ACK 狀態(tài)。

四次揮手

• 客戶端收到服務(wù)端的 FIN 報文后，回一個 ACK 應(yīng)答報文，之后進入 TIME_WAIT 狀態(tài)
• 服務(wù)器收到了 ACK 應(yīng)答報文后，就進入了 CLOSED 狀態(tài)，至此服務(wù)端已經(jīng)完成連接的關(guān)閉。
• 客戶端在經(jīng)過 2MSL 一段時間后，自動進入 CLOSED 狀態(tài)，至此客戶端也完成連接的關(guān)閉。

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

為什么要揮手四次？?

• 關(guān)閉連接時，客戶端向服務(wù)端發(fā)送 FIN 時，僅僅表示客戶端不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù)。
• 服務(wù)器收到客戶端的 FIN 報文時，先回一個 ACK 應(yīng)答報文，而服務(wù)端可能還有數(shù)據(jù)需要處理和發(fā)送，等服務(wù)端不再發(fā)送數(shù)據(jù)時，才發(fā)送 FIN 報文給客戶端來表示同意現(xiàn)在關(guān)閉連接。

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

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

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

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

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

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

服務(wù)器端在 1MSL 內(nèi)沒有收到客戶端發(fā)出的 ACK 確認報文，就會再次向客戶端發(fā)出 FIN 報文：

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

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

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

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

這里同樣有個動態(tài)過程的圖示：

文章出自：??前端餐廳???，如有轉(zhuǎn)載本文請聯(lián)系前端餐廳ReTech今日頭條號。

github：https://github.com/zuopf769