小議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應用到實時音視頻領域出力。
想要閱讀更多技術乾貨、行業洞察，歡迎關注網易雲信博客。
瞭解網易雲信，來自網易核心架構的通信與視頻雲服務。