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

小議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應用到實時音視頻領域出力。

想要閱讀更多技術乾貨、行業洞察，歡迎關注網易雲信博客。

瞭解網易雲信，來自網易核心架構的通訊與視頻雲服務。