TCP 特性

• • 1.確認(rèn)應(yīng)答機(jī)制 (ACK)
  • 2.超時(shí)重傳
  • 3.1建立連接 - 三次握手 ▲
  • 3.2.斷開連接 - 四次揮手 ▲

1.確認(rèn)應(yīng)答機(jī)制 (ACK)

確認(rèn)應(yīng)答是可靠傳輸?shù)淖詈诵臋C(jī)制
接收方反饋一個(gè)應(yīng)答報(bào)文(ACK)，表示已收到

假設(shè)現(xiàn)在 A 想去 B 家里玩游戲，于是 A 給 B 發(fā)消息，若消息沒(méi)有出現(xiàn)錯(cuò)誤且順序正確
結(jié)果如下所示:

但網(wǎng)絡(luò)傳輸比較復(fù)雜，可能存在一種情況"后發(fā)先至"
由于數(shù)據(jù)的長(zhǎng)度不同或者傳輸網(wǎng)絡(luò)不同，先發(fā)送的數(shù)據(jù)不一定先到達(dá)，接收方接收到的數(shù)據(jù)可能是亂序的，如圖：

當(dāng) B 回復(fù) A 的消息時(shí)，若存在對(duì)應(yīng)關(guān)系，那么即使出現(xiàn)了"后發(fā)先至"的情況，也能順利的確立應(yīng)答

上述方法，雖然可以順利的確立應(yīng)答，但額外的信息很多，占用的帶寬很多

下面如圖，針對(duì)發(fā)送的請(qǐng)求進(jìn)行編號(hào)，應(yīng)答的時(shí)候也針對(duì)編號(hào)進(jìn)行應(yīng)答，這樣既能保證數(shù)據(jù)傳輸沒(méi)有歧義，也不會(huì)浪費(fèi)太多的空間和帶寬

序號(hào)和確定序號(hào)，在前面 TCP報(bào)文格式中提到過(guò)

上述情況不嚴(yán)謹(jǐn)，真實(shí)的 TCP 還不一樣，TCP 是面向字節(jié)流的，此處的編號(hào)并不是按照一條兩條來(lái)編的，而是按照字節(jié)來(lái)編號(hào)的 (每個(gè)字節(jié)有一個(gè)編號(hào))

確認(rèn)應(yīng)答是一種特殊的報(bào)文(ACK)，所謂的應(yīng)答報(bào)文，本質(zhì)上就是 ACK 字段為1 的報(bào)文，此時(shí)報(bào)頭中的"確認(rèn)序號(hào)"字段才是生效的

初始序號(hào)是隨機(jī)的，為了防止網(wǎng)絡(luò)攻擊；如果發(fā)送多個(gè)數(shù)據(jù)，每個(gè)數(shù)據(jù)都會(huì)帶著一個(gè)序號(hào)
接收方收到數(shù)據(jù)后，是知道數(shù)據(jù)所帶著的序號(hào)的，根據(jù)序號(hào)給出確認(rèn)序號(hào)(告訴發(fā)送方下次給我發(fā)的序號(hào))，發(fā)送給發(fā)送方，發(fā)送方就知道接收方收到了哪些數(shù)據(jù)

2.超時(shí)重傳

確認(rèn)應(yīng)答是比較理想的情況，但數(shù)據(jù)在傳輸過(guò)程中，可能是會(huì)丟包的

仍以上面例子為例，A 給 B 發(fā)消息，你在家嘛？等了很久，A 也沒(méi)收到 B 的消息，此時(shí)，存在以下幾種情況：
① B 不想回 A 的消息
② B 沒(méi)收到 A 的消息 (丟包情況1: 發(fā)的請(qǐng)求丟失)
③ B 回復(fù)了消息，但 A 沒(méi)收到 (丟包情況2: 應(yīng)答的 ACK 丟失)

②③情況：丟包的兩種情況，對(duì)于發(fā)送方來(lái)說(shuō)無(wú)法確定是哪種情況，因此，進(jìn)行統(tǒng)一處理：當(dāng)發(fā)送了一條數(shù)據(jù)之后，TCP 內(nèi)部就會(huì)自動(dòng)啟動(dòng)一個(gè)定時(shí)器，達(dá)到一定時(shí)間也沒(méi)收到 ACK，定時(shí)器就會(huì)自動(dòng)觸發(fā)重傳消息的動(dòng)作 —— 超時(shí)重傳
①情況：

思考：
假設(shè)第二次重發(fā)沒(méi)有成功，那么就存在兩個(gè)超時(shí)時(shí)間 t1，t2 如圖所示：
那么，t1 和 t2 時(shí)間一樣長(zhǎng)嗎？？

在 TCP 中，t2 會(huì)比 t1 更長(zhǎng)
TCP 抱著一種 “悲觀的態(tài)度”，當(dāng)一次丟包重傳之后，TCP 就覺(jué)得大概率后面的重傳也沒(méi)用，所以就隔一個(gè)更長(zhǎng)的時(shí)間，節(jié)省帶寬

上述丟包有兩種情況，一種是請(qǐng)求丟失 —— 重傳沒(méi)有問(wèn)題；一種是 ACK 丟失，重傳就意味著接收方收到了相同的數(shù)據(jù)
TCP 會(huì)在內(nèi)部進(jìn)行數(shù)據(jù)去重 (以序號(hào)為 key 進(jìn)行去重)，保證應(yīng)用層讀到的數(shù)據(jù)不是重復(fù)數(shù)據(jù)

確認(rèn)應(yīng)答 和 超時(shí)重傳是 TCP 可靠性中最核心的機(jī)制

3.1建立連接 - 三次握手 ▲

為什么要就建立連接？
1.更好的保證可靠性: 建立連接的過(guò)程其實(shí)就是讓通信雙方驗(yàn)證各自的發(fā)送能力和接受能力是否正常
2.協(xié)商一些重要參數(shù) (如: 序號(hào)的初始值)

具體怎樣建立連接？
舉例：A 給 B 打電話，打電話同樣要驗(yàn)證自己以及對(duì)方的話筒和聽筒是否正常工作

第一次握手： 剛開始，A 不知道自己和 B 手機(jī)的聽筒和話筒是否正常，所以 A說(shuō)"喂，你能聽到嗎?"
第二次握手： B 聽到后，說(shuō)明 A 的話筒和 B 的聽筒正常，但 B 還需進(jìn)一步檢查自己的話筒和 A 的聽筒是否正常；同時(shí) B 把 A 話筒正常和自己聽筒正常的消息傳遞給 A；于是 B “我能聽到，你呢？”
第三次握手： A 收到 B 的消息后，就證明了 A 聽筒正常，B 話筒正常

以上三次握手就保證了 A、B 的聽筒和話筒都正常，也就保證了通話的正常，這就類似于網(wǎng)絡(luò)建立連接時(shí)的三次握手

TCP 中真實(shí)的建立連接過(guò)程： (假設(shè)主機(jī) A 主動(dòng)發(fā)起連接)

• 第一次握手： 客戶端向服務(wù)器發(fā)送 SYN 報(bào)文 (SEQ=x，SYN=1)，并進(jìn)入 SYN_SENT 狀態(tài)，等待服務(wù)器確認(rèn)

• 第二次握手： 實(shí)際上是分兩部分來(lái)完成的，即 SYN+ACK (請(qǐng)求和確認(rèn)) 報(bào)文
  服務(wù)器收到了客戶端的請(qǐng)求，向客戶端回復(fù)一個(gè)確認(rèn)信息 (ack=x+1)
  服務(wù)器再向客戶端發(fā)送一個(gè) SYN 包 (SEQ=y)建立連接的請(qǐng)求，此時(shí)服務(wù)器進(jìn)入 SYN_RECV 狀態(tài)

• 第三次握手： 客戶端收到服務(wù)器的回復(fù) (SYN+ACK 報(bào)文0)；此時(shí)，客戶端也要向服務(wù)器發(fā)送確認(rèn)包 (ACK)；此包發(fā)送完畢客戶端和服務(wù)器進(jìn)入 ESTABLISHED 狀態(tài)，完成 3 次握手

建立連接的過(guò)程，相當(dāng)于通信雙方各自給對(duì)方發(fā)送 SYN，在各自給對(duì)方發(fā)送給 ACK，只不過(guò)中間的 ACK 和 SYN 合二為一了，于是最后就是"三次握手"

幾個(gè)重要的狀態(tài):

• LISTEN: 正在偵聽來(lái)自遠(yuǎn)方的 TCP 端口的連接請(qǐng)求，服務(wù)端啟動(dòng)后處于 LISTEN 狀態(tài)用于監(jiān)聽不同客戶端的 TCP 請(qǐng)求并建立連接
• SYN_SEND / SYN_RCVD: 建立連接的中間過(guò)程，若連接順利的話(建立連接過(guò)程也可能丟包)，這兩個(gè)狀態(tài)就一瞬消失
• ESTABLISHEN: 連接建立完畢 (驗(yàn)證了通信雙方的發(fā)送和接受能力都正常)，可以進(jìn)行數(shù)據(jù)傳輸

1.兩次握手可以嗎？？
不可以

• 防止已失效的請(qǐng)求報(bào)文又傳送到了服務(wù)端，建立了多余的鏈接，浪費(fèi)資源
• 兩次握手只能保證單向連接是通暢的 (為了實(shí)現(xiàn)可靠數(shù)據(jù)傳輸， TCP 協(xié)議的通信雙方，都必須維護(hù)一個(gè)序列號(hào)，以標(biāo)識(shí)發(fā)送出去的數(shù)據(jù)包中，哪些是已經(jīng)被對(duì)方收到的；三次握手的過(guò)程即是通信雙方相互告知序列號(hào)起始值，并確認(rèn)對(duì)方已經(jīng)收到了序列號(hào)起始值的必經(jīng)步驟；如果只是兩次握手，至多只有連接發(fā)起方的起始序列號(hào)能被確認(rèn)，另一方選擇的序列號(hào)則得不到確認(rèn)）

.

2.為什么是三次？？
主要是為了建立可靠的通信通道，保證客戶端與服務(wù)端同時(shí)具備發(fā)送、接收數(shù)據(jù)的能力
.
3.四次握手可以嗎？？
可以，但沒(méi)必要
四次握手可以驗(yàn)證雙方的發(fā)送接收能力正常，但是這樣做效率比較低
.

3.2.斷開連接 - 四次揮手 ▲

三次握手: 雙方各自向?qū)Ψ桨l(fā)起建立連接的請(qǐng)求，再各自給對(duì)方回應(yīng)，只不過(guò)，中間的 SYN 和 ACK 能合并在一起
四次揮手: 雙方各自向?qū)Ψ桨l(fā)起建立連接的請(qǐng)求，再各自給對(duì)方回應(yīng)，只不過(guò)，中間的 FIN 和 ACK 不一定能合并在一起

仍以打電話為例，如下圖：

TCP 中真實(shí)的斷開連接過(guò)程： (假設(shè)主機(jī) A 主動(dòng)斷開連接)

• 第一次揮手: 客戶端向服務(wù)器端發(fā)送斷開 TCP 連接請(qǐng)求的 [FIN，ACK] 報(bào)文，在報(bào)文中隨機(jī)生成一個(gè)序列號(hào) SEQ=u，表示要斷開 TCP 連接
  此時(shí)，客戶端進(jìn)入FIN_WAIT_1 (終止等待1) 狀態(tài)
• 第二次揮手: 當(dāng)服務(wù)器端收到客戶端發(fā)來(lái)的斷開 TCP 連接的請(qǐng)求后，回復(fù)發(fā)送 ACK 報(bào)文，表示已經(jīng)收到斷開請(qǐng)求。回復(fù)時(shí)，隨機(jī)生成一個(gè)序列號(hào) SEQ=v；由于回復(fù)的是客戶端發(fā)來(lái)的請(qǐng)求，所以在客戶端請(qǐng)求序列號(hào) SEQ=u 的基礎(chǔ)上加 1，得到 ack=u+1
  此時(shí)，服務(wù)端就進(jìn)入了CLOSE_WAIT (關(guān)閉等待) 狀態(tài)，客戶端收到ACK后，就進(jìn)入FIN_WAIT_2 (終止等待2) 狀態(tài)
• 第三次揮手: 服務(wù)器端在回復(fù)完客戶端的 TCP 斷開請(qǐng)求后，不會(huì)馬上進(jìn)行 TCP 連接的斷開。服務(wù)器端會(huì)先確認(rèn)斷開前，所有傳輸?shù)娇蛻舳说臄?shù)據(jù)是否已經(jīng)傳輸完畢。確認(rèn)數(shù)據(jù)傳輸完畢后才進(jìn)行斷開，向客戶端發(fā)送 [FIN，ACK] 報(bào)文，設(shè)置字段值為 1。再次隨機(jī)生成一個(gè)序列號(hào) SEQ=w；由于還是對(duì)客戶端發(fā)來(lái)的 TCP 斷開請(qǐng)求序列號(hào) SEQ=u 進(jìn)行回復(fù)，因此 ack 依然為 u+1
  此時(shí)，服務(wù)器就進(jìn)入了LAST_ACK (最后確認(rèn)) 狀態(tài)
• 第四次揮手: 客戶端收到服務(wù)器發(fā)來(lái)的 TCP 斷開連接數(shù)據(jù)包后將進(jìn)行回復(fù)，表示收到斷開 TCP 連接數(shù)據(jù)包。向服務(wù)器發(fā)送 ACK 報(bào)文，生成一個(gè)序列號(hào) SEQ=u+1；由于回復(fù)的是服務(wù)器，所以 ACK 字段的值在服務(wù)器發(fā)來(lái)斷開 TCP 連接請(qǐng)求序列號(hào) SEQ=w 的基礎(chǔ)上加 1，得到 ack=w+1
  此時(shí)，客戶端就進(jìn)入了TIME_WAIT (時(shí)間等待) 狀態(tài)；注意此時(shí)TCP連接還沒(méi)有釋放，必須經(jīng)過(guò)2MSL (最長(zhǎng)報(bào)文段壽命) 的時(shí)間后，當(dāng)客戶端撤銷相應(yīng)的TCB后，才進(jìn)入CLOSED狀態(tài)

兩個(gè)重要的狀態(tài):

• CLOSE_WAIT: 表示在等待關(guān)閉； 四次揮手揮了一半了，當(dāng)前可能剩下的兩次不揮了(接收方?jīng)]調(diào)用 close 方法，就會(huì)導(dǎo)致四次揮手只揮兩次，從而沒(méi)有正確關(guān)閉連接)
• TIME_WAIT: 誰(shuí)主動(dòng)斷開連接，誰(shuí)進(jìn)入 TIME-WAIT 狀態(tài)，此時(shí)該主機(jī)已經(jīng)完成了四次揮手的過(guò)程，但仍不能立刻斷開連接，而是要以 TIME-WAIT 狀態(tài)來(lái)保持連接一段時(shí)間之后，再?gòu)氐揍尫胚B接 (處理最后一個(gè) ACK 丟包之后重傳的問(wèn)題)
  為了解決網(wǎng)絡(luò)的丟包和網(wǎng)絡(luò)不穩(wěn)定所帶來(lái)的其他問(wèn)題，確保連接方能在時(shí)間范圍內(nèi)，關(guān)閉自己的連接

1.四次揮手，三次揮完行不行？？
通常情況下不行，若觸發(fā)了延時(shí)應(yīng)答機(jī)制，就可以三次揮完
"不行"，即：上述的 ② ③ 為什么沒(méi)有合并在一起？？
因?yàn)橹虚g兩次操作的時(shí)機(jī)不一樣
ACK 是收到 FIN 之后立刻由內(nèi)核返回的數(shù)據(jù)報(bào)，FIN 是應(yīng)用程序處理完接受緩沖區(qū)的數(shù)據(jù)之后，調(diào)用的 close 方法觸發(fā)的
.
2.為什么四次？？
因?yàn)橐?strong>確保客戶端和服務(wù)端的數(shù)據(jù)能夠完成傳輸
.
3.為什么 TIME_WAIT 狀態(tài)要等待 2MSL？？
假設(shè)網(wǎng)絡(luò)上傳輸數(shù)據(jù)的最大時(shí)間為 MSL
MSL 就是 ACK / FIN 從主機(jī) A 到主機(jī) B 的最大時(shí)間
TIME-WAIT 等待時(shí)間，需要分成兩個(gè)部分：
①等待 ACK 經(jīng)歷一個(gè)最大時(shí)間到達(dá)主機(jī) B
②萬(wàn)一 ACK 丟了，在等待一個(gè)最大時(shí)間，主機(jī) B 重傳 FIN 到達(dá)主機(jī) A
因此，TIME_WAIT 就需要等待 2倍的MSL，即：2MSL
原因：

• 確保 ACK 報(bào)文能夠到達(dá)服務(wù)端，從而使服務(wù)端正常關(guān)閉連接
  第四次揮手時(shí)，客戶端第四次揮手的 ACK 報(bào)文不一定會(huì)到達(dá)服務(wù)端；服務(wù)端會(huì)超時(shí)重傳 FIN / ACK 報(bào)文，此時(shí)如果客戶端已經(jīng)斷開了連接，那么就無(wú)法響應(yīng)服務(wù)端的二次請(qǐng)求，這樣服務(wù)端遲遲收不到 FIN / ACK 報(bào)文的確認(rèn)，就無(wú)法正常斷開連接
  MSL 是報(bào)文段在網(wǎng)絡(luò)上存活的最長(zhǎng)時(shí)間，客戶端等待 2MSL 時(shí)間，即「客戶端 ACK 報(bào)文 1MSL 超時(shí) + 服務(wù)端 FIN 報(bào)文 1MSL 傳輸」，就能夠收到服務(wù)端重傳的 FIN / ACK 報(bào)文，然后客戶端重傳一次 ACK 報(bào)文，并重新啟動(dòng) 2MSL 計(jì)時(shí)器；如此保證服務(wù)端能夠正常關(guān)閉
  如果服務(wù)端重發(fā)的 FIN 沒(méi)有成功地在 2MSL 時(shí)間里傳給客戶端，服務(wù)端則會(huì)繼續(xù)超時(shí)重試直到斷開連接
• 防止已失效的連接請(qǐng)求報(bào)文段出現(xiàn)在之后的連接中
  TCP 要求在 2MSL 內(nèi)不使用相同的序列號(hào)；客戶端在發(fā)送完最后一個(gè) ACK 報(bào)文段后，再經(jīng)過(guò)時(shí)間 2MSL，就可以保證本連接持續(xù)的時(shí)間內(nèi)產(chǎn)生的所有報(bào)文段都從網(wǎng)絡(luò)中消失；這樣就可以使下一個(gè)連接中不會(huì)出現(xiàn)這種舊的連接請(qǐng)求報(bào)文段；或者即使收到這些過(guò)時(shí)的報(bào)文，也可以不處理它

總結(jié)

以上是生活随笔為你收集整理的TCP 协议(包含三次握手，四次挥手)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。