BBR原理導讀 https://mp.weixin.qq.com/s/j10wc2TZG9ddbio7UeYUaQ
BBR原理導讀
最近在排查網絡問題時，發現在服務器上部署了Linux 4.9 的 TCP BBR擁塞控制算法以后，訪問速度得到了成倍的提示，頓時覺得⼗分神奇，在⽹上查詢了BBR相關資料，閱讀了BBR的論⽂，下⾯基於該論⽂向⼤家簡要分析⼀下BBR的來⻰去脈。
什么是BBR
2016年底google的開發者Neal Cardwell等5個⼤⽜在acmqueue上發表了論⽂BBR: Congestion-Based Congestion Control，提出了TCP擁塞控制的BBR算法。BBR即Bottleneck Bandwidth andRound-trip propagation time，正如其名，它是⼀種基於瓶頸帶寬和往返傳播時間的擁塞控制算法。
背景
基於丟包的擁塞控制算法的缺陷
-
丟包≠擁塞
在tcp擁塞控制算法提出的20世紀80年代，直接把丟包等價於發⽣了擁塞，需要降低發送 速率。受限於硬件的發展⽔平和⽹絡普及程度，這在過去的很⻓⼀段時間都是⼗分適⽤的。然⽽30多年 過去了，⽹絡的帶寬從⼏Mbps已經發展到了⼏Gbps，⽹絡上的⽹卡、交換機和路由器的內存也從⼏ KB發展到了⼏GB。並且⽹絡的復雜程度也原超當年，各種跨洋跨⼤洲的通信鏈路以及⽆線⽹絡使得⽹ 絡丟包和⽹絡擁塞的關系越來越稀薄。在實際情況中，⾼速⼴域⽹內的傳輸錯誤丟包是不能忽略的，特 別是在⽆線⽹絡的情況下，整個鏈路的不穩定性導致的丟包更是⾮常常⻅。如果簡單的認為丟包就是擁 塞所引起，從⽽降低⼀半的速率，將會導致⽹絡吞吐變低。
-
緩沖區膨脹(bufferbloat)
⽹絡中的各種設備基本都有⾃⼰的緩存，基於丟包的擁塞控制算法⾸先會填 滿⽹絡中的緩存，當緩存填滿以后出現了丟包才開始降低發送速率。如果⽹絡瓶頸的緩存⽐較⼤時，這278就可能造成極⼤的延時。要解決上⾯的問題，就需要另外⼀種思路，不是基於丟包來估計⽹絡發⽣了擁堵。
原理
tcp擁塞控制的初衷是為了在保證通信質量的前提下盡可能⾼的利⽤通信鏈路的帶寬。⼀個tcp鏈接就如同⼀條條管道，評價⼀條tcp鏈路的傳輸性能主要依靠2個參數:RTprop (round-trip propagation time)往返傳播時間和 BtlBw (bottleneck bandwidth)瓶頸帶寬，就如同現實管道中的管道⻓度和最⼩直徑。
當⽹絡中數據包不多，還沒有填滿瓶頸鏈路的管道時，RTprop決定着鏈路的性能。隨着投遞率的增加，往 返時延不發⽣變化。在1979 Leonard Kleinrock證明了，當數據包剛好填滿管道時，即滿⾜最⼤帶寬BtlBw和最⼩時延RTprop，⽆論是單獨鏈接還是整個⽹絡來說是最優⼯作點。定義帶寬時延積BDP=BtlBw × RTprop，則在最優點⽹絡中的數據包數量=BDP。繼續增加⽹絡中的數據包，超出BDP的數據包會占⽤buffer，達到瓶頸帶寬的⽹絡的投遞率不再發射變化，RTT會增加。繼續增加數據包，buffer會被填滿從⽽發⽣丟包。故在BDP線的右側，⽹絡擁塞持續作⽤。過去基於丟包的擁塞控制算法⼯作在bandwidth-limited區域的右側邊界，將瓶頸鏈路管道填滿后繼續填充buffer，直到buffer填滿發⽣丟包，擁塞控制算法發現丟包，將發送窗⼝減半后再線性增加。過去存儲器昂貴，buffer的容量只⽐BDP稍⼤，增加的時延不明顯，隨着內存價格的下降導致buffer容量遠⼤於BDP，增加的時延就很顯著了。
針對上述的問題，BBR采⽤了完全不同的⽅案：既然丟包不能等同於擁塞，那就忽略丟包，通過觀測和量化鏈路的瓶頸帶寬和往返時延來讓擁塞控制算法處理真正的⽹絡擁塞，從⽽盡可能的讓⽹絡傳輸達到Kleinrock所提出來的最優⼯作點。
然⽽另外⼀個問題隨之⽽來了，同樣在20世紀80年代，Jeffrey M. Jaffe就證明了沒有什么算法能同時計算出這個最佳⼯作點。要測量最低延遲(min RTT)，就必須要排空緩存，⽹絡中的數據包越少越好，⽽此時 帶寬是較低的。要測量最⼤帶寬(max BW)，就要把鏈路瓶頸填滿，在buffer中有⼀定的數據包，⽽此時延 時⼜是較⾼的。
針對測不准的問題，BBR算法采⽤的⽅案是，交替測量帶寬和延遲，⽤⼀段時間內的帶寬極⼤值和延遲極⼩值作為估計值，動態更新測量值，最終控制發送速率，避免⽹絡擁塞。
實現
BBR啟動以后主要分為四個階段：
-
啟動階段
BBR采⽤類似標准TCP的slow start，指數的⽅式來探測⽹絡的帶寬，⽬的也 是盡可能快的占滿管道，經過三次發現投遞率不再增⻓，說明管道被填滿，開始占⽤buffer。
-
排空階段
指數降低發送速率，相當於是startup的逆過程，將多占的buffer慢慢排空。
-
PROBE_BW:
在之后，BBR進⼊穩定⼯作狀態。BBR會不斷的通過改變發送速率進⾏帶寬探測，先在 ⼀個RTT時間內增加發送速率探測最⼤帶寬，如果RTT沒有變化，后減⼩發送速率排空前⼀個RTT多發 出來地包，后⾯6個周期使⽤更新后的估計帶寬發包
-
PROBE_RTT：
延遲探測階段，BBR設定了min RTT的超時時間為10秒，每過10秒，會進⼊⾮常短暫延 遲探測階段，為了探測最⼩延遲，BBR在這段時間內僅發送最少量的包。
在穩定⼯作的情況下，BBR會交替的進⾏帶寬探測和延時探測，並且越98%時間都處於帶寬探測階段，帶寬探測階段時定期嘗試增加發包速率，如果收到確認的速率也增加了，就進⼀步增加發包速率。下圖展示了在第20s時⽹絡帶寬增加⼀倍時⽹絡的⾏為。向上的尖峰表明它增加發送速率來探測帶寬變化， 向下的尖峰表明它降低發送速率排空數據。如果帶寬不變，增加發送速率肯定會使RTT增加。如果帶寬增 加，則增加發包速率時RTT不變。這樣經過三個周期之后，估計的帶寬增加了1.95倍。284⽽在第40s時⽹絡帶寬減半，因為發送速率不變，inflight(在途數據包)增加，多出來的數據包占⽤了 buffer，RTT會顯著增加，帶寬的估計是滑動窗⼝時間內的極⼤值，當之前的估計值超時之后，降低⼀半 后的有效帶寬就會變成新的估計帶寬從⽽減⼩發送速率，經過4秒后，BBR逐漸收斂。
效果
我們回過頭再來看BBR要解決的2個問題
-
優化在⾼丟包率下⽹絡的吞吐率：
上圖可以看到，傳統的TCP CUBIC在隨着丟包率的增加性能急劇下降，在千分之⼀的丟包率情況下，系統吞吐量就下降到⽹絡的百分之⼗，⽽BBR則在百分之五以下的丟包率的情況下，基本沒有性能損失。
-
減少緩沖區膨脹，降低⾼緩存導致的延遲
上圖展示了在不同buffer⼤⼩的情況下，BBR和CUBIC的延時表現。紅線為傳統TCP CUBIC，CUBIC傾向於填滿buffer，這也導致延遲基本隨着buffer的增⼤線性增⻓，⽽延時過⻓可能直接導致系統建⽴連接超時。⽽BBR基本保持發送隊列為最⼩，隨着buffer的增加⽹絡延遲基本不變。所以BBR能在存在⼀定丟包率的的⽹絡環境中充分利⽤帶寬，⼗分的適合在跨區域的⾼延遲⾼速⽹絡。當 然BBR也不是萬能的，許多測試和實際應⽤也發現了BBR存在在⽹絡狀況變化較⼤的情況下測不准導致⼤ 量丟包，交替測量導致波動較⼤，收斂較慢導致的公平問題等。Google也在持續優化BBR算法，在2018年 公布的BBR 2.0研究進展中就包含了：
-
提⾼與基於丟包的擁塞算法(Reno/Cubic)的共存能⼒。降低BBR算法的搶占性，提⾼不同算法之間的公平性。
-
減⼩排隊丟包和排隊時延的情況。這⾥主要根據丟包率和標記ECN⽐例來設置inflight的兩個⻔限值，inflight_hi和inflight_lo。
-
加快min_rtt的收斂性，增加是將進⼊Probe_RTT模式的頻率由10s設置到2.5s。
-
減⼩Probe_RTT模式帶來的帶寬的波動。
參考⽂獻
[1] Neal Cardwell. "TCP BBR congestion control comes to GCP – your Internet just got faster"
[2] Neal Cardwell, et al. "BBR: Congestion-Based Congestion Control."
[3] Yuchung Cheng, Neal Cardwell. "Making Linux TCP Fast"
[4] Neal Cardwell. "BBR Congestion Control Work at Google IETF 102 Update"