小議BBR算法

?? BBR全稱Bottleneck Bandwidth and RTT，它是谷歌在2016年推出的全新的網絡擁塞控制算法。要說明BBR算法，就不能不提TCP擁塞算法。

?? 傳統的TCP擁塞控制算法，是基于丟包反饋的協議。基于丟包反饋的協議是一種被動式的擁塞控制機制，其依據網絡中的丟包事件來做網絡擁塞判斷。即便網絡中的負載很高時，只要沒有產生擁塞丟包，協議就不會主動降低自己的發送速度。

?? TCP在發送端維護一個擁塞窗口cwnd，通過cwnd來控制發送量。采用AIMD，就是加性遞增和乘性遞減的方式控制cwnd，在擁塞避免階段加性增窗，發生丟包則乘性減窗。

這個擁塞控制算法的假定是丟包都是擁塞造成的。

?? TCP擁塞控制協議希望最大程度的利用網絡剩余帶寬，提高吞吐量。然而，由于基于丟包反饋協議在網絡近飽和狀態下所表現出來的侵略性，一方面大大提高了網絡的帶寬利用率；但另一方面，對于基于丟包反饋的擁塞控制協議來說，大大提高網絡利用率同時意味著下一次擁塞丟包事件為期不遠了，所以這些協議在提高網絡帶寬利用率的同時也間接加大了網絡的丟包率，造成整個網絡的抖動性加劇。

TCP擁塞控制算法的假定是丟包都是擁塞造成的，而事實上，丟包并不總是擁塞導致，丟包可能原因是多方面，比如：路由器策略導致的丟包，WIFI信號干擾導致的錯誤包，信號的信噪比（SNR）的影響等等。這些丟包并不是網絡擁塞造成的，但是卻會造成TCP 控制算法的大幅波動，即使在網絡帶寬很好的情況下，仍然會出現發送速率上不去的情況。比如長肥管道，帶寬很高，RTT很大。管道中隨機丟包的可能性很大，這就會造成TCP的發送速度起不來。

Google 的BBR出現很好的解決了這個問題。BBR是一種基于帶寬和延遲反饋的擁塞控制算法。它是一個典型的封閉反饋系統，發送多少報文和用多快的速度發送這些報文都是每次反饋中不斷調節。

BBR算法的核心就是找到兩個參數，最大帶寬和最小延時。最大帶寬和最小延時的乘積就是BDP(Bandwidth Delay Product), BDP就是網絡鏈路中可以存放數據的最大容量。知道了BDP就可以解決應該發送多少數據的問題，而網絡最大帶寬可以解決用多大速度發送的問題。如果網絡比作一條高速公路，把數據比作汽車，最大帶寬就是每分鐘允許通行的汽車數量，最小RTT就是沒有擁堵情況下，汽車跑一個來回需要的時間，而BDP就是在這條路上排滿汽車的數量。

?

BBR如何探測最大帶寬和最小延時

BBR是如何探測最大帶寬和最小延時呢？首先有一點就是最大帶寬和最小延時是無法同時得到的。

如圖所示，橫軸是網絡鏈路中的數據量，縱軸分別是RTT和帶寬。可以發現在RTT不變的時候，帶寬一直在上升，沒有達到最大，因為這個時候網絡沒有擁塞，而帶寬停止上漲的時候RTT持續變大，一直到發生丟包。因為這個時候，網絡開始擁塞，報文累積在路由器的buffer中，這樣延時持續變大，而帶寬不會變大。圖中BDP的豎線所標識的就是理想情況下最大帶寬和最小延時。很明顯，要找到BDP, 很難在同一時刻找到最小的RTT和最大帶寬。這樣最小RTT和最大帶寬必須分別探測。

探測最大帶寬的方法就是盡量多發數據，把網絡中的buffer占滿，帶寬在一段時間內不會增加，這樣可以得到此時的最大帶寬。

探測最小RTT的方法就是盡量把buffer騰空，讓數據交付延時盡量低。

由此，BBR就引入了基于不同探測階段的狀態機。

狀態機分為4個階段，Startup，Drain，ProbeBW， ProbeRTT。

Startup類似于普通擁塞控制里的慢啟動，增益系數是 2ln2，每一個來回都以這個系數增大發包速率，估測到帶寬滿了就進入 Drain狀態，連續三個來回，測得的最大瓶頸帶寬沒有比上一輪增大 25%以上，就算帶寬滿了。

進入 Drain狀態，增益系數小于 1，也就降速了。一個包來回，把 Startup狀態中產生的拍隊排空，怎樣才算隊列空了？發出去還沒有 ACK 的數據包量 inflight，與 BDP 進行比較，inflight < BDP 說明空了，道路不那么滿了，如果 inflght > BDP 說明還不能到下一個狀態，繼續 Drain。

ProbeBW是穩定狀態，這時已經測出來一個最大瓶頸帶寬，而且盡量不會產生排隊現象。之后的每個來回，在 ProbeBW狀態循環（除非要進入下面提到的 ProbeRTT狀態），輪詢下面這些增益系數，[5/4, 3/4, 1, 1, 1, 1, 1, 1]，如此，最大瓶頸帶寬就會在其停止增長的地方上下徘徊。大部分時間都應該處于 ProbeBW狀態。

前面三種狀態，都可能進入 ProbeRTT狀態。超過十秒沒有估測到更小的 RTT 值，這時進入 ProbeRTT狀態，把發包量降低，空出道路來比較準確得測一個 RTT 值，至少 200ms 或一個包的來回之后退出這個狀態。檢查帶寬是否是滿的，進入不同的狀態：如果不滿，進入 Startup狀態，如果滿，進入 ProbeBW狀態。

BBR算法不會因為一次或者偶然的丟包就大幅降低吞吐量，這樣就比TCP就有較強的抗丟包能力。

如圖所示，cubic在丟包率上升的時候，吞吐量下降很快。而BBR在5%以上的丟包才會出現明顯的吞吐量下降。

BBR與基于丟包反饋的cubic和基于延時反饋的vegas算法的本質區別在于，BBR無視隨機丟包，無視時延短暫波動，采用了實時采集并保留時間窗口的策略，保持對可用帶寬的準確探知。事實上，丟包并不一定會造成帶寬減少，延遲增加也不一定會造成帶寬減少，cubic無法判斷是否擁塞造成的丟包，vegas對延時增加過于敏感，會導致競爭性不足。

BBR可以區分出噪聲丟包和擁塞丟包，這樣意味著，BBR比傳統TCP擁塞控制算法具有更好的抗丟包能力。

?

BBR在實時音視頻領域的應用

實時音視頻系統要求低延時，流暢性好，而實際網絡狀態卻是復雜多變的，丟包，延時和網絡帶寬都在時刻變化，這就對網絡擁塞控制算法提出了很高的要求。它需要一種帶寬估計準確，抗丟包和抖動能力好的擁塞控制算法。

目前Google的webrtc提供了GCC控制算法，它是一種發送側基于延遲和丟包的控制算法，這個算法的原理在很多地方都有詳細描述，這里不再贅述。GCC用于實音視頻的主要問題還在于在帶寬發生變化時，它的帶寬跟蹤時間比較長，這樣就會造成帶寬突變的時候無法及時準確探測帶寬，可能造成音視頻卡頓。

既然BBR有良好的抗丟包能力，自然也被想到應用到實時音視頻領域。但是，BBR并不是為處理實時音視頻設計的，所以需要對一些問題做一些優化。

第一，BBR在丟包率達到25%以上，吞吐量會斷崖式下降。

這是由BBR算法的pacing_gain數組[5/4, 3/4, 1, 1, 1, 1, 1, 1]的固定參數決定的。

在pacing_gain數組中，其增益周期的倍數為5/4，增益也就是25%，可以簡單理解為，在增益周期，BBR可以多發送25%的數據。

在增益期，丟包率是否抵消了增益比25%？也就是說，x是否大于25。

假設丟包率固定為25%，那么，在增益周期，25%的增益完全被25%的丟包所抵消，相當于沒有收益，接下來到了排空周期，由于丟包率不變，又會減少了25%的發送數據，同時丟包率依然是25%...再接下來的6個RTT，持續保持25%的丟包率，而發送率卻僅僅基于反饋，即每次遞減25%，我們可以看到，在pacing_gain標識的所有8周期，數據的發送量是只減不增的，并且會一直持續下去，這樣就會斷崖式下跌。

?怎樣才能對抗丟包，這就需要在每個周期考慮丟包率，把丟包率補償進去。比如丟包率達到25%的時候，增益系數就變成50%，這樣就可以避免由于丟包帶來的反饋減損，然而，你又如何判斷這些丟包是噪聲丟包還是擁塞丟包呢？答案在于RTT，只要時間窗口內的RTT不增加，那么丟包就不是擁塞導致的。

第二，BBR的最小RTT有個10s超時時間，在10s超時后，進入ProbeRTT 狀態，并持續最小200ms，此狀態下，為了排空擁塞，inflight只允許有4個包，這會導致音視頻數據在這段時間內堆積在發送隊列中，使得時延增加。

可行的解決辦法是，不再保留ProbeRTT狀態，采用多輪下降的方式排空擁塞，然后采樣最小RTT，也就是在infight > bdp的時候，設置pacing gain為0.75，用0.75倍帶寬作為發送速率，持續多輪，直到inflight < bdp, 此外，最小RTT的超時時間改成2.5s，也就是說不采用非常激進的探測方式，避免了發送速率的大幅波動，可以改善探測新的帶寬過程中發送隊列中產生的延時。

第三，開始提到pacing gain數組上探周期為1.25倍帶寬，隨后是0.75倍帶寬周期，這兩個RTT周期之間會出現發送速率的劇烈下降，這可能會使音視頻數據滯留在buffer中發不出去，引入不必要的延時。

解決辦法可以考慮減小上探周期和排空周期的幅度，比如使用[1.1 0.9 1 1 1 1 1 1]這種pacing gain參數，這樣做的優點就是可以保證媒體流的平穩發送，發送速率不會大幅波動，缺點是，網絡帶寬改善的時候，上探時間會變長。

第四，BBR探測新帶寬收斂慢的問題

原始的BBR算法的收斂性受到pacing gain周期影響，帶寬突降的時候，BBR需要多個輪次才會降到實際帶寬。這是由于BBR每輪只能降速一次，而pacing gain的6個RTT的保持周期大大加長了這個時間。解決的辦法就是隨機化pacing gain的6個保持周期，如果是0.75倍周期，就一次降速到位，這樣可以極大的減少BBR的收斂時間。

最后，BBR算法看似簡單，但是應用到實時音視頻卻沒有那么簡單，需要大量的實驗優化，谷歌也在webrtc中引入BBR，目前仍在測試中。本文提到的改進方法是網易云信在這方面的一些嘗試，希望能夠拋磚引玉，有更多有興趣的人能夠為BBR應用到實時音視頻領域出力。

?

想要技術干貨、行業洞察，歡迎關注網易云信博客。

了解網易云信，來自網易核心架構的通信與視頻云服務。

?

?

?

總結

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

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