圖解 - 什麼是 TCP 擁塞控制及谷歌的 BBR 算法

1. 擁塞控制簡史

來看下維基百科對 TCP/IP 協議棧的一些介紹，筆者做了少量的修改來確保語句通順：

 

互聯網協議套件是一個網絡通信模型以及整個網絡傳輸協議家族，由於該協議簇包含兩個核心協議：TCP（傳輸控制協議）和 IP（網際協議），因此常被通稱爲 TCP/IP 協議族。

 

TCP/IP 協議對於數據應該如何封裝、定址、傳輸、路由以及在目的地如何接收等基本過程都加以標準化。它將通信過程抽象化爲四個層次，並採取協議堆棧的方式分別實現出不同通信協議，實際使用的四層結構是七層 OSI 模型的簡化。

我們可以看到 TCP/IP 協議棧是一個簡化的分層模型，是互聯網世界連接一切的基石，一起來看一張七層模型 vs 四層模型的簡圖：

大約在 1988 年之前 TCP/IP 是沒有擁塞控制的，但是隨着網絡接入規模的發展之前僅有的端到端窗口控制已經無法滿足要求，在 1986 年引發大規模網絡癱瘓，此時就要提到一個重量級人物：Van Jacobson 範 · 雅各布森。

這位力挽狂瀾的人物入選了計算機名人堂 Internet Hall of Fame，Van Jacobson 大神提出並設計實施了 TCP/IP 擁塞控制，解決了當時最大的問題，來簡單看下 Van Jacobson 的維基百科簡介 (筆者做了部分刪減)：

範 · 雅各布森 Van Jacobson 是目前作爲互聯網技術基礎的 TCP/IP 協議棧的主要起草者，他以其在網絡性能的提升和優化的開創性成就而聞名。

2006 年 8 月，他加入了帕洛阿爾託研究中心擔任研究員，並在位於相鄰的施樂建築羣的 Packet Design 公司擔任首席科學家。在此之前，他曾是思科系統公司首席科學家，並在位於勞倫斯伯克利國家實驗室的網絡研究小組任領導者。

範 · 雅各布森因爲在提高 IP 網絡性能提升和優化所作的工作而爲人們所知，1988 到 1989 年間，他重新設計了 TCP/IP 的流控制算法（Jacobson 算法），他因設計了 RFC 1144 中的 TCP/IP 頭壓縮協議即範 · 雅各布森 TCP/IP 頭壓縮協議而廣爲人知。此外他也曾與他人合作設計了一些被廣泛使用的網絡診斷工具，如 traceroute，pathchar 以及 tcpdump 。

範 · 雅各布森於 2012 年 4 月入選第一批計算機名人堂，計算機名人堂簡介：https://www.internethalloffame.org/inductees/van-jacobson

如圖爲 Van Jacobson 計算機名人堂的簡介：

筆者找了 Van Jacobson 和 Michael J. Karels 在 1988 年 11 月發佈的關於擁塞避免和控制的論文，總計 25 頁，感興趣的讀者可以查閱：

https://ee.lbl.gov/papers/congavoid.pdf

我們常用的 tracetoute 和 tcpdump 也是 van-jacobson 大神的傑作，作爲互聯網時代的受益者不由得對這些互聯網發展早期做出巨大貢獻的開拓者、創新者、變革者心生讚歎和敬意。

2. 流量控制和擁塞控制

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

2.1 流量控制簡介

流量控制和擁塞控制從漢語字面上並不能很好的區分，本質上這一對算法既有區別也有聯繫。

維基百科對於流量控制 Flow Control 的說明：

 

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.

翻譯一下：

 

在數據通信中，流量控制是管理兩個節點之間數據傳輸速率的過程，以防止快速發送方壓倒慢速接收方。

它爲接收機提供了一種控制傳輸速度的機制，這樣接收節點就不會被來自發送節點的數據淹沒。

可以看到流量控制是通信雙方之間約定數據量的一種機制，具體來說是藉助於 TCP 協議的確認 ACK 機制和窗口協議來完成的。

窗口分爲固定窗口和可變窗口，可變窗口也就是滑動窗口，簡單來說就是通信雙方根據接收方的接收情況動態告訴發送端可以發送的數據量，從而實現發送方和接收方的數據收發能力匹配。

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

我們以兩個主機交互來簡單理解流量控制過程：

接收方回覆報文頭部解釋：

 

圖中 RcvBuffer 是接收區總大小，buffered data 是當前已經佔用的數據，而 free buffer space 是當前剩餘的空間，rwnd 的就是 free buffer space 區域的字節數。

HostB 把當前的 rwnd 值放入報文頭部的接收窗口 receive window 字段中，以此通知 HostA 自己還有多少可用空間， 而 HostA 則將未確認的數據量控制在 rwnd 值的範圍內，從而避免 HostB 的接收緩存溢出。

可見流量控制是端到端微觀層面的數據策略，雙方在數據通信的過程中並不關心鏈路帶寬情況，只關心通信雙方的接收發送緩衝區的空間大小，可以說是個速率流量匹配策略。

流量控制就像現實生活中物流領域中 A 和 B 兩個倉庫，A 往 B 運送貨物時只關心倉庫 B 的剩餘空間來調整自己的發貨量，而不關心高速是否擁堵。

2.2 擁塞控制的必要性

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

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

我們從一個更高的角度去看大量 TCP 連接複用網絡鏈路的通信過程：

所以擁塞控制和每一條端到端的連接關係非常大，這就是流量控制和擁塞控制的深層次聯繫，所謂每一條連接都順暢那麼整個複雜的網絡鏈路也很大程度是通暢的。

在展開擁塞控制之前我們先考慮幾個問題：

• 如何感知擁塞

TCP 連接的發送方在向對端發送數據的過程中，需要根據當前的網絡狀況來調整發送速率，所以感知能力很關鍵。

在 TCP 連接的發送方一般是基於丟包來判斷當前網絡是否發生擁塞，丟包可以由重傳超時 RTO 和重複確認來做判斷。

• 如何利用帶寬

誠然擁塞影響很大，但是一直低速發包對帶寬利用率很低也是很不明智的做法，因此要充分利用帶寬就不能過低過高發送數據，而是保持在一個動態穩定的速率來提高帶寬利用率，這個還是比較難的，就像茫茫黑夜去躲避障礙物。

• 擁塞時如何調整

擁塞發生時我們需要有一套應對措施來防止擁塞惡化並且恢復連接流量，這也是擁塞控制算法的精要所在。

3. 理解擁塞控制

看到一篇文章說到 TCP 傳輸層擁塞控制算法並不是簡單的計算機網絡的概念，也屬於控制論範疇，感覺這個觀點很道理。

TCP 擁塞控制算法的目的可以簡單概括爲：公平競爭、充分利用網絡帶寬、降低網絡延時、優化用戶體驗，然而就目前而言要實現這些目標就難免有權衡和取捨。

在理解擁塞控制算法之前我們需要明確一個核心的思想：聞道有先後 術業有專攻，筆者覺得這是一個非常重要的共識問題，把 A 踩在泥土裏，把 B 吹捧到天上去，都不是很好的做法。

實際的網絡環境十分複雜並且變化很快，並沒有哪個擁塞控制算法可以全部搞定，每一種算法都有自己的特定和適用領域，每種算法都是對幾個關鍵點的權衡，在無法兼得的條件下有的算法選擇帶寬利用率，有的算法選擇通信延時等等。

在明確這個共識問題之後，我們對待各個擁塞控制算法的態度要平和一些，不要偏激地認爲誰就是最好，幾十年前的網絡狀況和現在是截然不同的，我們永遠都是站在巨人的肩膀之上的，這也是科學和文明進步的推動力。

傳統擁塞控制算法並不是一蹴而就的，複雜的網絡環境和用戶的高要求推動着擁塞控制算法的優化和迭代，我們看下基於丟包策略的傳統擁塞控制算法的幾個迭代版本，如圖所示：

與此同時還有一類算法是基於 RTT 延時策略來進行控制的，但是這類算法在發包速率上可能不夠激進，競爭性能不如其他算法，因此在共享網絡帶寬時有失公平性，但是算法速率曲線卻是很平滑，我們暫且把這類算法當做君子吧！

其中比較有名的 Vegas 算法是大約在 1995 年由亞利桑那大學的研究人員拉里 · 彼得森和勞倫斯 · 布拉科夫提出，這個新的 TCP 擁塞算法以內華達州最大的城市拉斯維加斯命名，後成爲 TCP Vegas 算法。

關於基於 RTT 的 TCP Vegas 算法的詳細介紹可以查閱文檔：

http://www.cs.cmu.edu/~srini/15-744/F02/readings/BP95.pdf

文檔對 Vegas 算法和 New Reno 做了一些對比，我們從直觀圖形上可以看到 Vegas 算法更加平滑，相反 New Reno 則表現除了較大的波動呈鋸齒狀，如圖所示：

實際上還有更細粒度的分類，由於不是今天的重點，就不再深入展開了，當前使用的擁塞控制算法還是基於丟包 Loss-Based 作爲主流。

3.1 擁塞窗口 cwnd

從流量控制可以知道接收方在 header 中給出了 rwnd 接收窗口大小，發送方不能自顧自地按照接收方的 rwnd 限制來發送數據，因爲網絡鏈路是複用的，需要考慮當前鏈路情況來確定數據量，這也是我們要提的另外一個變量 cwnd，筆者找了一個關於 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 的定義：

這個解釋指出了 cwnd 是在發送方維護的，cwnd 和 rwnd 並不衝突，發送方需要結合 rwnd 和 cwnd 兩個變量來發送數據，如圖所示：

cwnd 的大小和 MSS 最大數據段有直接關係，MSS 是 TCP 報文段中的數據字段的最大長度，即 MSS=TCP 報文段長度 - TCP 首部長度。

3.2 擁塞控制基本策略

擁塞控制是一個動態的過程，它既要提高帶寬利用率發送儘量多的數據又要避免網絡擁堵丟包 RTT 增大等問題，基於這種高要求並不是單一策略可以搞定的，因此 TCP 的擁塞控制策略實際上是分階段分策略的綜合過程：

**注：**有的版本的 TCP 算法不一定沒有快速恢復階段

如圖爲典型的包含 4 個策略的擁塞控制：

如圖爲發生超時重傳 RTO 時的過程：

3.3 TCP 擁塞控制算法常見版本

實際上 TCP 算法有很多版本，每個版本存在一些差異，在這裏簡單看一下維基百科的介紹：

• 算法命名規則

 

TCP + 算法名的命名方式最早出現在 Kevin Fall 和 Sally Floyd1996 年發佈的論文中。

• TCP Tahoe 和 TCP Reno

 

這兩個算法代號取自太浩湖 Lake Tahoe 和裏諾市，兩者算法大致一致，對於丟包事件判斷都是以重傳超時 retransmission timeout 和重複確認爲條件，但是對於重複確認的處理兩者有所不同，對於超時重傳 RTO 情況兩個算法都是將擁塞窗口降爲 1 個 MSS，然後進入慢啓動階段。

TCP Tahoe 算法：如果收到三次重複確認即第四次收到相同確認號的分段確認，並且分段對應包無負載分段和無改變接收窗口的話，Tahoe 算法則進入快速重傳，將慢啓動閾值改爲當前擁塞窗口的一半，將擁塞窗口降爲 1 個 MSS，並重新進入慢啓動階段。

TCP Reno 算法：如果收到三次重複確認，Reno 算法則進入快速重傳只將擁塞窗口減半來跳過慢啓動階段，將慢啓動閾值設爲當前新的擁塞窗口值，進入一個稱爲快速恢復的新設計階段。

• TCP New Reno

 

TCP New Reno 是對 TCP Reno 中快速恢復階段的重傳進行改善的一種改進算法，New Reno 在低錯誤率時運行效率和選擇確認 SACK 相當，在高錯誤率仍優於 Reno。

• TCP BIC 和 TCP CUBIC

 

TCP BIC 旨在優化高速高延遲網絡的擁塞控制，其擁塞窗口算法使用二分搜索算法嘗試找到能長時間保持擁塞窗口最大值，Linux 內核在 2.6.8 至 2.6.18 使用該算法作爲默認 TCP 擁塞算法。

CUBIC 則是比 BIC 更溫和和系統化的分支版本，其使用三次函數代替二分算法作爲其擁塞窗口算法，並且使用函數拐點作爲擁塞窗口的設置值，Linux 內核在 2.6.19 後使用該算法作爲默認 TCP 擁塞算法。

• TCP PRR

 

TCP PRR 是旨在恢復期間提高發送數據的準確性，該算法確保恢復後的擁塞窗口大小盡可能接近慢啓動閾值。在 Google 進行的測試中，能將平均延遲降低 3~10% 恢復超時減少 5%，PRR 算法後作爲 Linux 內核 3.2 版本默認擁塞算法。

• TCP BBR

 

TCP BBR 是由 Google 設計於 2016 年發佈的擁塞算法，該算法認爲隨着網絡接口控制器逐漸進入千兆速度時，分組丟失不應該被認爲是識別擁塞的主要決定因素，所以基於模型的擁塞控制算法能有更高的吞吐量和更低的延遲，可以用 BBR 來替代其他流行的擁塞算法。

Google 在 YouTube 上應用該算法，將全球平均的 YouTube 網絡吞吐量提高了 4%，BBR 之後移植入 Linux 內核 4.9 版本。

3.4 擁塞控制過程詳解

我們以典型慢啓動、擁塞避免、快速重傳、快速恢復四個過程進行闡述。

• 慢啓動

慢啓動就是對於剛啓動的網絡連接，發送速度不是一步到位而是試探性增長，具體來說：連接最初建立時發送方初始化擁塞窗口 cwnd 爲 m，之後發送方在一個 RTT 內每收到一個 ACK 數據包時 cwnd 線性自增 1，發送方每經過一個 RTT 時間，cwnd=cwnd*2 指數增長，經過一段時間增長直到 cwnd 達到慢啓動閾值 ssthresh。

之後 cwnd 不再呈指數增長從而進入擁塞避免階段 (注 cwnd 增長的單位是 MSS)，當然如果在慢啓動階段還未到達閾值 ssthresh 而出現丟包時進入快速重傳等階段，需要注意的是如果網絡狀況良好 RTT 時間很短，那麼慢啓動階段將很快到達一個比較高的發送速率，所以將慢啓動理解爲試探啓動更形象。

• 擁塞避免

當慢啓動階段 cwnd 的值到達 ssthresh 時就不再瘋狂增長，進入更加理性的線性階段直至發送丟包，本次的閾值 ssthresh 是上一次發生丟包時 cwnd 的 1/2，因此這是一個承上啓下的過程。

本次發送丟包時仍然會調整 ssthresh 的值，具體擁塞避免增長過程：發送方每收到一個 ACK 數據包時將 cwnd=cwnd+1/cwnd，每經過一個 RTT 將 cwnd 自增 1。

• 超時重傳和快速重傳

TCP 作爲一個可靠的協議面臨的很大的問題就是丟包，丟包就要重傳因此發送方需要根據接收方回覆的 ACK 來確認是否丟包了，並且發送方在發送數據之後啓動定時器，如圖所示：

RTO 是隨着複雜網絡環境而動態變化的，在擁塞控制中發生超時重傳將會極大拉低 cwnd，如果網絡狀況並沒有那麼多糟糕，偶爾出現網絡抖動造成丟包或者阻塞也非常常見，因此觸發的慢啓動將降低通信性能，故出現了快速重傳機制。

所謂快速重傳時相比超時重傳而言的，重發等待時間會降低並且後續儘量避免慢啓動，來保證性能損失在最小的程度，如圖所示：

快速重傳和超時重傳的區別在於 cwnd 在發生擁塞時的取值，超時重傳會將 cwnd 修改爲最初的值，也就是慢啓動的值，快速重傳將 cwnd 減半，二者都將 ssthresh 設置爲 cwnd 的一半。

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

快速重傳是基於對網絡狀況沒有那麼糟糕的假設，因此在實際網絡確實還算好的時候，快速重傳還是很有用的，在很差的網絡環境很多算法都很難保證效率的。

• 快速恢復

在快速重傳之後就會進入快速恢復階段，此時的 cwnd 爲上次發生擁塞時的 cwnd 的 1/2，之後 cwnd 再線性增加重複之前的過程。

4. 弱網環境的 AIMD 特性

我們知道在網絡鏈路中連接的數量是動態變化且數量巨大的，每一條連接都面臨着一個黑盒子式的網絡環境，這並不像我們平時出行時看看地圖就知道哪裏堵了，爲了維護一個好的網絡環境，每一條連接都需要遵守一些約定。

如果連接端都無所顧忌地發生數據包，那麼網絡鏈路很快就到了瓶頸了，數據通信完全無法保障，所以要到達一個穩定高效的網絡環境還是需要費很大心思的，這其中有兩個重要的概念：公平性和收斂性。

說來慚愧筆者在網絡上找了很多資料去理解 TCP 擁塞控制的公平性和收斂性，但是仍然沒有獲得一個很好的權威解釋，所以只能結合一些資料和自身的理解去闡述所謂的公平性和收斂性。

筆者認爲公平性是相對於網絡鏈路中的所有連接而言的，這些共享鏈路的連接啓動和結束的時間不同，在實際的交互過程中每條連接佔有帶寬的機會是均等的，並且由於帶寬限制連接雙方通信的數據量是動態調整並且近似收斂於某個值，也就是呈現一個鋸齒狀或者更加平滑的波動曲線，對於基於丟包的擁塞控制算法而言 AIMD 線性增乘性減策略起了關鍵控制作用。

接下來我們來重點看下 AIMD 特性，先來貼一張經典的圖，直觀看 AIMD 的過程：

看看維基百科對於 AIMD 的定義：

The additive-increase/multiplicative-decrease(AIMD) algorithm is a feedback control algorithm best known for its use in TCP congestion control.

AIMD combines linear growth of the congestion window with an exponential reduction when congestion is detected.

Multiple flows using AIMD congestion control will eventually converge to use equal amounts of a shared link.

The related schemes of multiplicative-increase/multiplicative-decrease (MIMD) and additive-increase/additive-decrease (AIAD) do not reach stability.

簡單翻譯一下：線性增加乘性減少算法是一個反饋控制算法，因其在 TCP 擁塞控制中的使用而廣爲人知，AIMD 將線性增加擁塞窗口和擁塞時乘性減少窗口相結合，基於 AIMD 的多個連接理想狀態下會達到最終收斂，共享相同數量的網絡帶寬，與其相關的乘性增乘性減 MIMD 策略和增性加增性減少 AIAD 都無法保證穩定性。

AIMD 相比 MIMD 和 AIAD 在連接進入擁塞避免階段使用試探線性加策略而不是乘性加策略更加安全，在探測丟包時則大幅度乘性減少到 1/2 這樣對於緩解擁塞會有比較好的效果更加快速，相反如果探測到丟包時採用線性減少 AD 可能擁塞持續的時間會更長，總體來說 AIMD 算是一個比較簡單實用的工程版本的反饋控制，也具備可工程收斂性，因而被廣泛實用。

時間拉回 20 多年前，在互聯網早期幾乎所有的設備都是通過有線網絡進行連接通信的，這也是擁塞控制在設計之後一直都起到不錯作用的重要因素，有線連接的網絡穩定性比較好，因此把丟包作爲網絡擁堵的一個特徵也很正常。

再拉回到現在，從 2010 年之後移動互聯網蓬勃發展，移動終端的持有量已經可以稱爲海量，無線網絡的引入讓網絡環境變得更加複雜，因此不穩定丟包變得更加頻繁，但是這時的丟包就不一定是網絡擁堵造成的了，因爲整個數據包經過多重路由、交換機、基站等基礎通信設備每個環節都可能發生異常。

在弱網環境下，尤其是移動互聯網中之前的基於 AIMD 的擁塞控制策略可能會由於丟包的出現而大幅降低網絡吞吐量，從而對網絡帶寬的利用率也大大下降，這時我們採用更加激進的控制策略，或許可以獲得更好的效果和用戶體驗。

惡意丟包的情況下，基於 AIMD 的擁塞控制確實就相當於被限速了，因爲 AIMD 確實有些保守謹慎了，這個其實也很好理解的哈。

我們都知道在移動網絡環境下是由終端以無線形式和附近的基站交互數據，之後數據傳輸至核心網，最後落到具體的服務器所在的有線網絡，其中最後一公里的區域屬於高延時場景，有線網絡屬於低延時高帶寬場景。

在國外有相關實驗證明弱網環境下 RTT 的變化對於使用傳統擁塞控制算法下網絡吞吐量的影響，數據和曲線如圖所示：

實驗含義：RTT 的增大影響了比如 CUBIC 這類擁塞控制算法的慢啓動等階段，我們知道慢啓動階段每經過 1 個 RTT 週期擁塞窗口 cwnd 將加倍，但是更大的 RTT 就意味着發送方以很低的速率發送數據，更多的時間是空閒的，發包的加速度極大將低了，所以整個吞吐量就下降很明顯。

看下實驗者的原文表述：

The delay before acknowledgment packets are received (= latency) will have an impact on how fast the TCP congestion window increases (hence the throughput). 

When latency is high, it means that the sender spends more time idle (not sending any new packets), which reduces how fast throughput grows.

5.BBR 算法基本原理

BBR 算法是個主動的閉環反饋系統，通俗來說就是根據帶寬和 RTT 延時來不斷動態探索尋找合適的發送速率和發送量。

看下維基百科對 BBR 算法的說明和資料：

相關文獻：https://queue.acm.org/detail.cfm?id=3022184

TCP BBR(Bottleneck Bandwidth and Round-trip propagation time) 是由 Google 設計，並於 2016 年發佈的擁塞算法，以往大部分擁塞算法是基於丟包來作爲降低傳輸速率的信號，而 BBR 基於模型主動探測。

該算法使用網絡最近出站數據分組當時的最大帶寬和往返時間來創建網絡的顯式模型。數據包傳輸的每個累積或選擇性確認用於生成記錄在數據包傳輸過程和確認返回期間的時間內所傳送數據量的採樣率。

該算法認爲隨着網絡接口控制器逐漸進入千兆速度時，分組丟失不應該被認爲是識別擁塞的主要決定因素，所以基於模型的擁塞控制算法能有更高的吞吐量和更低的延遲，可以用 BBR 來替代其他流行的擁塞算法例如 CUBIC。Google 在 YouTube 上應用該算法，將全球平均的 YouTube 網絡吞吐量提高了 4%，在一些國家超過了 14%。BBR 之後移植入 Linux 內核 4.9 版本，並且對於 QUIC 可用。

5.1 基於丟包反饋策略可能在的問題

基於丟包反饋屬於被動式機制，根源在於這些擁塞控制算法依據是否出現丟包事件來判斷網絡擁塞做減窗調整，這樣就可能會出現一些問題：

• 丟包即擁塞
  現實中網絡環境很複雜會存在錯誤丟包，很多算法無法很好區分擁塞丟包和錯誤丟包，因此在存在一定錯誤丟包的前提下在某些網絡場景中並不能充分利用帶寬。

• 緩衝區膨脹問題 BufferBloat
  網絡連接中路由器、交換機、核心網設備等等爲了平滑網絡波動而存在緩衝區，這些緩存區就像輸液管的膨脹部分讓數據更加平穩，但是 Loss-Based 策略在最初就像網絡中發生數據類似於灌水，此時是將 Buffer 全部算在內的，一旦 buffer 滿了，就可能出現 RTT 增加丟包等問題，就相當於有的容量本不該算在其中，但是策略是基於包含 Buffer 進行預測的，特別地在深緩衝區網絡就會出現一些問題。

• 網絡負載高但無丟包事件
  假設網絡中的負載已經很高了，只要沒有丟包事件出現，算法就不會主動減窗降低發送速率，這種情況下雖然充分利用了網絡帶寬，同時由於一直沒有丟包事件出現發送方仍然在加窗，表現出了較強的網絡帶寬侵略性，加重了網絡負載壓力。

• 高負載丟包
  高負載無丟包情況下算法一直加窗，這樣可以預測丟包事件可能很快就出現了，一旦丟包出現窗口將呈現乘性減少，由高位發送速率迅速降低會造成整個網絡的瞬時抖動性，總體呈現較大的鋸齒狀波動。

• 低負載高延時丟包
  在某些弱網環境下 RTT 會增加甚至出現非擁塞引起丟包，此時基於丟包反饋的擁塞算法的窗口會比較小，對帶寬的利用率很低，吞吐量下降很明顯，但是實際上網絡負載並不高，所以在弱網環境下效果並不是非常理想。

5.2 TCP BBR 算法基本原理

前面我們提到了一些 Loss-Based 算法存在的問題，TCP BBR 算法是一種主動式機制，簡單來說 BBR 算法不再基於丟包判斷並且也不再使用 AIMD 線性增乘性減策略來維護擁塞窗口，而是分別採樣估計極大帶寬和極小延時，並用二者乘積作爲發送窗口，並且 BBR 引入了 Pacing Rate 限制數據發送速率，配合 cwnd 使用來降低衝擊。

5.2.1 一些術語

• BDP

  BDP 是 Bandwidth-Delay Product 的縮寫，可以翻譯爲帶寬延時積，我們知道帶寬的單位是 bps(bit per second)，延時的單位是 s，這樣 BDP 的量綱單位就是 bit，從而我們知道 BDP 就是衡量一段時間內鏈路的數據量的指標。這個可以形象理解爲水管灌水問題，帶寬就是水管的水流速度立方米 / s，延時就是灌水時間單位 s，二者乘積我們就可以知道當前水管內存儲的水量了，這是 BBR 算法的一個關鍵指標，來看一張陶輝大神文章中的圖以及一些網絡場景中的 BDP 計算：

• 長肥網絡
  我們把具有長 RTT 往返時間和高帶寬的網絡成爲長肥網絡或者長肥管道，它的帶寬延時積 BDP 很大大，這種網絡理論上吞吐量很大也是研究的重點。

• TCP Pacing 機制
  可以簡單地理解 TCP Pacing 機制就是將擁塞控制中數據包的做平滑發送處理，避免數據的突發降低網絡抖動。

5.2.2 帶寬和延時的測量

BBR 算法的一些思想在之前的基於延時的擁塞控制算法中也有出現，其中必有有名的是 TCP WestWood 算法。

TCP Westwood 改良自 New Reno，不同於以往其他擁塞控制算法使用丟失來測量，其通過對確認包測量來確定一個合適的發送速度，並以此調整擁塞窗口和慢啓動閾值。其改良了慢啓動階段算法爲敏捷探測和設計了一種持續探測擁塞窗口的方法來控制進入敏捷探測，使鏈接儘可能地使用更多的帶寬。

TCP WestWood 算法也是基於帶寬和延時乘積進行設計的，但是帶寬和延時兩個指標無法同時測量，因爲這兩個值是有些矛盾的極值，要測量最大帶寬就要發送最大的數據量但是此時的 RTT 可能會很大，如果要測量最小的 RTT 那麼久意味着數據量非常少最大帶寬就無法獲得。

TCP BBR 算法採用交替採樣測量兩個指標，取一段時間內的帶寬極大值和延時極小值作爲估計值，具體的實現本文就不展開了。

5.2.3 發送速率和 RTT 曲線

前面提到了 BBR 算法核心是尋找 BDP 最優工作點，在相關論文中給出了一張組合的曲線圖，我們一起來看下：

1. 曲線圖示說明：
這張圖是由兩個圖組合而成，目前是展示 [數據發送速率 vs 網絡數據] 和 [RTTvs 網絡數據] 的關係，橫軸是網絡數據數量。

兩個縱軸從上到下分別爲 RTT 和發送速率，並且整個過程分爲了 3 個階段：應用限制階段、帶寬限制階段、緩衝區限制階段。

2. 曲線過程說明：

• app limit 應用限制階段
  在這個階段是應用程序開始發送數據，目前網絡通暢 RTT 基本保持固定且很小，發送速率與 RTT 成反比，因此發送速率也是線性增加的，可以簡單認爲這個階段有效帶寬並沒有達到上限，RTT 是幾乎固定的沒有明顯增長。

• band limit 帶寬限制階段
  隨着發送速率提高，網絡中的數據包越來越多開始佔用鏈路 Buffer，此時 RTT 開始增加發送速率不再上升，有效帶寬開始出現瓶頸，但是此時鏈路中的緩存區並沒有佔滿，因此數據還在增加，RTT 也開始增加。

• buffer limit 緩衝區限制階段
  隨着鏈路中的 Buffer 被佔滿，開始出現丟包，這也是探測到的最大帶寬，這個節點 BDP+BufferSize 也是基於丟包的控制策略的作用點。

3. 一些看法

網上有一些資料都提及到了這張圖，其中的一些解釋也並不算非常清晰，結合這些資料和自己的認識，筆者認爲在網絡鏈路的緩存區沒有被使用時 RTT 爲最小延時 MinRTT，在網絡鏈路緩衝區被佔滿時出現最大帶寬 MaxBW(鏈路帶寬 + 鏈路緩存)，但是此時的 MaxBW 和 MinRTT 並不是最優的而是水位比較高的水平，有數據表明按照 2ln2 的增益計算此時爲 3BDP，整個過程中 MinRTT 和 MaxBW 是分開探測的，因爲這二者是不能同時被測量的。

5.2.4 BBR 算法的主要過程

BBR 算法和 CUBIC 算法類似，也同樣有幾個過程：StartUp、Drain、Probe_BW、Probe_RTT，來看下這幾個狀態的遷移情況：

• StartUp 慢啓動階段
  BBR 的慢啓動階段類似於 CUBIC 的慢啓動，同樣是進行探測式加速區別在於 BBR 的慢啓動使用 2ln2 的增益加速，過程中即使發生丟包也不會引起速率的降低，而是依據返回的確認數據包來判斷帶寬增長，直到帶寬不再增長時就停止慢啓動而進入下一個階段，需要注意的是在尋找最大帶寬的過程中產生了多餘的 2BDP 的數據量，關於這塊可以看下英文原文的解釋：

To handle Internet link bandwidths spanning 12 orders of magnitude, Startup implements a binary search for BtlBw by using a gain of 2/ln2 to double the sending rate while delivery rate is increasing. This discovers BtlBw in log2BDP RTTs but creates up to 2BDP excess queue in the process.

• Drain 排空階段
  排空階段是爲了把慢啓動結束時多餘的 2BDP 的數據量清空，此階段發送速率開始下降，也就是單位時間發送的數據包數量在下降，直到未確認的數據包數量 < BDP 時認爲已經排空，也可以認爲是 RTT 不再下降爲止，排空階段結束。

• ProbeBW 帶寬探測階段
  經過慢啓動和排空之後，目前發送方進入穩定狀態進行數據的發送，由於網絡帶寬的變化要比 RTT 更爲頻繁，因此 ProbeBW 階段也是 BBR 的主要階段，在探測期中增加發包速率如果數據包 ACK 並沒有受影響那麼就繼續增加，探測到帶寬降低時也進行發包速率下降。

• ProbeRTT 延時探測階段
  前面三個過程在運行時都可能進入 ProbeRTT 階段，當某個設定時間內都沒有更新最小延時狀態下開始降低數據包發送量，試圖探測到更小的 MinRTT，探測完成之後再根據最新數據來確定進入慢啓動還是 ProbeBW 階段。

我們來看一下這四個過程的示意圖：

曲線說明：這兩個座標給出了 10Mbps 和 40msRTT 的網絡環境下 CUBIC 和 BBR 的一個對比過程，在上面的圖中藍色表示接收者，紅色表示 CUBIC，綠色表示 BBR，在下面的圖中給出了對應上圖過程中的 RTT 波動情況，紅色代表 CUBIC，綠色代表 BBR。

5.3 TCP-BBR 算法效果

有一些文章認爲 BBR 有鮮明的特點，把擁塞控制算法分爲 BBR 之前和 BBR 之後，可見 BBR 還是有一定影響，但是 BBR 算法也不是銀彈，不過可以先看看 BBR 算法在谷歌推動下的一些應用效果，其中包括吞吐量、RTT、丟包率影響：

從圖中我們可以看到在 YouTube 應用 BBR 算法之後，就吞吐量普遍有 4% 左右的提升，特別地在日本的提升達到 14%，RTT 的下降更爲明顯平均降低 33%，其中 IN(印度地區) 達到 50% 以上，在丟包率測試中 BBR 並不想 CUBIC 那麼敏感，在丟包率達到 5% 是吞吐量纔開始明顯下降。

6. 參考文獻

• https://cloud.tencent.com/developer/article/1369617

• https://cloud.google.com/blog/products/gcp/tcp-bbr-congestion-control-comes-to-gcp-your-internet-just-got-faster

• https://cloud.tencent.com/developer/article/1383232

• https://queue.acm.org/detail.cfm?id=3022184

• https://zhuanlan.zhihu.com/p/63888741

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/pmUdUvHgEhZzAhz2EP5Evg