實時音視頻系統要求低延時，流暢性好，而實際網絡狀態卻是復雜多變的，丟包，延時和網絡帶寬都在時刻變化，這就對網絡擁塞控制算法提出了很高的要求。本文來自網易云信資深工程師肖磊在LiveVideoStackCon2019北京站上的精彩分享，文章中詳細介紹了BBR擁塞控制算法產生背景及其演進。

文 / 肖磊 網易云信

整理 / LiveVideoStack

?

大家好，我是網易云信音視頻工程師肖磊，目前致力于實時音視頻領域的QoS研究，通過優化擁塞控制算法，為用戶提供高帶寬利用率，低延時，抗抖動能力強的實時音視頻服務。

本次我分享的主題是BBR及其在實時音視頻領域的應用，BBR全稱是Bottleneck Bandwidth and RTT，它是谷歌在2016年推出的全新網絡擁塞控制算法，在此之后大家對于擁塞控制的關注度逐漸提高，越來越多的新算法被推出。本次分享的內容主要包括BBR算法的基本原理以及BBR算法如何應用在網易云信的實時音視頻產品中。

1. BBR產生的背景

?

擁塞控制始于20世紀80年代，當時TCP是滑動窗口的算法，擁塞窗口固定，需要通過不斷地響應報文推動滑動窗口前進。但在1986年TCP導致了擁塞崩潰，比如現在多端采用TCP發起報文，實際帶寬達不到所能提供的最大帶寬時網絡出現擁堵，此時會有越來越多的TCP發起重試，進而加劇擁堵情況。

2000年之后伴隨著互聯網大爆發，各類應用特別是音視頻應用數量大幅增加，TCP擁塞控制算法無法滿足當前互聯網應用對網絡傳輸高實時性、高帶寬利用率、高吞吐量的需求，在這種背景下BBR應運而生。

1.1 TCP算法存在的問題

?

在互聯網發展的過程當中，TCP算法也做出了一定改變，先后演進了Reno、NewReno、Cubic和Vegas，這些改進算法大體可以分為基于丟包和基于延時的擁塞控制算法。基于丟包的擁塞控制算法以Reno、NewReno為代表，它的主要問題有Buffer bloat和長肥管道兩種，基于丟包的協議擁塞控制機制是被動式的，其依據網絡中的丟包事件來做網絡擁塞判斷。即使網絡中的負載很高，只要沒有產生擁塞丟包，協議就不會主動降低自己的發送速度。最初路由器轉發出口的Buffer 是比較小的，TCP在利用時容易造成全局同步，降低帶寬利用率，隨后路由器廠家由于硬件成本下降不斷地增加Buffer，基于丟包反饋的協議在不丟包的情況下持續占用路由器buffer，雖然提高了網絡帶寬的利用率，但同時也意味著發生擁塞丟包后，網絡抖動性加大。另外對于帶寬和RTT都很高的長肥管道問題來說，管道中隨機丟包的可能性很大，TCP的默認buffer設置比較小加上隨機丟包造成的cwnd經常下折，導致帶寬利用率依舊很低。

基于延時的擁塞控制算法以vegas為代表，但當vegas出現時，基于丟包的擁塞控制算法在市面已經占據主流，vegas搶不到帶寬出現“餓死”現象，因此也沒辦法與之抗爭。

在BBR出現之前，TCP的擁塞控制一直逃脫不了這兩個方向，另外優化TCP的擁塞控制難免涉及到內核的修改，這也是限制TCP繼續優化的一大問題。

1.2 BBR算法的特點及核心

?

BBR（Bottleneck Bandwidth and Round-trip propagation time）是一種基于帶寬和延遲反饋的擁塞控制算法。目前已經演化到第二版，是一個典型的封閉反饋系統，發送多少報文和用多快的速度發送這些報文都是在每次反饋中不斷調節。在BBR提出之前，擁塞控制都是基于事件的算法，需要通過丟包或延時事件驅動；BBR提出之后，擁塞控制是基于反饋的自主自動控制算法，對于速率的控制是由算法決定，而不由網絡事件決定，算法核心是“不排隊”。

2. BBR算法基本原理

2.1 BBR結構圖

?

BBR算法的核心是找到最大帶寬（Max BW）和最小延時（Min RTT）這兩個參數，最大帶寬和最小延時的乘積可以得到BDP(Bandwidth Delay Product), 而BDP就是網絡鏈路中可以存放數據的最大容量。BDP驅動Probing State Machine得到Rate quantum和cwnd，分別設置到發送引擎中就可以解決發送速度和數據量的問題。

2.2 即時帶寬的計算

?

一般情況下的即時帶寬計算，很多人認為將發送報文和收到報文的時間點記錄下來，發包數量再除以時間就可以得到帶寬，但這樣的計算方式是錯誤的。由于delay feedback表示一組報文的響應，一組報文之后會有一個延遲的相應來通知哪些報文沒有收到，以及收到的時間差是多少。delay feedback容易受到網絡影響，因此報文不會均勻發送，易發生聚合和丟包現象，在計算時要考慮發送的時間差和ack的時間差，公式為：bandwidth = delivered/max（send time,ack time），這樣才能抵消掉延遲聚合和丟失的情況。

2.3 BDP

BDP（帶寬延遲積）是BBR算法中的核心，其中最大帶寬和最小延遲不能同時得到。如圖所示，橫軸是網絡鏈路中的數據量，縱軸分別是RTT和帶寬，在RTT不變的時候，網絡沒有發生擁塞，帶寬一直在上升，沒有達到最大，而當帶寬停止上漲的時候，網絡開始擁塞，RTT持續變大，直到發生丟包。圖中BDP所標識的點就是理想情況下最大帶寬和最小延時。很明顯只有在沒有發生擁塞時才能得到RTT的數值，因此很難在同一時刻找到最小的RTT和最大帶寬。

2.4 BBR狀態機

?

既然最大帶寬和最小延遲不能同時得到，必然存在探測最大帶寬和最小RTT的過程。上圖表示的是BBR的狀態機，狀態機分為Startup，Drain，ProbeBW，ProbeRTT4個階段。Startup階段類似于普通擁塞控制里的慢啟動，以2/ln2的增益系數持續更新發包速率，帶寬連續三次沒有增長就可以判定達到最大帶寬而進入Drain狀態。

進入Drain狀態時隊列可能存在擁堵，因此需要把 Startup狀態中產生的隊列排空，排空的速率是ln2/2，如果inflight < BDP 說明此時網絡由BBR造成的擁塞已經全部排空，如果 inflght > BDP 說明此時網絡還有擁塞，不能進入下一個狀態。

擁塞排空之后會進入探測帶寬階段，探測最大帶寬的方法是在10個RTT中觀測到的最大帶寬，以此數據作為最大帶寬。如果10s沒有得到最小RTT，超時之后需要繼續探測最小RTT。探測最小RTT需要盡量避免網絡擁堵，降低擁塞窗口，發送比較少的報文。整個BBR的擁塞控制在啟動之后，最終是在Drain和ProbeBW階段之間切換。

3. BBR算法的優缺點

?

BBR相對TCP的優點包括抗丟包能力強、延遲低、搶占能力強和平穩發送。在BBR算法之前的TCP Cubic，擁塞控制算法并沒有平穩發送的說法，而只是判斷發送與否的問題，BBR算法出現之后，會平穩的發送數據，不會突發流量沖擊。

3.1 抗丟包能力強

?

關于BBR算法的抗丟包能力可以用上圖來說明，BBR算法不會因為一次或者偶然的丟包就大幅降低吞吐量，因此具有較強的抗丟包能力。

3.2 低延遲/搶占能力強

?

對于BBR在低延遲方面的優勢來說，由于目前關于擁塞控制的算法很多，BBR在運轉時設備中可能會有多種擁塞控制算法同時作用的情況，BBR算法只能保證自己不排隊。但在實際現行網絡下，是否排隊并不由BBR一個算法決定，運行過程中BBR算法不會加重網絡擁塞。

在帶寬探測階段，BBR算法每一輪都會嘗試上探更大的帶寬，由此可以很快搶占其他擁塞算法讓出來的帶寬，這也是BBR算法搶占能力強的原因。

3.3 平穩發送

?

之前提到在TCP算法中并沒有平穩發送的說法，BBR算法后來引入了平穩發送的概念，不只解決了發送多少的問題，還解決了發送速率的問題，具體實現是使用cwnd控制發送數量，發送速度使用漏桶算法控制。BBR算法中的cwnd與TCP算法不同，TCP算法中的cwnd是對網絡狀態的模擬，分為發送窗口和接收窗口，而BBR算法只有發送窗口，且cwnd = 2*BDP。

3.4 收斂速度慢/高于一定丟包率吞吐量下跌

?

BBR算法在具備一些優勢的同時也存在一定的缺點，比如原始的BBR算法收斂性受到pacing gain周期影響，帶寬突降的時候，BBR需要多個輪次才會降到實際帶寬。這其中的原因是BBR每輪只能降速一次，而pacing gain的6個RTT的保持周期大大加長了這個時間。由于pacing gain上探周期的1.25無法抵消掉25%以上的丟包，這會造成帶寬反饋持續下降，BBR吞吐量就會斷崖式下跌。

3.5 深隊列競爭不過Cubic

?

BBR算法設計之初cwnd = 2*BDP，在此之前BBR算法要比Cubic強很多，但在實際的網絡環境中，如果出現buffer很大的情況，BBR是比Cubic競爭性差的，因此在應用BBR算法時必須了解當前的網絡狀況。

3.6 算法公平性/抗抖動能力

?

在算法公平性方面，BBR在與Reno競爭時可以占用90%以上的帶寬，但在與多個BBR流競爭時，RTT高的流占用帶寬更高，其中也暴露的漏洞是如果想占用更高帶寬，可以人為調高RTT的值，這些并不是BBR算法的設計初衷。在抗抖動能力方面，RTT的抖動使BBR無法得到準確的BDP，探測帶寬很有可能低于可用帶寬。

4. BBR應用在實時音視頻領域

4.1 BBR在實時音視頻領域的優勢

?

如果將BBR算法應用在實時音視頻領域，需要滿足帶寬（特別是低帶寬場景）探測準確，適合實時音視頻傳輸的低延時需求，能夠滿足音視頻傳輸碼率平穩的需求以及快速響應帶寬變化這四個要求。

4.2 BBR在實時音視頻領域存在的問題

?

滿足以上四個實時音視頻需求的同時，BBR算法在應用時也存在著收斂速度慢、抗丟包能力無法達到預期的問題，另外實時音視頻領域需要提供穩定的視頻流，但BBR的ProbeRTT階段只發4個包，發送速率下降太多會引發延遲加大和卡頓問題，最后BBR探測帶寬需要Paddin有可能造成帶寬浪費。

4.3 收斂速度/抗丟包能力解決辦法

?

針對BBR應用在實時音視頻領域遇到的問題，目前已經有不少解決方案。對于收斂速度慢的問題來說，BBR V2提出在Probe Down一次排空到位（inflight < BDP），另外還可以隨機化6個1x平穩發送周期，縮短排空所需要的時間。對于抗丟包能力不足的問題來說，目前BBR算法的抗丟包能力是足夠的，但在一些極端網絡條件下可以把丟包率補償到pacing rate，有效提升抗丟包能力。

4.4 ProbeRTT階段問題解決辦法

ProbeRTT并不適用實時音視頻領域，因此可以選擇直接去除，或者像BBR V2把probe RTT縮短到2.5s一次，使用0.5xBDP發送。

4.5 Padding/RTT不公平問題

?

為了保持帶寬競爭性和平穩發送，BBR中的padding不可或缺，想要迅速感知帶寬變化也必須有padding的存在。關于RTT不公平問題之前有提到RTT大占據的帶寬多，但在排空階段一次排空就可以緩解這個問題。

4.6 Cubic與BBR對比

?

由上圖整體可以看出BBR帶寬利用率要高于Cubic。

4.7 BBR與GCC對比

?

目前GCC控制算法在實時音視頻領域占據主流，但WebRTC的GCC算法仍然有一些局限性，比如將帶寬限制在300k，一段時間后取消限制的場景來對比，由圖像對比可以得到，BBR比GCC的帶寬估計更加準確（GCC:250k,BBR:300k），而在帶寬限制取消后，GCC需要20s以上才能恢復到最大帶寬，BBR僅需要2s就可以恢復。

如果將帶寬限制在2.5Mbps，加入200ms delay，200ms jitter，此場景中GCC和BBR的表現如圖所示，GCC帶寬探測只有300k，而BBR帶寬維持在2.5M附近波動，在如此惡劣的網絡環境中BBR的表現已經是相當優秀了。

總結來看，BBR算法有很多優點的同時也有很多缺點，目前沒有一個算法能夠適用所有的網絡狀態，針對不同的網絡狀態選擇不同的擁塞算法似乎是一個可行的辦法，但基于當前擁塞算法，融合其他算法的優點也是可以實現的，在此希望能夠涌現出更多有興趣的人為實時音視頻領域的擁塞算法出力。

擴展閱讀

除了針對復雜網絡條件BBR擁塞控制算法優化之外，從4G到5G網絡自身提升所帶來的超高帶寬、超低延遲，將會如何影響和改變即時通訊與音視頻技術發展，點擊【閱讀原文】，走進《5G萬物智聯下的互聯網通信云技術》沙龍。

總結

以上是生活随笔為你收集整理的干货 | BBR及其在实时音视频领域的应用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。