通過(guò)本文你將了解到以下內(nèi)容：

• 擁塞控制概念以及其背景
• 流量控制和擁塞控制的區(qū)別與聯(lián)系
• 擁塞控制主要過(guò)程詳解

伙伴們認(rèn)真學(xué)習(xí)一下，讓offer來(lái)得更猛烈些吧！

0x01.TCP/IP協(xié)議棧簡(jiǎn)要回顧

來(lái)看下維基百科對(duì)TCP/IP的一些介紹，筆者做了少量的修改來(lái)確保語(yǔ)句通順：

互聯(lián)網(wǎng)協(xié)議套件是一個(gè)網(wǎng)絡(luò)通信模型以及整個(gè)網(wǎng)絡(luò)傳輸協(xié)議家族，由于該協(xié)議簇包含兩個(gè)核心協(xié)議：TCP（傳輸控制協(xié)議）和IP（網(wǎng)際協(xié)議），因此常被通稱為 TCP/IP協(xié)議族 。

TCP/IP協(xié)議對(duì)于數(shù)據(jù)應(yīng)該如何封裝、定址、傳輸、路由以及在目的地如何接收等基本過(guò)程都加以標(biāo)準(zhǔn)化。它將通信過(guò)程 抽象化為四個(gè)層次 ，并采取協(xié)議堆棧的方式分別實(shí)現(xiàn)出不同通信協(xié)議，實(shí)際使用的四層結(jié)構(gòu)是七層OSI模型的簡(jiǎn)化。

我們可以看到TCP/IP協(xié)議棧是一個(gè)簡(jiǎn)化的分層模型，是互聯(lián)網(wǎng)世界連接一切的基石，一起來(lái)看一張 七層模型vs四層模型 的簡(jiǎn)圖：

TCP/IP協(xié)議棧過(guò)于龐大，篇幅所限本文不再做更多細(xì)節(jié)的描述。

0x02.流量控制和擁塞控制

TCP是一種面向連接的、可靠的、全雙工傳輸協(xié)議，前輩們寫了很多復(fù)雜的算法為其保駕護(hù)航，其中有一組像 海爾兄弟一樣 的算法： 流量控制和擁塞控制 ，這也是我們今天的主角。

2.1 流量控制簡(jiǎn)介

流量控制和擁塞控制從漢語(yǔ)字面上并不能很好的區(qū)分，本質(zhì)上這一對(duì)算法既有區(qū)別也有聯(lián)系。

維基百科對(duì)于 流量控制Flow Control 的說(shuō)明：

In data communications, flow control is the process of managing the rate of data transmission between two nodes to prevent a fast sender from overwhelming a slow receiver.

It provides a mechanism for the receiver to control the transmission speed, so that the receiving node is not overwhelmed with data from transmitting node.

翻譯一下：

在數(shù)據(jù)通信中，流量控制是管理兩個(gè)節(jié)點(diǎn)之間數(shù)據(jù)傳輸速率的過(guò)程，以防止快速發(fā)送方壓倒慢速接收方。

它為接收機(jī)提供了一種控制傳輸速度的機(jī)制，這樣接收節(jié)點(diǎn)就不會(huì)被來(lái)自發(fā)送節(jié)點(diǎn)的數(shù)據(jù)淹沒(méi)。

可以看到流量控制是通信雙方之間約定數(shù)據(jù)量的一種機(jī)制，具體來(lái)說(shuō)是借助于TCP協(xié)議的確認(rèn)ACK機(jī)制和窗口協(xié)議來(lái)完成的。

窗口分為 固定窗口和可變窗口 ，可變窗口也就是 滑動(dòng)窗口 ，簡(jiǎn)單來(lái)說(shuō)就是通信雙方根據(jù)接收方的接收情況動(dòng)態(tài)告訴發(fā)送端可以發(fā)送的數(shù)據(jù)量，從而實(shí)現(xiàn)發(fā)送方和接收方的數(shù)據(jù) 收發(fā)能力匹配 。

這個(gè)過(guò)程非常容易捕捉，使用 wireshark在電腦上抓或者tcpdump在服務(wù)器 上抓都可以看到，大白在自己電腦上用wireshark抓了一條：

我們以兩個(gè)主機(jī)交互來(lái)簡(jiǎn)單理解流量控制過(guò)程：

接收方回復(fù)報(bào)文頭部解釋：

圖中RcvBuffer是接收區(qū)總大小，buffered data是當(dāng)前已經(jīng)占用的數(shù)據(jù)，而free buffer space是當(dāng)前剩余的空間，rwnd的就是free buffer space區(qū)域的字節(jié)數(shù)。

HostB把當(dāng)前的rwnd值放入報(bào)文頭部的接收窗口receive window字段中，以此通知HostA自己還有多少可用空間， 而HostA則將未確認(rèn)的數(shù)據(jù)量控制在rwnd值的范圍內(nèi)，從而避免HostB的接收緩存溢出。

可見(jiàn) 流量控制是端到端微觀層面的數(shù)據(jù)策略 ，雙方在數(shù)據(jù)通信的過(guò)程中并不關(guān)心鏈路帶寬情況，只關(guān)心通信雙方的接收發(fā)送緩沖區(qū)的空間大小，可以說(shuō)是個(gè) 速率流量匹配策略 。

流量控制就像現(xiàn)實(shí)生活中物流領(lǐng)域中A和B兩個(gè)倉(cāng)庫(kù)，A往B運(yùn)送貨物時(shí)只關(guān)心倉(cāng)庫(kù)B的剩余空間來(lái)調(diào)整自己的發(fā)貨量，而不關(guān)心高速是否擁堵。

2.2 擁塞控制的必要性

前面我們提到了微觀層面點(diǎn)到點(diǎn)的流量控制，但是我們不由地思考一個(gè)問(wèn)題： 只有流量控制夠嗎？答案是否定的。

我們還需要一個(gè)宏觀層面的控去避免網(wǎng)絡(luò)鏈路的擁堵，否則再好的端到端流量控制算法也面臨 丟包、亂序、重傳 問(wèn)題，只能造成惡性循環(huán)。

我們從一個(gè)更高的角度去看 大量TCP連接復(fù)用網(wǎng)絡(luò)鏈路 的通信過(guò)程：

所以擁塞控制和每一條端到端的連接關(guān)系非常大，這就是流量控制和擁塞控制的深層次聯(lián)系，所謂每一條連接都順暢那么整個(gè)復(fù)雜的網(wǎng)絡(luò)鏈路也很大程度是通暢的。

在展開擁塞控制之前我們先考慮幾個(gè)問(wèn)題：

• 如何感知擁塞

TCP連接的發(fā)送方在向?qū)Χ税l(fā)送數(shù)據(jù)的過(guò)程中，需要根據(jù)當(dāng)前的網(wǎng)絡(luò)狀況來(lái)調(diào)整發(fā)送速率，所以感知能力很關(guān)鍵。

在TCP連接的發(fā)送方一般是 基于丟包 來(lái)判斷當(dāng)前網(wǎng)絡(luò)是否發(fā)生擁塞，丟包可以由 重傳超時(shí)RTO和重復(fù)確認(rèn) 來(lái)做判斷。

• 如何利用帶寬

誠(chéng)然擁塞影響很大，但是一直低速發(fā)包對(duì)帶寬利用率很低也是很不明智的做法，因此要充分利用帶寬就不能過(guò)低過(guò)高發(fā)送數(shù)據(jù)，而是保持在一個(gè)動(dòng)態(tài)穩(wěn)定的速率來(lái)提高帶寬利用率，這個(gè)還是比較難的， 就像茫茫黑夜去躲避障礙物 。

• 擁塞時(shí)如何調(diào)整

擁塞發(fā)生時(shí)我們需要有一套應(yīng)對(duì)措施來(lái)防止擁塞惡化并且恢復(fù)連接流量，這也是擁塞控制算法的精要所在。

0x03.理解擁塞控制

前面我們提了擁塞控制的必要性以及重要問(wèn)題，接下來(lái)一起看下前輩們是如何設(shè)計(jì)實(shí)現(xiàn)精彩的擁塞控制策略的吧！

3.1 擁塞窗口cwnd

從流量控制可以知道接收方在header中給出了rwnd接收窗口大小，發(fā)送方不能自顧自地按照接收方的rwnd限制來(lái)發(fā)送數(shù)據(jù)，因?yàn)榫W(wǎng)絡(luò)鏈路是復(fù)用的，需要考慮當(dāng)前鏈路情況來(lái)確定數(shù)據(jù)量，這也是我們要提的另外一個(gè)變量cwnd，筆者找了一個(gè)關(guān)于rwnd和cwnd的英文解釋：

Congestion Window (cwnd) is a TCP state variable that limits the amount of data the TCP can send into the network before receiving an ACK.

The Receiver Window (rwnd) is a variable that advertises the amount of data that the destination side can receive.

Together, the two variables are used to regulate data flow in TCP connections, minimize congestion, and improve network performance.

筆者在rfc5681文檔中也看到cwnd的定義：

這個(gè)解釋指出了cwnd是在發(fā)送方維護(hù)的，cwnd和rwnd并不沖突，發(fā)送方需要結(jié)合rwnd和cwnd兩個(gè)變量來(lái)發(fā)送數(shù)據(jù)，如圖所示：

cwnd的大小和MSS最大數(shù)據(jù)段有直接關(guān)系，MSS是TCP報(bào)文段中的數(shù)據(jù)字段的最大長(zhǎng)度，即MSS=TCP報(bào)文段長(zhǎng)度-TCP首部長(zhǎng)度。

3.2 擁塞控制基本策略

擁塞控制是一個(gè)動(dòng)態(tài)的過(guò)程 ，它既要提高帶寬利用率發(fā)送盡量多的數(shù)據(jù)又要避免網(wǎng)絡(luò)擁堵丟包RTT增大等問(wèn)題，基于這種高要求并不是單一策略可以搞定的，因此TCP的擁塞控制策略實(shí)際上是 分階段分策略的綜合過(guò)程 ：

注： 有的版本的TCP算法不一定沒(méi)有快速恢復(fù)階段

如圖為典型的包含4個(gè)策略的擁塞控制：

如圖為發(fā)生超時(shí)重傳RTO時(shí)的過(guò)程：

3.3 TCP算法常見(jiàn)版本

實(shí)際上TCP算法有很多版本，每個(gè)版本存在一些差異，在這里簡(jiǎn)單看一下維基百科的介紹：

• 算法命名規(guī)則

TCP+算法名的命名方式最早出現(xiàn)在Kevin Fall和Sally Floyd1996年發(fā)布的論文中。

• TCP Tahoe 和TCP Reno

這兩個(gè)算法代號(hào)取自太浩湖Lake Tahoe和里諾市，兩者算法大致一致，對(duì)于丟包事件判斷都是以重傳超時(shí)retransmission timeout和重復(fù)確認(rèn)為條件，但是對(duì)于重復(fù)確認(rèn)的處理兩者有所不同，對(duì)于 超時(shí)重傳RTO情況兩個(gè)算法都是將擁塞窗口降為1個(gè)MSS ，然后進(jìn)入慢啟動(dòng)階段。

TCP Tahoe算法 ：如果收到三次重復(fù)確認(rèn)即第四次收到相同確認(rèn)號(hào)的分段確認(rèn)，并且分段對(duì)應(yīng)包無(wú)負(fù)載分段和無(wú)改變接收窗口的話，Tahoe算法則進(jìn)入快速重傳，將慢啟動(dòng)閾值改為當(dāng)前擁塞窗口的一半，將擁塞窗口降為1個(gè)MSS，并重新進(jìn)入慢啟動(dòng)階段。

TCP Reno算法 ：如果收到三次重復(fù)確認(rèn)，Reno算法則進(jìn)入快速重傳只將擁塞窗口減半來(lái)跳過(guò)慢啟動(dòng)階段，將慢啟動(dòng)閾值設(shè)為當(dāng)前新的擁塞窗口值，進(jìn)入一個(gè)稱為快速恢復(fù)的新設(shè)計(jì)階段。

• TCP New Reno

TCP New Reno是對(duì)TCP Reno中快速恢復(fù)階段的重傳進(jìn)行改善的一種改進(jìn)算法，New Reno在低錯(cuò)誤率時(shí)運(yùn)行效率和選擇確認(rèn)SACK相當(dāng)，在高錯(cuò)誤率仍優(yōu)于Reno。

• TCP BIC 和TCP CUBIC

TCP BIC旨在優(yōu)化高速高延遲網(wǎng)絡(luò)的擁塞控制，其擁塞窗口算法使用二分搜索算法嘗試找到能長(zhǎng)時(shí)間保持擁塞窗口最大值， Linux內(nèi)核在2.6.8至2.6.18使用該算法作為默認(rèn)TCP擁塞算法 。

CUBIC則是比BIC更溫和和系統(tǒng)化的分支版本，其使用三次函數(shù)代替二分算法作為其擁塞窗口算法，并且使用函數(shù)拐點(diǎn)作為擁塞窗口的設(shè)置值， Linux內(nèi)核在2.6.19后使用該算法作為默認(rèn)TCP擁塞算法 。

• TCP PRR

TCP PRR是旨在恢復(fù)期間提高發(fā)送數(shù)據(jù)的準(zhǔn)確性，該算法確?；謴?fù)后的擁塞窗口大小盡可能接近慢啟動(dòng)閾值。在Google進(jìn)行的測(cè)試中，能將平均延遲降低3~10%恢復(fù)超時(shí)減少5%， PRR算法后作為L(zhǎng)inux內(nèi)核3.2版本默認(rèn)擁塞算法 。

• TCP BBR

TCP BBR是由Google設(shè)計(jì)于2016年發(fā)布的擁塞算法 ，該算法認(rèn)為隨著網(wǎng)絡(luò)接口控制器逐漸進(jìn)入千兆速度時(shí)，分組丟失不應(yīng)該被認(rèn)為是識(shí)別擁塞的主要決定因素，所以基于模型的擁塞控制算法能有更高的吞吐量和更低的延遲，可以用BBR來(lái)替代其他流行的擁塞算法。

Google在YouTube上應(yīng)用該算法，將全球平均的YouTube網(wǎng)絡(luò)吞吐量提高了4%， BBR 之后移植入Linux內(nèi)核4.9版本 。

3.4 擁塞控制過(guò)程詳解

我們以典型 慢啟動(dòng)、擁塞避免、快速重傳、快速恢復(fù) 四個(gè)過(guò)程進(jìn)行闡述。

• 慢啟動(dòng)

慢啟動(dòng)就是對(duì)于剛啟動(dòng)的網(wǎng)絡(luò)連接，發(fā)送速度不是一步到位而是試探性增長(zhǎng)，具體來(lái)說(shuō)：連接最初建立時(shí)發(fā)送方初始化擁塞窗口cwnd為m，之后發(fā)送方在一個(gè)RTT內(nèi) 每收到一個(gè)ACK數(shù)據(jù)包時(shí)cwnd線性自增1 ，發(fā)送方 每經(jīng)過(guò)一個(gè)RTT時(shí)間，cwnd=cwnd*2 指數(shù)增長(zhǎng)，經(jīng)過(guò)一段時(shí)間增長(zhǎng)直到cwnd達(dá)到慢啟動(dòng)閾值ssthresh。

之后cwnd不再呈指數(shù)增長(zhǎng)從而進(jìn)入擁塞避免階段(注cwnd增長(zhǎng)的單位是MSS)，當(dāng)然如果在慢啟動(dòng)階段還未到達(dá)閾值ssthresh而出現(xiàn)丟包時(shí)進(jìn)入快速重傳等階段，需要注意的是 如果網(wǎng)絡(luò)狀況良好RTT時(shí)間很短，那么慢啟動(dòng)階段將很快到達(dá)一個(gè)比較高的發(fā)送速率 ，所以將 慢啟動(dòng)理解為試探啟動(dòng) 更形象。

• 擁塞避免

當(dāng)慢啟動(dòng)階段cwnd的值到達(dá)ssthresh時(shí)就不再瘋狂增長(zhǎng)，進(jìn)入更加理性的線性階段直至發(fā)送丟包，本次的閾值ssthresh是上一次發(fā)生丟包時(shí)cwnd的1/2，因此這是一個(gè)承上啟下的過(guò)程。

本次發(fā)送丟包時(shí)仍然會(huì)調(diào)整ssthresh的值，具體擁塞避免增長(zhǎng)過(guò)程： 發(fā)送方每收到一個(gè)ACK數(shù)據(jù)包時(shí)將cwnd=cwnd+1/cwnd，每經(jīng)過(guò)一個(gè)RTT將cwnd自增1 。

• 超時(shí)重傳和快速重傳

TCP作為一個(gè)可靠的協(xié)議面臨的很大的問(wèn)題就是丟包，丟包就要重傳因此發(fā)送方需要根據(jù)接收方回復(fù)的ACK來(lái)確認(rèn)是否丟包了，并且發(fā)送方在發(fā)送數(shù)據(jù)之后啟動(dòng)定時(shí)器，如圖所示：

RTO是隨著復(fù)雜網(wǎng)絡(luò)環(huán)境而動(dòng)態(tài)變化的，在擁塞控制中發(fā)生超時(shí)重傳將會(huì)極大拉低cwnd，如果網(wǎng)絡(luò)狀況并沒(méi)有那么多糟糕， 偶爾出現(xiàn)網(wǎng)絡(luò)抖動(dòng)造成丟包或者阻塞也非常常見(jiàn) ，因此觸發(fā)的慢啟動(dòng)將降低通信性能，故出現(xiàn)了快速重傳機(jī)制。

所謂 快速重傳時(shí)相比超時(shí)重傳而言的 ，重發(fā)等待時(shí)間會(huì)降低并且后續(xù)盡量避免慢啟動(dòng)，來(lái)保證性能損失在最小的程度，如圖所示：

快速重傳和超時(shí)重傳的區(qū)別在于cwnd在發(fā)生擁塞時(shí)的取值， 超時(shí)重傳會(huì)將cwnd修改為最初的值，也就是慢啟動(dòng)的值，快速重傳將cwnd減半，二者都將ssthresh設(shè)置為cwnd的一半 。

從二者的區(qū)別可以看到，快速重傳更加主動(dòng)，有利于保證鏈路的傳輸性能，但是有研究表明3個(gè)ACK的機(jī)制同樣存在問(wèn)題，本文就不做深入闡述了，感興趣的讀者可以自主查閱。

快速重傳是基于對(duì)網(wǎng)絡(luò)狀況沒(méi)有那么糟糕的假設(shè)，因此在實(shí)際網(wǎng)絡(luò)確實(shí)還算好的時(shí)候，快速重傳還是很有用的，在很差的網(wǎng)絡(luò)環(huán)境很多算法都很難保證效率的。

• 快速恢復(fù)

在快速重傳之后就會(huì)進(jìn)入快速恢復(fù)階段，此時(shí)的cwnd為上次發(fā)生擁塞時(shí)的cwnd的1/2，之后cwnd再線性增加重復(fù)之前的過(guò)程。