拒絕八股！通俗易懂帶你理解TCP協(xié)議，輕松拿捏面試官！

點(diǎn)擊左上方藍(lán)色“一口Linux”，選擇“設(shè)為星標(biāo)”

第一時(shí)間看干貨文章?

?【干貨】嵌入式驅(qū)動(dòng)工程師學(xué)習(xí)路線

?【干貨】一個(gè)可以寫(xiě)到簡(jiǎn)歷的基于Linux物聯(lián)網(wǎng)綜合項(xiàng)目

?【干貨】Linux嵌入式知識(shí)點(diǎn)-思維導(dǎo)圖-免費(fèi)獲取

?1

前言

我本人是比較抗拒背八股的，我主張去理解知識(shí)，讓它真的成為你的一部分，這樣在表達(dá)的時(shí)候就會(huì)非常流利，我常和我朋友說(shuō)每次我面試的時(shí)候?qū)τ谶@些八股都是在簡(jiǎn)單的吟誦，因?yàn)槲艺娴睦斫庹莆樟诉@些知識(shí)。但是網(wǎng)絡(luò)、計(jì)算機(jī)組成的具體內(nèi)容確實(shí)不像代碼一樣容易理解，所以很多人只能死記硬背。

其實(shí)這些所謂的八股，除了設(shè)計(jì)者和專(zhuān)精的工程師，又有多少人能真正確定自己對(duì)這些知識(shí)的理解是沒(méi)有錯(cuò)誤的呢？只要在面試中表達(dá)出自己的理解，而不是死記硬背，相信就能夠和普通的候選人拉開(kāi)差距了。

閑話(huà)少說(shuō)，下面是我對(duì)于TCP協(xié)議的一些個(gè)人理解，可能會(huì)帶有錯(cuò)誤，歡迎大家指正。

不簡(jiǎn)單的TCP協(xié)議

TCP內(nèi)部的實(shí)現(xiàn)是很復(fù)雜的，我會(huì)從流量控制、可靠交付、擁塞控制、TCP報(bào)文、三次握手四次揮手、重傳時(shí)間等內(nèi)容和大家稍微聊聊TCP的具體實(shí)現(xiàn)，以及為什么要這么做。

TCP的地位：是整個(gè)網(wǎng)絡(luò)協(xié)議族中最重要的一個(gè)，TCP在網(wǎng)絡(luò)協(xié)議族中是很特別的，因?yàn)檎麄€(gè)網(wǎng)絡(luò)，我們姑且分為課本上的五層吧，從下到上即物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、應(yīng)用層五層，只有傳輸層的TCP能做到可靠交付，這也是為什么很多應(yīng)用都是用TCP的原因，所以在面試中TCP絕對(duì)是重點(diǎn)中的重點(diǎn)。

TCP：傳輸控制協(xié)議（英語(yǔ)：Transmission?Control?Protocol，縮寫(xiě)：TCP）是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議，由IETF的RFC 793定義。在簡(jiǎn)化的計(jì)算機(jī)網(wǎng)絡(luò)OSI模型中，它完成第四層傳輸層所指定的功能。用戶(hù)數(shù)據(jù)報(bào)協(xié)議（UDP）是同一層內(nèi)另一個(gè)重要的傳輸協(xié)議。

在因特網(wǎng)協(xié)議族（Internet protocol suite）中，TCP層是位于IP層之上，應(yīng)用層之下的中間層。不同主機(jī)的應(yīng)用層之間經(jīng)常需要可靠的、像管道一樣的連接，但是IP層不提供這樣的流機(jī)制，而是提供不可靠的包交換。

應(yīng)用層向TCP層發(fā)送用于網(wǎng)間傳輸?shù)?、?位字節(jié)表示的數(shù)據(jù)流，然后TCP把數(shù)據(jù)流分割成適當(dāng)長(zhǎng)度的報(bào)文段（通常受該計(jì)算機(jī)連接的網(wǎng)絡(luò)的數(shù)據(jù)鏈路層的最大傳輸單元（MTU）的限制）。之后TCP把結(jié)果包傳給IP層，由它來(lái)透過(guò)網(wǎng)絡(luò)將包傳送給接收端實(shí)體的TCP層。TCP為了保證不發(fā)生丟包，就給每個(gè)包一個(gè)序號(hào)，同時(shí)序號(hào)也保證了傳送到接收端實(shí)體的包的按序接收。然后接收端實(shí)體對(duì)已成功收到的包發(fā)回一個(gè)相應(yīng)的確認(rèn)信息（ACK）；如果發(fā)送端實(shí)體在合理的往返時(shí)延（RTT）內(nèi)未收到確認(rèn)，那么對(duì)應(yīng)的數(shù)據(jù)包就被假設(shè)為已丟失并進(jìn)行重傳。TCP用一個(gè)校驗(yàn)和函數(shù)來(lái)檢驗(yàn)數(shù)據(jù)是否有錯(cuò)誤，在發(fā)送和接收時(shí)都要計(jì)算校驗(yàn)和。（維基百科）

TCP報(bào)文

1.源端口，目的端口：每個(gè)兩字節(jié)

2.序號(hào)：兩字節(jié)，TCP的每個(gè)字節(jié)都按照序號(hào)編序（這也是面向字節(jié)流的一個(gè)標(biāo)志），建立連接時(shí)序號(hào)是隨機(jī)的 而后的序號(hào)都在此基礎(chǔ)上遞增。比如我第一次握手seq=10086 第三次握手seq=10087 之后又傳了一百字節(jié)的數(shù)據(jù)，那么再發(fā)數(shù)據(jù),seq=10087+100+1=10188。

3.確認(rèn)號(hào)：兩字節(jié)，希望對(duì)方下一個(gè)報(bào)文段的序號(hào) 這也是為什么握手的時(shí)候ack=seq+1 確認(rèn)號(hào)代表前面序號(hào)的字節(jié)都已經(jīng)成功按序收到（捎帶確認(rèn)機(jī)制），當(dāng)客戶(hù)端發(fā)送過(guò)來(lái)的序號(hào)seq=10086時(shí)，報(bào)文長(zhǎng)度為200，那么服務(wù)端的ack應(yīng)該是12087，表示對(duì)之前所有報(bào)文的確認(rèn)。

4.數(shù)據(jù)偏移：四位，實(shí)際上表示的是首部長(zhǎng)度，最大十進(jìn)制數(shù)轉(zhuǎn)換過(guò)來(lái)對(duì)應(yīng)的是15，代表頭部最多大小為60字節(jié)，所以TCP頭部的長(zhǎng)度應(yīng)該是20-60間以4字節(jié)為單位變化的，不可能出現(xiàn)30字節(jié)長(zhǎng)度的TCP頭部

5.保留：六位，今后使用

然后就是6個(gè)控制位，每個(gè)1為，數(shù)據(jù)偏移+保留+6控制位=2字節(jié)

6.緊急URG：表明該報(bào)文優(yōu)先級(jí)很高，當(dāng)URG=1時(shí)，報(bào)文會(huì)被放在發(fā)送方此次發(fā)送報(bào)文的最前端進(jìn)行優(yōu)先發(fā)送

7.確認(rèn)ACK：ACK=1 確認(rèn)號(hào)有效 建立連接之后 每次ACK=1

8.推送PUSH：PUSH=1 立即創(chuàng)建一個(gè)報(bào)文段發(fā)送出去（用得少）

9.復(fù)位RST：RST=1 表示TCP連接出現(xiàn)嚴(yán)重錯(cuò)誤，需要重新連接

10.同步SYN：SYN=1 表明這是一個(gè)連接請(qǐng)求報(bào)文

11.窗口：2字節(jié)，滑動(dòng)窗口的大小 我們后面細(xì)說(shuō)

12.檢驗(yàn)和：2字節(jié)，這個(gè)用途和UDP的一樣，加上12字段偽首部之后進(jìn)行校驗(yàn)

13.緊急指針：2字節(jié)，只有當(dāng)URG=1時(shí)才有意義，指出本報(bào)文段中緊急數(shù)據(jù)的字節(jié)數(shù)

14.選項(xiàng)：長(zhǎng)度可變，最大40字節(jié)（窗口擴(kuò)大選項(xiàng)、時(shí)間戳選項(xiàng)等等）

TCP的特點(diǎn)

• 連接點(diǎn)對(duì)點(diǎn)

• 全雙工 A可以給B發(fā) B也可以給A發(fā)

• 面向連接 只有連接建立完成 才可以發(fā)數(shù)據(jù)

• 擁塞控制 主要是通過(guò)以下機(jī)制來(lái)完成的（慢開(kāi)始 擁塞避免 快恢復(fù)和快重傳）

• 可靠交付

• 面向字節(jié)流

這些下面都會(huì)一一介紹

TCP和UDP的區(qū)別

TCP是一個(gè)復(fù)雜的協(xié)議 而UDP比較簡(jiǎn)單

1.連接 TCP是一個(gè)面向連接的協(xié)議 而UDP是一個(gè)無(wú)連接協(xié)議 即TCP需要連接建立之后才能傳輸數(shù)據(jù) 而UDP在未建立連接時(shí)就能夠傳輸數(shù)據(jù)

2.交付 TCP是一個(gè)可靠交付的協(xié)議 而UDP只能盡最大努力交付 可靠交付指的是數(shù)據(jù)按序到達(dá) 不丟失 不重復(fù)

3.數(shù)量 TCP是一個(gè)點(diǎn)對(duì)點(diǎn)的全雙工協(xié)議 而UDP支持一對(duì)一 一對(duì)多 多對(duì)多

4.首部長(zhǎng)度 TCP的首部長(zhǎng)度更長(zhǎng) 20-60字節(jié) 而UDP的首部固定為8個(gè)字節(jié)

5.面向 TCP面向的是字節(jié)流 即上層應(yīng)用層交付下來(lái)的數(shù)據(jù)報(bào) 在TCP的眼中是一串字節(jié)流 而UDP是面向數(shù)據(jù)報(bào)的

6.是否具有擁塞控制 TCP是有擁塞控制的 在網(wǎng)絡(luò)擁塞時(shí)源點(diǎn)主機(jī)的發(fā)送速率會(huì)降低 而UDP不具有擁塞控制 一些追求傳輸效率的應(yīng)用通常使用UDP協(xié)議

所謂面向字節(jié)流 指的是TCP發(fā)送端發(fā)送幾次數(shù)據(jù)和接收端接受幾次數(shù)據(jù)時(shí)沒(méi)有必然聯(lián)系的

比如發(fā)送端調(diào)用一次write寫(xiě)了一百個(gè)字節(jié) 但是接受端可以分10次接受 也可以寫(xiě)10次100字節(jié) 接收端一次接收完

原因:

TCP面向連接 一個(gè)Socket收到的數(shù)據(jù)由同一臺(tái)數(shù)據(jù)發(fā)出 并且有序到達(dá) 所以每次讀取多少數(shù)據(jù)都可以 因?yàn)槲抑狼懊娴臄?shù)據(jù)都是對(duì)的 某些時(shí)候?yàn)榱斯?jié)省資源 程序可能會(huì)選擇"攢一會(huì)"再讀

而UDP協(xié)議不知道前面的數(shù)據(jù)是否是錯(cuò)的 所以每次發(fā)送就對(duì)應(yīng)著一次接收 如果錯(cuò)了就再發(fā)

應(yīng)用區(qū)別：

UDP：追求高速度的應(yīng)用一般用的是UDP（KCP），比如視頻、音頻、實(shí)時(shí)游戲、廣播，而且通常這些應(yīng)用對(duì)于數(shù)據(jù)的可靠性要求不是很高，視頻丟點(diǎn)數(shù)據(jù)（丟幾幀 后面再補(bǔ)上），你也看不出來(lái)，但是速度慢就不能接受了，玩英雄聯(lián)盟慢一秒別人就把你頭打爆了

TCP：可靠傳輸，HTTP用的就是TCP（后面用為了追求性能用UDP去了，我們之后詳說(shuō)），任何確保數(shù)據(jù)可靠的應(yīng)用都應(yīng)該使用TCP

典中典之三次握手 四次揮手

相信很多同學(xué)都聽(tīng)說(shuō)過(guò)三次握手 四次揮手的問(wèn)題，也大概知道過(guò)程是什么樣的，但是自己講很難講清楚，我們現(xiàn)在來(lái)捋一捋這到底是是個(gè)什么過(guò)程，以及為什么要三次握手四次揮手

注：下文的客戶(hù)端和服務(wù)器是站在應(yīng)用層角度的，可以理解成發(fā)送方和接收方

三次握手

第一次握手：客戶(hù)端向服務(wù)器發(fā)送TCP請(qǐng)求連接報(bào)文，SYN置1，seq=x (都知道SYN和seq是啥吧)

第二次握手：服務(wù)器收到報(bào)文，發(fā)送TCP確認(rèn)報(bào)文，SYN=ACK=1，seq=y ack=x+1

第三次握手：客戶(hù)端收到報(bào)文，發(fā)送ACK=1,seq=x+1,ack=y+1

怎么記憶這個(gè)過(guò)程呢？

第一次和第二次握手 都屬于正兒八經(jīng)連接建立的過(guò)程 我們之前說(shuō)過(guò)SYN置一的情況是請(qǐng)求連接報(bào)文才有的 所以前兩次握手是有SYN的

第三次握手是對(duì)前兩次握手的確認(rèn)過(guò)程 即確認(rèn) 客戶(hù)端感知到服務(wù)器的存在 服務(wù)器也知道客戶(hù)端的存在 所以不需要SYN

因?yàn)榈谝淮挝帐职l(fā)送的報(bào)文是沒(méi)有實(shí)體數(shù)據(jù)的，所以第三次握手seq=第一次握手seq+1

注：第三次握手可以帶數(shù)據(jù) 前面兩次不行

為什么需要三次握手

這個(gè)一般是和三次握手一起問(wèn)的

我個(gè)人理解有兩個(gè)原因

1.TCP是面向連接的 如果只進(jìn)行兩次握手 服務(wù)器其實(shí)是不知道連接是否建立成功的

2.如果只進(jìn)行兩次握手，那么會(huì)出現(xiàn)這么一種情況，因?yàn)榫W(wǎng)絡(luò)延遲，客戶(hù)端向服務(wù)器發(fā)了一次連接請(qǐng)求報(bào)文，但是服務(wù)器暫時(shí)沒(méi)收到，然后客戶(hù)端又發(fā)了一次，這次服務(wù)器收到了，兩次握手成功了，這時(shí)第一次發(fā)送的請(qǐng)求來(lái)了，服務(wù)器也會(huì)做出響應(yīng)，就會(huì)同時(shí)有兩個(gè)TCP連接，浪費(fèi)資源。但是如果有三次握手的話(huà)，服務(wù)器進(jìn)行確認(rèn)的時(shí)候，客戶(hù)端會(huì)忽略掉這次確認(rèn)（想一想為什么）

四次揮手

第一次：客戶(hù)端主動(dòng)發(fā)送斷開(kāi)請(qǐng)求，F(xiàn)IN=1(這是一個(gè)請(qǐng)求斷開(kāi)的報(bào)文)，seq=x

第二次：服務(wù)器收到之后 發(fā)送 ACK=1 seq=v ack=x+1 然后處于半關(guān)閉狀態(tài)Close-wait

第三次：服務(wù)器發(fā)送FIN=1 ACK=1 seq=w ack=x+1

第四次：客戶(hù)端收到后 發(fā)送ACK=1 seq=u+1 ack=w+1

一些解釋

1.第三次為什么seq=w 是因?yàn)槲覀兗僭O(shè)第二次到第三次的期間 服務(wù)器還在發(fā)數(shù)據(jù)

2,為什么第三次也有ACK字段

個(gè)人理解：TCP報(bào)文規(guī)定了只要建立連接之后所有報(bào)文都有ACK字段，所以其實(shí)第一次也有ACK字段的，只是大部分教材沒(méi)有畫(huà)出來(lái)

（八股文的很多細(xì)節(jié)是無(wú)法深究的 不是TCP的設(shè)計(jì)者誰(shuí)知道真相是什么呢 我覺(jué)得只要有自己的理解 就已經(jīng)超越很多死背書(shū)的人了）

3.為什么服務(wù)器連著給客戶(hù)端發(fā)兩次 一次不行嗎？

第一次是對(duì)客戶(hù)端發(fā)來(lái)的確認(rèn)

第二次是請(qǐng)求和客戶(hù)端斷開(kāi)

而且在這兩次發(fā)送報(bào)文之間 服務(wù)器是可以發(fā)送數(shù)據(jù)的 客戶(hù)端不行

為什么需要四次揮手

服務(wù)器決定進(jìn)行第二次揮手和第三次揮手，某些時(shí)候把兩次揮手合并，因?yàn)橹虚g等不等待其實(shí)是由服務(wù)端應(yīng)用程序決定的（handler），如果沒(méi)有數(shù)據(jù)要發(fā)，同時(shí)又開(kāi)啟了tcp的延遲確認(rèn)，那么就會(huì)合并揮手，這也是抓包的時(shí)候?yàn)槭裁茨茏サ饺螕]手的包。

為什么需要等待2MSL

1.釋放的端口可能會(huì)重連剛斷開(kāi)的服務(wù)器端口，而第二次揮手之后服務(wù)器還在給該端口發(fā)數(shù)據(jù)，如果不等的話(huà)，在這個(gè)通道里的老TCP報(bào)文可能和新的報(bào)文沖突，造成數(shù)據(jù)紊亂，2MSL（兩倍生存時(shí)間，原因我推測(cè)可能是計(jì)算客戶(hù)端發(fā)送給服務(wù)器，服務(wù)器處理之后再返回過(guò)來(lái)）是足夠讓客戶(hù)端全部收到第二次揮手后的數(shù)據(jù)的。具體的時(shí)間不同版本其實(shí)也不一樣，有興趣的同學(xué)可以深入了解

2.保證確認(rèn)斷開(kāi)，如果最后一次確認(rèn)丟失了，服務(wù)器會(huì)重新進(jìn)行第三次揮手，這樣客戶(hù)端還能夠?qū)Φ谌螕]手的FIN報(bào)文進(jìn)行處理

TCP怎么保證可靠交付

這個(gè)問(wèn)題是一個(gè)很廣泛的問(wèn)題 基本把所有TCP的設(shè)計(jì)思想都包含了

什么是可靠交付？

我認(rèn)為最起碼要做到這幾點(diǎn)：數(shù)據(jù)不丟 數(shù)據(jù)不重 數(shù)據(jù)按序 數(shù)據(jù)不錯(cuò)

1.數(shù)據(jù)不丟：TCP使用了確認(rèn)-重傳機(jī)制，對(duì)每一個(gè)收到的正確報(bào)文進(jìn)行確認(rèn)(ack)，如果發(fā)現(xiàn)有數(shù)據(jù)沒(méi)有被確認(rèn)，就重傳，其中重傳又有超時(shí)重傳和快重傳

2.數(shù)據(jù)不重/不錯(cuò)：接收方會(huì)對(duì)數(shù)據(jù)進(jìn)行檢驗(yàn)。重復(fù)的數(shù)據(jù)丟棄，錯(cuò)誤的數(shù)據(jù)丟棄，并不進(jìn)行確認(rèn)。

3.數(shù)據(jù)按序：流量控制，不至于一下發(fā)很多報(bào)文，而且會(huì)對(duì)數(shù)據(jù)包進(jìn)行重新排序

TCP確認(rèn)-重傳機(jī)制

相信大家已經(jīng)懂什么是確認(rèn)了吧，簡(jiǎn)單來(lái)說(shuō)，接收端發(fā)送ack=10001的報(bào)文，就說(shuō)明從連接開(kāi)始的序列號(hào)（假設(shè)是100）到ack-1（10000）的報(bào)文都是可靠交付的。

重傳也很簡(jiǎn)單，我們先來(lái)聊聊超時(shí)重傳

什么時(shí)候重傳呢？

其實(shí)TCP在傳遞數(shù)據(jù)的時(shí)候，會(huì)設(shè)置一個(gè)超時(shí)計(jì)時(shí)器，當(dāng)超時(shí)計(jì)時(shí)器觸發(fā)了，發(fā)送端還沒(méi)有收到來(lái)自接收端的確認(rèn)報(bào)文，那么就認(rèn)為這個(gè)消息沒(méi)成功傳遞，原因可能有很多，網(wǎng)絡(luò)阻塞，丟包，數(shù)據(jù)出錯(cuò)等等

問(wèn)題來(lái)了：超時(shí)計(jì)時(shí)器怎么設(shè)置呢？每一個(gè)數(shù)據(jù)的超時(shí)時(shí)間都不一樣嗎？怎么能做到既不浪費(fèi)算力，又能高效確認(rèn)超時(shí)呢？

首先超時(shí)時(shí)間肯定不能選的很短，不然會(huì)很容易重發(fā)，浪費(fèi)很多資源。

也不能很長(zhǎng)，因?yàn)榘l(fā)送端只有收到確認(rèn)之后才回刪除數(shù)據(jù)，這樣會(huì)浪費(fèi)發(fā)送端的資源。

所以重傳時(shí)間RTO我們一般設(shè)為比平常報(bào)文的平均往返時(shí)間稍微長(zhǎng)一點(diǎn)點(diǎn)

具體公式如下：

RTTS(加群啊平均往返時(shí)間)=（1-a) x 舊的RTTS+ a x RTTS RFC文檔推薦 a=0.125

RTTD（RTT偏差加權(quán)值) =(1-b) x 舊的RTTD + b x (RTTS-RTTD) RFC文檔推薦b=0.25

RTO=RTTS+4 * RTTD

而每次觸發(fā)超時(shí)重傳 RTO=2 X RTO

TCP的流量控制

什么是流量控制？為什么要流量控制？

簡(jiǎn)單來(lái)說(shuō)流量控制就是接收方通過(guò)參數(shù)控制發(fā)送方的速度，記得我們上文講到的TCP報(bào)文的窗口字段嗎，這個(gè)就是調(diào)控的因素，當(dāng)接收方的緩存變少，就把窗口變小，發(fā)送方就會(huì)把數(shù)據(jù)發(fā)的慢一點(diǎn)，窗口的大小就是發(fā)送速度的大小

而我們提到的這種方案，就是TCP的滑動(dòng)窗口，它的思想與算法中的滑動(dòng)窗口類(lèi)似，維護(hù)一個(gè)變長(zhǎng)的窗口值，落在窗口里的就是可以發(fā)送的，在窗口后面的就是發(fā)完了的，窗口前面的就是還沒(méi)發(fā)的，窗口是以字節(jié)為單位的，這也能體現(xiàn)TCP的面向字節(jié)流思想。

注意：發(fā)送端和接收端的窗口大小不可能做到完全同步，因?yàn)榫W(wǎng)絡(luò)具有時(shí)延，當(dāng)窗口為0的時(shí)候，發(fā)送端不再發(fā)送數(shù)據(jù)，待接收端緩沖區(qū)有空間了之后，會(huì)重新打開(kāi)滑動(dòng)窗口，讓發(fā)送端繼續(xù)發(fā)送數(shù)據(jù)。

TCP的擁塞控制

什么是擁塞？

擁塞：對(duì)網(wǎng)絡(luò)中的某種資源的需求超過(guò)了資源可提供的部分

TCP采用四種算法避免擁塞

我們把A設(shè)為發(fā)送方 B設(shè)為接收方

發(fā)送方維護(hù)一個(gè)cwnd（擁塞窗口)的動(dòng)態(tài)變量，其值取決于網(wǎng)絡(luò)的擁塞程度，還有一個(gè)慢啟動(dòng)門(mén)限ssthresh狀態(tài)變量

原則：沒(méi)有擁塞，把cwnd變大，擁塞了，把cwnd縮小 思想很簡(jiǎn)單，實(shí)現(xiàn)很復(fù)雜

現(xiàn)在是不是有點(diǎn)蒙，之前不是提到了發(fā)送窗口大小嗎，怎么又來(lái)了個(gè)擁塞窗口，A到底用什么速度發(fā)數(shù)據(jù)

經(jīng)查證：發(fā)送窗口大小等于min(cwnd，B的接收窗口)

1.慢開(kāi)始:cwnd小于ssthresh時(shí)，采用這種算法，cwnd大小按照指數(shù)擴(kuò)容，每次 x 2

2.擁塞避免：cwnd>=ssthresh時(shí)，采用這種算法，cwnd按照常數(shù)擴(kuò)容，每次+1

判斷擁塞：當(dāng)網(wǎng)絡(luò)中有一段數(shù)據(jù)重傳，則認(rèn)為網(wǎng)絡(luò)擁塞，ss變?yōu)閾砣麜r(shí)的一半,cwnd變?yōu)?

大家是不是覺(jué)得很不科學(xué)，因?yàn)閬G包是很正常的，再牛逼的網(wǎng)絡(luò)也會(huì)丟包，重傳一次就認(rèn)為擁塞，cwnd可能永遠(yuǎn)都等于1

因此TCP還有一種重傳機(jī)制

3.快重傳：不需要等到超時(shí)才進(jìn)行重傳，當(dāng)B給A連著發(fā)了三次ack一致的確認(rèn)報(bào)文，A就認(rèn)為數(shù)據(jù)丟失了，重發(fā)ack之后的數(shù)據(jù)

4.快恢復(fù):當(dāng)快重傳被觸發(fā)時(shí)，同時(shí)執(zhí)行快恢復(fù)算法，ss=擁塞時(shí)的一半，cwnd=ss，執(zhí)行擁塞避免算法

TCP到底用的是超時(shí)重傳還是快重傳

相信如果你聽(tīng)懂了上面的內(nèi)容，你腦子里應(yīng)該有這個(gè)疑問(wèn)

TCP到底是兩種都用，還是擁塞的時(shí)候用快重傳，平常使用超時(shí)重傳呢？

我們計(jì)網(wǎng)老師說(shuō)的是后者，但是TCP是如何判斷網(wǎng)絡(luò)是否擁塞的呢，已經(jīng)建立連接的TCP能動(dòng)態(tài)修改重傳策略嗎？

從業(yè)務(wù)的角度來(lái)說(shuō)我覺(jué)得答案更可能是前者，畢竟這么玩能提高速度。

結(jié)語(yǔ)

今天的內(nèi)容到這里就結(jié)束了，如果對(duì)您有所幫助，歡迎點(diǎn)贊、評(píng)論、收藏，您的支持就是對(duì)我最大的鼓勵(lì)。