?參考答案：

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

三次握手

先上圖：

白話文理解

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

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

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

一次握手

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

二次握手

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

三次握手

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

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

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

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

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

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

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

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

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

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

這個(gè)過程可理解為：

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

所以我們需要“第三次握手”來確認(rèn)這個(gè)過程：

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

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

四次揮手?

白話文理解

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

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

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

?

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

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

一次揮手

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

二次揮手

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

三次揮手

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

四次揮手

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

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

為什么要揮手四次？?

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

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

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

為的是確認(rèn)服務(wù)器端是否收到客戶端發(fā)出的 ACK 確認(rèn)報(bào)文，當(dāng)客戶端發(fā)出最后的 ACK 確認(rèn)報(bào)文時(shí)，并不能確定服務(wù)器端能夠收到該段報(bào)文。

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

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

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

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

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

客戶端再次向服務(wù)器端發(fā)出 ACK 確認(rèn)報(bào)文，計(jì)時(shí)器重置，重新開始 2MSL 的計(jì)時(shí)。

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

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

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

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

github：https://github.com/zuopf769