面試必備！TCP協(xié)議經(jīng)典十五連問(wèn)！

時(shí)間：2021-08-19 16:25:07

關(guān)鍵字： TCP

手機(jī)看文章

掃描二維碼
隨時(shí)隨地手機(jī)看文章

[導(dǎo)讀]前言TCP協(xié)議是大廠面試必問(wèn)的知識(shí)點(diǎn)。整理了15道非常經(jīng)典的TCP面試題，希望大家都找到理想的offer呀公眾號(hào)：撿田螺的小男孩1.?講下TCP三次握手流程開(kāi)始客戶(hù)端和服務(wù)器都處于CLOSED狀態(tài)，然后服務(wù)端開(kāi)始監(jiān)聽(tīng)某個(gè)端口，進(jìn)入LISTEN狀態(tài)第一次握手(SYN=1,seq=x...

前言

TCP協(xié)議是大廠面試必問(wèn)的知識(shí)點(diǎn)。整理了15道非常經(jīng)典的TCP面試題，希望大家都找到理想的offer呀

公眾號(hào)：撿田螺的小男孩

1. ?講下TCP三次握手流程

開(kāi)始客戶(hù)端和服務(wù)器都處于CLOSED狀態(tài)，然后服務(wù)端開(kāi)始監(jiān)聽(tīng)某個(gè)端口，進(jìn)入LISTEN狀態(tài)

第一次握手(SYN=1, seq=x)，發(fā)送完畢后，客戶(hù)端進(jìn)入 SYN_SEND 狀態(tài)
第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x 1)，發(fā)送完畢后，服務(wù)器端進(jìn)入 SYN_RCVD 狀態(tài)。
第三次握手(ACK=1，ACKnum=y 1)，發(fā)送完畢后，客戶(hù)端進(jìn)入 ESTABLISHED 狀態(tài)，當(dāng)服務(wù)器端接收到這個(gè)包時(shí),也進(jìn)入 ESTABLISHED 狀態(tài)，TCP 握手，即可以開(kāi)始數(shù)據(jù)傳輸。

2.TCP握手為什么是三次，不能是兩次？不能是四次？

TCP握手為什么是三次呢？為了方便理解，我們以談戀愛(ài)為例子：兩個(gè)人能走到一起，最重要的事情就是相愛(ài)，就是我愛(ài)你，并且我知道，你也愛(ài)我，接下來(lái)我們以此來(lái)模擬三次握手的過(guò)程：

為什么握手不能是兩次呢？

如果只有兩次握手，女孩子可能就不知道，她的那句我也愛(ài)你，男孩子是否收到，戀愛(ài)關(guān)系就不能愉快展開(kāi)。

為什么握手不能是四次呢？

因?yàn)槲帐植荒苁撬拇文兀恳驗(yàn)槿我呀?jīng)夠了，三次已經(jīng)能讓雙方都知道：你愛(ài)我，我也愛(ài)你。而四次就多余了。

3. 講下TCP四次揮手過(guò)程

第一次揮手(FIN=1，seq=u)，發(fā)送完畢后，客戶(hù)端進(jìn)入FIN_WAIT_1 狀態(tài)
第二次揮手(ACK=1，ack=u 1,seq =v)，發(fā)送完畢后，服務(wù)器端進(jìn)入CLOSE_WAIT 狀態(tài)，客戶(hù)端接收到這個(gè)確認(rèn)包之后，進(jìn)入 FIN_WAIT_2 狀態(tài)
第三次揮手(FIN=1，ACK1,seq=w,ack=u 1)，發(fā)送完畢后，服務(wù)器端進(jìn)入LAST_ACK 狀態(tài)，等待來(lái)自客戶(hù)端的最后一個(gè)ACK。
第四次揮手(ACK=1，seq=u 1,ack=w 1)，客戶(hù)端接收到來(lái)自服務(wù)器端的關(guān)閉請(qǐng)求，發(fā)送一個(gè)確認(rèn)包，并進(jìn)入 TIME_WAIT狀態(tài)，等待了某個(gè)固定時(shí)間（兩個(gè)最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，沒(méi)有收到服務(wù)器端的 ACK ，認(rèn)為服務(wù)器端已經(jīng)正常關(guān)閉連接，于是自己也關(guān)閉連接，進(jìn)入 CLOSED 狀態(tài)。服務(wù)器端接收到這個(gè)確認(rèn)包之后，關(guān)閉連接，進(jìn)入 CLOSED 狀態(tài)。

4. TCP揮手為什么需要四次呢？

舉個(gè)例子吧!

★小明和小紅打電話(huà)聊天，通話(huà)差不多要結(jié)束時(shí)，小紅說(shuō)“我沒(méi)啥要說(shuō)的了”，小明回答“我知道了”。但是小明可能還會(huì)有要說(shuō)的話(huà)，小紅不能要求小明跟著自己的節(jié)奏結(jié)束通話(huà)，于是小明可能又嘰嘰歪歪說(shuō)了一通，最后小明說(shuō)“我說(shuō)完了”，小紅回答“知道了”，這樣通話(huà)才算結(jié)束。
”

5. TIME-WAIT 狀態(tài)為什么需要等待 2MSL

2MSL，2 Maximum Segment Lifetime，即兩個(gè)最大段生命周期

★
1個(gè) MSL 保證四次揮手中主動(dòng)關(guān)閉方最后的 ACK 報(bào)文能最終到達(dá)對(duì)端
1個(gè) MSL 保證對(duì)端沒(méi)有收到 ACK 那么進(jìn)行重傳的 FIN 報(bào)文能夠到達(dá)
”

6.TCP 和 UDP 的區(qū)別

TCP面向連接（（如打電話(huà)要先撥號(hào)建立連接）;UDP是無(wú)連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接。
TCP要求安全性，提供可靠的服務(wù)，通過(guò)TCP連接傳送的數(shù)據(jù)，不丟失、不重復(fù)、安全可靠。而UDP盡最大努力交付，即不保證可靠交付。
TCP是點(diǎn)對(duì)點(diǎn)連接的，UDP一對(duì)一，一對(duì)多，多對(duì)多都可以
TCP傳輸效率相對(duì)較低,而UDP傳輸效率高，它適用于對(duì)高速傳輸和實(shí)時(shí)性有較高的通信或廣播通信。
TCP適合用于網(wǎng)頁(yè)，郵件等;UDP適合用于視頻，語(yǔ)音廣播等
TCP面向字節(jié)流，UDP面向報(bào)文

7. TCP報(bào)文首部有哪些字段，說(shuō)說(shuō)其作用

16位端口號(hào)：源端口號(hào)，主機(jī)該報(bào)文段是來(lái)自哪里；目標(biāo)端口號(hào)，要傳給哪個(gè)上層協(xié)議或應(yīng)用程序
32位序號(hào)：一次TCP通信（從TCP連接建立到斷開(kāi)）過(guò)程中某一個(gè)傳輸方向上的字節(jié)流的每個(gè)字節(jié)的編號(hào)。
32位確認(rèn)號(hào)：用作對(duì)另一方發(fā)送的tcp報(bào)文段的響應(yīng)。其值是收到的TCP報(bào)文段的序號(hào)值加1。
4位頭部長(zhǎng)度：表示tcp頭部有多少個(gè)32bit字（4字節(jié)）。因?yàn)?位最大能標(biāo)識(shí)15，所以TCP頭部最長(zhǎng)是60字節(jié)。
6位標(biāo)志位：URG(緊急指針是否有效)，ACk（表示確認(rèn)號(hào)是否有效），PSH（緩沖區(qū)尚未填滿(mǎn)），RST（表示要求對(duì)方重新建立連接），SYN（建立連接消息標(biāo)志接），F(xiàn)IN（表示告知對(duì)方本端要關(guān)閉連接了）
16位窗口大小：是TCP流量控制的一個(gè)手段。這里說(shuō)的窗口，指的是接收通告窗口。它告訴對(duì)方本端的TCP接收緩沖區(qū)還能容納多少字節(jié)的數(shù)據(jù)，這樣對(duì)方就可以控制發(fā)送數(shù)據(jù)的速度。
16位校驗(yàn)和：由發(fā)送端填充，接收端對(duì)TCP報(bào)文段執(zhí)行CRC算法以檢驗(yàn)TCP報(bào)文段在傳輸過(guò)程中是否損壞。注意，這個(gè)校驗(yàn)不僅包括TCP頭部，也包括數(shù)據(jù)部分。這也是TCP可靠傳輸?shù)囊粋€(gè)重要保障。
16位緊急指針：一個(gè)正的偏移量。它和序號(hào)字段的值相加表示最后一個(gè)緊急數(shù)據(jù)的下一字節(jié)的序號(hào)。因此，確切地說(shuō)，這個(gè)字段是緊急指針相對(duì)當(dāng)前序號(hào)的偏移，不妨稱(chēng)之為緊急偏移。TCP的緊急指針是發(fā)送端向接收端發(fā)送緊急數(shù)據(jù)的方法。

8. TCP 是如何保證可靠性的

首先，TCP的連接是基于三次握手，而斷開(kāi)則是四次揮手。確保連接和斷開(kāi)的可靠性。
其次，TCP的可靠性，還體現(xiàn)在有狀態(tài);TCP會(huì)記錄哪些數(shù)據(jù)發(fā)送了，哪些數(shù)據(jù)被接受了，哪些沒(méi)有被接受，并且保證數(shù)據(jù)包按序到達(dá)，保證數(shù)據(jù)傳輸不出差錯(cuò)。
再次，TCP的可靠性，還體現(xiàn)在可控制。它有報(bào)文校驗(yàn)、ACK應(yīng)答、超時(shí)重傳(發(fā)送方)、失序數(shù)據(jù)重傳（接收方）、丟棄重復(fù)數(shù)據(jù)、流量控制（滑動(dòng)窗口）和擁塞控制等機(jī)制。

9. TCP 重傳機(jī)制

超時(shí)重傳

TCP 為了實(shí)現(xiàn)可靠傳輸，實(shí)現(xiàn)了重傳機(jī)制。最基本的重傳機(jī)制，就是超時(shí)重傳，即在發(fā)送數(shù)據(jù)報(bào)文時(shí)，設(shè)定一個(gè)定時(shí)器，每間隔一段時(shí)間，沒(méi)有收到對(duì)方的ACK確認(rèn)應(yīng)答報(bào)文，就會(huì)重發(fā)該報(bào)文。

這個(gè)間隔時(shí)間，一般設(shè)置為多少呢？我們先來(lái)看下什么叫RTT（Round-Trip Time，往返時(shí)間）。

RTT就是，一個(gè)數(shù)據(jù)包從發(fā)出去到回來(lái)的時(shí)間，即數(shù)據(jù)包的一次往返時(shí)間。超時(shí)重傳時(shí)間，就是Retransmission Timeout ，簡(jiǎn)稱(chēng)RTO。

RTO設(shè)置多久呢？

如果RTO比較小，那很可能數(shù)據(jù)都沒(méi)有丟失，就重發(fā)了，這會(huì)導(dǎo)致網(wǎng)絡(luò)阻塞，會(huì)導(dǎo)致更多的超時(shí)出現(xiàn)。
如果RTO比較大，等到花兒都謝了還是沒(méi)有重發(fā)，那效果就不好了。

一般情況下，RTO略大于RTT，效果是最好的。一些小伙伴會(huì)問(wèn)，超時(shí)時(shí)間有沒(méi)有計(jì)算公式呢?有的！有個(gè)標(biāo)準(zhǔn)方法算RTO的公式，也叫Jacobson / Karels 算法。我們一起來(lái)看下計(jì)算RTO的公式

1. 先計(jì)算SRTT（計(jì)算平滑的RTT）

SRTT?=?(1?-?α)?*?SRTT? ?α?*?RTT??//求?SRTT?的加權(quán)平均

2. 再計(jì)算RTTVAR (round-trip time variation)

RTTVAR?=?(1?-?β)?*?RTTVAR? ?β?*?(|RTT?-?SRTT|)?//計(jì)算?SRTT?與真實(shí)值的差距

3. 最終的RTO

RTO?=?μ?*?SRTT? ???*?RTTVAR??=??SRTT? ?4·RTTVAR??

其中，α = 0.125，β = 0.25， μ = 1，? = 4，這些參數(shù)都是大量結(jié)果得出的最優(yōu)參數(shù)。

但是，超時(shí)重傳會(huì)有這些缺點(diǎn)：

★
當(dāng)一個(gè)報(bào)文段丟失時(shí)，會(huì)等待一定的超時(shí)周期然后才重傳分組，增加了端到端的時(shí)延。
當(dāng)一個(gè)報(bào)文段丟失時(shí)，在其等待超時(shí)的過(guò)程中，可能會(huì)出現(xiàn)這種情況：其后的報(bào)文段已經(jīng)被接收端接收但卻遲遲得不到確認(rèn)，發(fā)送端會(huì)認(rèn)為也丟失了，從而引起不必要的重傳，既浪費(fèi)資源也浪費(fèi)時(shí)間。
”

并且，TCP有個(gè)策略，就是超時(shí)時(shí)間間隔會(huì)加倍。超時(shí)重傳需要等待很長(zhǎng)時(shí)間。因此，還可以使用快速重傳機(jī)制。

快速重傳

快速重傳機(jī)制，它不以時(shí)間驅(qū)動(dòng)，而是以數(shù)據(jù)驅(qū)動(dòng)。它基于接收端的反饋信息來(lái)引發(fā)重傳。

一起來(lái)看下快速重傳流程：

快速重傳流程

發(fā)送端發(fā)送了 1，2，3，4，5,6 份數(shù)據(jù):

第一份 Seq=1 先送到了，于是就 Ack 回 2；
第二份 Seq=2 也送到了，假設(shè)也正常，于是ACK 回 3；
第三份 Seq=3 由于網(wǎng)絡(luò)等其他原因，沒(méi)送到；
第四份 Seq=4 也送到了，但是因?yàn)镾eq3沒(méi)收到。所以ACK回3；
后面的 Seq=4,5的也送到了，但是ACK還是回復(fù)3，因?yàn)镾eq=3沒(méi)收到。
發(fā)送端連著收到三個(gè)重復(fù)冗余ACK=3的確認(rèn)（實(shí)際上是4個(gè)，但是前面一個(gè)是正常的ACK，后面三個(gè)才是重復(fù)冗余的），便知道哪個(gè)報(bào)文段在傳輸過(guò)程中丟失了，于是在定時(shí)器過(guò)期之前，重傳該報(bào)文段。
最后，接收到收到了 Seq3，此時(shí)因?yàn)?Seq=4，5，6都收到了，于是ACK回7.

但快速重傳還可能會(huì)有個(gè)問(wèn)題：ACK只向發(fā)送端告知最大的有序報(bào)文段，到底是哪個(gè)報(bào)文丟失了呢？并不確定！那到底該重傳多少個(gè)包呢？

★是重傳 Seq3 呢？還是重傳 Seq3、Seq4、Seq5、Seq6 呢？因?yàn)榘l(fā)送端并不清楚這三個(gè)連續(xù)的 ACK3 是誰(shuí)傳回來(lái)的。
”

帶選擇確認(rèn)的重傳（SACK）

為了解決快速重傳的問(wèn)題：應(yīng)該重傳多少個(gè)包? TCP提供了SACK方法（帶選擇確認(rèn)的重傳，Selective Acknowledgment）。

SACK機(jī)制就是，在快速重傳的基礎(chǔ)上，接收端返回最近收到的報(bào)文段的序列號(hào)范圍，這樣發(fā)送端就知道接收端哪些數(shù)據(jù)包沒(méi)收到，醬紫就很清楚該重傳哪些數(shù)據(jù)包啦。SACK標(biāo)記是加在TCP頭部選項(xiàng)字段里面的。

SACK機(jī)制

如上圖中，發(fā)送端收到了三次同樣的ACK=30的確認(rèn)報(bào)文，于是就會(huì)觸發(fā)快速重發(fā)機(jī)制，通過(guò)SACK信息發(fā)現(xiàn)只有30~39這段數(shù)據(jù)丟失，于是重發(fā)時(shí)就只選擇了這個(gè)30~39的TCP報(bào)文段進(jìn)行重發(fā)。

D-SACK

D-SACK，即Duplicate SACK（重復(fù)SACK），在SACK的基礎(chǔ)上做了一些擴(kuò)展，，主要用來(lái)告訴發(fā)送方，有哪些數(shù)據(jù)包自己重復(fù)接受了。DSACK的目的是幫助發(fā)送方判斷，是否發(fā)生了包失序、ACK丟失、包重復(fù)或偽重傳。讓TCP可以更好的做網(wǎng)絡(luò)流控。來(lái)看個(gè)圖吧：

D-SACK簡(jiǎn)要流程

10. 聊聊TCP的滑動(dòng)窗口

TCP 發(fā)送一個(gè)數(shù)據(jù)，需要收到確認(rèn)應(yīng)答，才會(huì)發(fā)送下一個(gè)數(shù)據(jù)。這樣有個(gè)缺點(diǎn)，就是效率會(huì)比較低。

★這就好像我們面對(duì)面聊天，你說(shuō)完一句，我應(yīng)答后，你才會(huì)說(shuō)下一句。那么，如果我在忙其他事情，沒(méi)有能夠及時(shí)回復(fù)你。你說(shuō)完一句后，要等到我忙完回復(fù)你，你才說(shuō)下句，這顯然很不現(xiàn)實(shí)。
”

為了解決這個(gè)問(wèn)題，TCP引入了窗口，它是操作系統(tǒng)開(kāi)辟的一個(gè)緩存空間。窗口大小值表示無(wú)需等待確認(rèn)應(yīng)答，而可以繼續(xù)發(fā)送數(shù)據(jù)的最大值。

TCP頭部有個(gè)字段叫win，也即那個(gè)16位的窗口大小，它告訴對(duì)方本端的TCP接收緩沖區(qū)還能容納多少字節(jié)的數(shù)據(jù)，這樣對(duì)方就可以控制發(fā)送數(shù)據(jù)的速度，從而達(dá)到流量控制的目的。

★通俗點(diǎn)講，就是接受方每次收到數(shù)據(jù)包，在發(fā)送確認(rèn)報(bào)文的時(shí)候，同時(shí)告訴發(fā)送方，自己的緩存區(qū)還有多少空余空間，緩沖區(qū)的空余空間，我們就稱(chēng)之為接受窗口大小。這就是win。
”

TCP 滑動(dòng)窗口分為兩種: 發(fā)送窗口和接收窗口。發(fā)送端的滑動(dòng)窗口包含四大部分，如下：

已發(fā)送且已收到ACK確認(rèn)
已發(fā)送但未收到ACK確認(rèn)
未發(fā)送但可以發(fā)送
未發(fā)送也不可以發(fā)送

虛線(xiàn)矩形框，就是發(fā)送窗口。
SND.WND: 表示發(fā)送窗口的大小,上圖虛線(xiàn)框的格子數(shù)就是14個(gè)。
SND.UNA: 一個(gè)絕對(duì)指針，它指向的是已發(fā)送但未確認(rèn)的第一個(gè)字節(jié)的序列號(hào)。
SND.NXT：下一個(gè)發(fā)送的位置，它指向未發(fā)送但可以發(fā)送的第一個(gè)字節(jié)的序列號(hào)。

接收方的滑動(dòng)窗口包含三大部分，如下：

已成功接收并確認(rèn)
未收到數(shù)據(jù)但可以接收
未收到數(shù)據(jù)并不可以接收的數(shù)據(jù)

虛線(xiàn)矩形框，就是接收窗口。
REV.WND: 表示接收窗口的大小,上圖虛線(xiàn)框的格子就是9個(gè)。
REV.NXT:下一個(gè)接收的位置，它指向未收到但可以接收的第一個(gè)字節(jié)的序列號(hào)。

11. 聊聊TCP的流量控制

TCP三次握手，發(fā)送端和接收端進(jìn)入到ESTABLISHED狀態(tài)，它們即可以愉快地傳輸數(shù)據(jù)啦。

但是發(fā)送端不能瘋狂地向接收端發(fā)送數(shù)據(jù)，因?yàn)榻邮斩私邮詹贿^(guò)來(lái)的話(huà)，接收方只能把處理不過(guò)來(lái)的數(shù)據(jù)存在緩存區(qū)里。如果緩存區(qū)都滿(mǎn)了，發(fā)送方還在瘋狂發(fā)送數(shù)據(jù)的話(huà)，接收方只能把收到的數(shù)據(jù)包丟掉，這就浪費(fèi)了網(wǎng)絡(luò)資源啦。

★TCP 提供一種機(jī)制可以讓發(fā)送端根據(jù)接收端的實(shí)際接收能力控制發(fā)送的數(shù)據(jù)量，這就是流量控制。
”

TCP通過(guò)滑動(dòng)窗口來(lái)控制流量，我們看下流量控制的簡(jiǎn)要流程吧：

首先雙方三次握手，初始化各自的窗口大小，均為 400 個(gè)字節(jié)。

TCP的流量控制

假如當(dāng)前發(fā)送方給接收方發(fā)送了200個(gè)字節(jié)，那么，發(fā)送方的SND.NXT會(huì)右移200個(gè)字節(jié)，也就是說(shuō)當(dāng)前的可用窗口減少了200 個(gè)字節(jié)。
接受方收到后，放到緩沖隊(duì)列里面，REV.WND =400-200=200字節(jié)，所以win=200字節(jié)返回給發(fā)送方。接收方會(huì)在 ACK 的報(bào)文首部帶上縮小后的滑動(dòng)窗口200字節(jié)
發(fā)送方又發(fā)送200字節(jié)過(guò)來(lái)，200字節(jié)到達(dá)，繼續(xù)放到緩沖隊(duì)列。不過(guò)這時(shí)候，由于大量負(fù)載的原因，接受方處理不了這么多字節(jié)，只能處理100字節(jié)，剩余的100字節(jié)繼續(xù)放到緩沖隊(duì)列。這時(shí)候，REV.WND = 400-200-100=100字節(jié)，即win=100返回發(fā)送方。
發(fā)送方繼續(xù)干活，發(fā)送100字節(jié)過(guò)來(lái)，這時(shí)候，接受窗口win變?yōu)?。
發(fā)送方停止發(fā)送，開(kāi)啟一個(gè)定時(shí)任務(wù)，每隔一段時(shí)間，就去詢(xún)問(wèn)接受方，直到win大于0，才繼續(xù)開(kāi)始發(fā)送。

12. TCP的擁塞控制

擁塞控制是作用于網(wǎng)絡(luò)的，防止過(guò)多的數(shù)據(jù)包注入到網(wǎng)絡(luò)中，避免出現(xiàn)網(wǎng)絡(luò)負(fù)載過(guò)大的情況。它的目標(biāo)主要是最大化利用網(wǎng)絡(luò)上瓶頸鏈路的帶寬。它跟流量控制又有什么區(qū)別呢？流量控制是作用于接收者的，根據(jù)接收端的實(shí)際接收能力控制發(fā)送速度，防止分組丟失的。

我們可以把網(wǎng)絡(luò)鏈路比喻成一根水管，如果我們想最大化利用網(wǎng)絡(luò)來(lái)傳輸數(shù)據(jù)，那就是盡快讓水管達(dá)到最佳充滿(mǎn)狀態(tài)。

發(fā)送方維護(hù)一個(gè)擁塞窗口cwnd（congestion window） 的變量，用來(lái)估算在一段時(shí)間內(nèi)這條鏈路（水管）可以承載和運(yùn)輸?shù)臄?shù)據(jù)（水）的數(shù)量。它大小代表著網(wǎng)絡(luò)的擁塞程度，并且是動(dòng)態(tài)變化的，但是為了達(dá)到最大的傳輸效率，我們?cè)撊绾沃肋@條水管的運(yùn)送效率是多少呢？

一個(gè)比較簡(jiǎn)單的方法就是不斷增加傳輸?shù)乃?，直到水管快要爆裂為止（?duì)應(yīng)到網(wǎng)絡(luò)上就是發(fā)生丟包），用 TCP 的描述就是：

★只要網(wǎng)絡(luò)中沒(méi)有出現(xiàn)擁塞，擁塞窗口的值就可以再增大一些，以便把更多的數(shù)據(jù)包發(fā)送出去，但只要網(wǎng)絡(luò)出現(xiàn)擁塞，擁塞窗口的值就應(yīng)該減小一些，以減少注入到網(wǎng)絡(luò)中的數(shù)據(jù)包數(shù)。
”

實(shí)際上，擁塞控制主要有這幾種常用算法

慢啟動(dòng)
擁塞避免
擁塞發(fā)生
快速恢復(fù)

慢啟動(dòng)算法

慢啟動(dòng)算法，表面意思就是，別急慢慢來(lái)。它表示TCP建立連接完成后，一開(kāi)始不要發(fā)送大量的數(shù)據(jù)，而是先探測(cè)一下網(wǎng)絡(luò)的擁塞程度。由小到大逐漸增加擁塞窗口的大小，如果沒(méi)有出現(xiàn)丟包，每收到一個(gè)ACK，就將擁塞窗口cwnd大小就加1（單位是MSS）。每輪次發(fā)送窗口增加一倍，呈指數(shù)增長(zhǎng)，如果出現(xiàn)丟包，擁塞窗口就減半，進(jìn)入擁塞避免階段。

TCP連接完成，初始化cwnd = 1，表明可以傳一個(gè)MSS單位大小的數(shù)據(jù)。
每當(dāng)收到一個(gè)ACK，cwnd就加一;
每當(dāng)過(guò)了一個(gè)RTT，cwnd就增加一倍; 呈指數(shù)讓升

為了防止cwnd增長(zhǎng)過(guò)大引起網(wǎng)絡(luò)擁塞，還需設(shè)置一個(gè)慢啟動(dòng)閥值ssthresh（slow start threshold）狀態(tài)變量。當(dāng)cwnd到達(dá)該閥值后，就好像水管被關(guān)小了水龍頭一樣，減少擁塞狀態(tài)。即當(dāng)cwnd >ssthresh時(shí)，進(jìn)入了擁塞避免算法。

擁塞避免算法

一般來(lái)說(shuō)，慢啟動(dòng)閥值ssthresh是65535字節(jié)，cwnd到達(dá)慢啟動(dòng)閥值后

每收到一個(gè)ACK時(shí)，cwnd = cwnd 1/cwnd
當(dāng)每過(guò)一個(gè)RTT時(shí)，cwnd = cwnd 1

顯然這是一個(gè)線(xiàn)性上升的算法，避免過(guò)快導(dǎo)致網(wǎng)絡(luò)擁塞問(wèn)題。

擁塞發(fā)生

當(dāng)網(wǎng)絡(luò)擁塞發(fā)生丟包時(shí)，會(huì)有兩種情況：

RTO超時(shí)重傳
快速重傳

如果是發(fā)生了RTO超時(shí)重傳，就會(huì)使用擁塞發(fā)生算法

慢啟動(dòng)閥值sshthresh = ?cwnd /2
cwnd 重置為 1
進(jìn)入新的慢啟動(dòng)過(guò)程

這真的是辛辛苦苦幾十年，一朝回到解放前。其實(shí)還有更好的處理方式，就是快速重傳。發(fā)送方收到3個(gè)連續(xù)重復(fù)的ACK時(shí)，就會(huì)快速地重傳，不必等待RTO超時(shí)再重傳。

image.png

慢啟動(dòng)閥值ssthresh 和 cwnd 變化如下：

擁塞窗口大小 cwnd = cwnd/2
慢啟動(dòng)閥值 ssthresh = cwnd
進(jìn)入快速恢復(fù)算法

快速恢復(fù)

快速重傳和快速恢復(fù)算法一般同時(shí)使用?？焖倩謴?fù)算法認(rèn)為，還有3個(gè)重復(fù)ACK收到，說(shuō)明網(wǎng)絡(luò)也沒(méi)那么糟糕，所以沒(méi)有必要像RTO超時(shí)那么強(qiáng)烈。

正如前面所說(shuō)，進(jìn)入快速恢復(fù)之前，cwnd 和 sshthresh已被更新：

-?cwnd?=?cwnd?/2
-?sshthresh?=?cwnd

然后，真正的快速算法如下：

cwnd = sshthresh ? 3
重傳重復(fù)的那幾個(gè)ACK（即丟失的那幾個(gè)數(shù)據(jù)包）
如果再收到重復(fù)的 ACK，那么 cwnd = cwnd 1
如果收到新數(shù)據(jù)的 ACK 后, cwnd = sshthresh。因?yàn)槭盏叫聰?shù)據(jù)的 ACK，表明恢復(fù)過(guò)程已經(jīng)結(jié)束，可以再次進(jìn)入了擁塞避免的算法了。

13. 半連接隊(duì)列和 SYN Flood 攻擊的關(guān)系

TCP進(jìn)入三次握手前，服務(wù)端會(huì)從CLOSED狀態(tài)變?yōu)?strong>LISTEN狀態(tài),同時(shí)在內(nèi)部創(chuàng)建了兩個(gè)隊(duì)列：半連接隊(duì)列（SYN隊(duì)列）和全連接隊(duì)列（ACCEPT隊(duì)列）。

什么是半連接隊(duì)列（SYN隊(duì)列） 呢? 什么是全連接隊(duì)列（ACCEPT隊(duì)列） 呢？回憶下TCP三次握手的圖：

三次握手

TCP三次握手時(shí)，客戶(hù)端發(fā)送SYN到服務(wù)端，服務(wù)端收到之后，便回復(fù)ACK和SYN，狀態(tài)由LISTEN變?yōu)镾YN_RCVD，此時(shí)這個(gè)連接就被推入了SYN隊(duì)列，即半連接隊(duì)列。
當(dāng)客戶(hù)端回復(fù)ACK, 服務(wù)端接收后，三次握手就完成了。這時(shí)連接會(huì)等待被具體的應(yīng)用取走，在被取走之前，它被推入ACCEPT隊(duì)列，即全連接隊(duì)列。

SYN Flood是一種典型的DoS (Denial of Service，拒絕服務(wù)) 攻擊，它在短時(shí)間內(nèi)，偽造不存在的IP地址,向服務(wù)器大量發(fā)起SYN報(bào)文。當(dāng)服務(wù)器回復(fù)SYN ACK報(bào)文后，不會(huì)收到ACK回應(yīng)報(bào)文，導(dǎo)致服務(wù)器上建立大量的半連接半連接隊(duì)列滿(mǎn)了，這就無(wú)法處理正常的TCP請(qǐng)求啦。

主要有 syn cookie和SYN Proxy防火墻等方案應(yīng)對(duì)。

syn cookie：在收到SYN包后，服務(wù)器根據(jù)一定的方法，以數(shù)據(jù)包的源地址、端口等信息為參數(shù)計(jì)算出一個(gè)cookie值作為自己的SYNACK包的序列號(hào)，回復(fù)SYN ACK后，服務(wù)器并不立即分配資源進(jìn)行處理，等收到發(fā)送方的ACK包后，重新根據(jù)數(shù)據(jù)包的源地址、端口計(jì)算該包中的確認(rèn)序列號(hào)是否正確，如果正確則建立連接，否則丟棄該包。
SYN Proxy防火墻：服務(wù)器防火墻會(huì)對(duì)收到的每一個(gè)SYN報(bào)文進(jìn)行代理和回應(yīng)，并保持半連接。等發(fā)送方將ACK包返回后，再重新構(gòu)造SYN包發(fā)到服務(wù)器，建立真正的TCP連接。

14. Nagle 算法與延遲確認(rèn)

Nagle算法

如果發(fā)送端瘋狂地向接收端發(fā)送很小的包，比如就1個(gè)字節(jié)，那么親愛(ài)的小伙伴，你們覺(jué)得會(huì)有什么問(wèn)題呢？

★TCP/IP協(xié)議中，無(wú)論發(fā)送多少數(shù)據(jù)，總是要在數(shù)據(jù)前面加上協(xié)議頭，同時(shí)，對(duì)方接收到數(shù)據(jù)，也需要發(fā)送ACK表示確認(rèn)。為了盡可能的利用網(wǎng)絡(luò)帶寬，TCP總是希望盡可能的發(fā)送足夠大的數(shù)據(jù)。Nagle算法就是為了盡可能發(fā)送大塊數(shù)據(jù)，避免網(wǎng)絡(luò)中充斥著許多小數(shù)據(jù)塊。
”

Nagle算法的基本定義是：任意時(shí)刻，最多只能有一個(gè)未被確認(rèn)的小段。所謂“小段”，指的是小于MSS尺寸的數(shù)據(jù)塊，所謂“未被確認(rèn)”，是指一個(gè)數(shù)據(jù)塊發(fā)送出去后，沒(méi)有收到對(duì)方發(fā)送的ACK確認(rèn)該數(shù)據(jù)已收到。

Nagle算法的實(shí)現(xiàn)規(guī)則：

如果包長(zhǎng)度達(dá)到MSS，則允許發(fā)送；
如果該包含有FIN，則允許發(fā)送；
設(shè)置了TCP_NODELAY選項(xiàng)，則允許發(fā)送；
未設(shè)置TCP_CORK選項(xiàng)時(shí)，若所有發(fā)出去的小數(shù)據(jù)包（包長(zhǎng)度小于MSS）均被確認(rèn)，則允許發(fā)送；
上述條件都未滿(mǎn)足，但發(fā)生了超時(shí)（一般為200ms），則立即發(fā)送。

延遲確認(rèn)

如果接受方剛接收到發(fā)送方的數(shù)據(jù)包，在很短很短的時(shí)間內(nèi)，又接收到第二個(gè)包。那么請(qǐng)問(wèn)接收方是一個(gè)一個(gè)地回復(fù)好點(diǎn)，還是合并一起回復(fù)好呢？

★接收方收到數(shù)據(jù)包后，如果暫時(shí)沒(méi)有數(shù)據(jù)要發(fā)給對(duì)端，它可以等一段時(shí)再確認(rèn)（Linux上默認(rèn)是40ms）。如果這段時(shí)間剛好有數(shù)據(jù)要傳給對(duì)端，ACK就隨著數(shù)據(jù)傳輸，而不需要單獨(dú)發(fā)送一次ACK。如果超過(guò)時(shí)間還沒(méi)有數(shù)據(jù)要發(fā)送，也發(fā)送ACK，避免對(duì)端以為丟包。
”

但是有些場(chǎng)景不能延遲確認(rèn)，比如發(fā)現(xiàn)了亂序包、接收到了大于一個(gè) frame 的報(bào)文，且需要調(diào)整窗口大小等。

一般情況下，Nagle算法和延遲確認(rèn)不能一起使用，Nagle算法意味著延遲發(fā)，延遲確認(rèn)意味著延遲接收，醬紫就會(huì)造成更大的延遲，會(huì)產(chǎn)生性能問(wèn)題。

15. TCP的粘包和拆包

TCP是面向流，沒(méi)有界限的一串?dāng)?shù)據(jù)。TCP底層并不了解上層業(yè)務(wù)數(shù)據(jù)的具體含義，它會(huì)根據(jù)TCP緩沖區(qū)的實(shí)際情況進(jìn)行包的劃分，所以在業(yè)務(wù)上認(rèn)為，一個(gè)完整的包可能會(huì)被TCP拆分成多個(gè)包進(jìn)行發(fā)送，也有可能把多個(gè)小的包封裝成一個(gè)大的數(shù)據(jù)包發(fā)送，這就是所謂的TCP粘包和拆包問(wèn)題。

TCP的粘包和拆包

為什么會(huì)產(chǎn)生粘包和拆包呢?

要發(fā)送的數(shù)據(jù)小于TCP發(fā)送緩沖區(qū)的大小，TCP將多次寫(xiě)入緩沖區(qū)的數(shù)據(jù)一次發(fā)送出去，將會(huì)發(fā)生粘包；
接收數(shù)據(jù)端的應(yīng)用層沒(méi)有及時(shí)讀取接收緩沖區(qū)中的數(shù)據(jù)，將發(fā)生粘包；
要發(fā)送的數(shù)據(jù)大于TCP發(fā)送緩沖區(qū)剩余空間大小，將會(huì)發(fā)生拆包；
待發(fā)送數(shù)據(jù)大于MSS（最大報(bào)文長(zhǎng)度），TCP在傳輸前將進(jìn)行拆包。即TCP報(bào)文長(zhǎng)度-TCP頭部長(zhǎng)度>MSS。

解決方案：

發(fā)送端將每個(gè)數(shù)據(jù)包封裝為固定長(zhǎng)度
在數(shù)據(jù)尾部增加特殊字符進(jìn)行分割
將數(shù)據(jù)分為兩部分，一部分是頭部，一部分是內(nèi)容體；其中頭部結(jié)構(gòu)大小固定，且有一個(gè)字段聲明內(nèi)容體的大小。