文 / 袁榮喜
整理 / LiveVideoStack
大家好，我是來自學霸君的袁榮喜，本次分享内容的核心是BBR在實時視訊傳輸中的實踐。BBR其實是基于TCP的一種擁塞算法，在實時音視訊中的運用也是一種全新的嘗試，接下來我将會為大家逐一介紹這種嘗試所帶來的優缺點。
1. 傳輸與擁塞
講到音視訊的傳輸或者實時傳輸，就必須要了解傳輸和擁塞的關系。
1.1 傳輸三角關系
實時傳輸領域存在着一種三角關系，其中成本一般認為是硬體、軟體和通訊帶寬所帶來的成本，延遲是指獲得整個流媒體的時延，比如實時視訊中的雙端延遲和觀看長視訊時的首幀延遲，品質可以了解為視訊清晰度和資料完備性，這種三角關系均是以保證其中一角而犧牲其餘兩角的方案來建立實時傳輸方案。随着網際網路的發展，裝置的成本越來越低，手持裝置越來越友善，但由此也帶來很多在實時視訊傳輸過程中的問題。
1.2 實時視訊的困擾
實時視訊傳輸中常見的問題主要有卡頓、延遲、抖動、視訊模糊和斷線重連五種。造成這些問題的原因是多種多樣的，但其中最不能忽視的一個原因就是網絡擁塞。
1.3 網絡擁塞
網絡擁塞是指發送的資料超過了網絡能承載的傳輸能力，但人的需求無限，即使新技術在不斷地發展，網絡擁塞的情況在未來還是會不斷出現。
網絡發生擁塞的原因大緻有以下幾點，WiFi/4G信号衰減、核心傳輸鍊路衰減、網絡出口競争、重發風暴和裝置性能衰減等問題都會帶來網絡擁塞的問題，其中WiFi/4G信号衰減意味着信号被污染，導緻傳輸信道的吞吐率下降，最終造成網絡擁塞。
針對網絡擁塞的問題，業界也一直在提出不同的擁塞控制算法，擁塞算法的核心包括判斷擁塞狀态和決策合适的發送碼率，這兩個其實是map和reduce模型，把網絡上傳回的資料進行map，通過網絡狀态ruduce出一個合理的發送碼率。
GCC是一種基于延遲預估和丢包的擁塞控制算法，算法分為在接收端進行卡爾曼算法預估後傳回發送端進行碼率調整兩部分。Transport CC是基于發送端線性預測的擁塞控制算法，與GCC一樣主體都是基于時延的擁塞控制判斷。這兩種算法存在不同程度上的缺陷，在實作算法的過程中過于學術，比如GCC中有一個丢包率2%/10%的預值，但其實擁塞發生并不一定會産生丢包，而且丢包也不一定意味着發生擁塞，這種情況對于GCC是失效的。GCC基于時延估算的主體在現階段來看與帶寬的記憶丢包沒有争搶率，斯坦福大學提出的Salsify算法是基于視訊幀之間的時延去估算整個編碼器的編碼速度，但它一定要在編碼器的基礎上執行，無法滿足将視訊傳到sever上進行分發的要求，如果隻做分段擁塞控制就需要在sever上進行重解碼和重編碼，無法滿足目前實時視訊領域的應用。
實時傳輸理想的擁塞控制算法要滿足三個特點，第一要相對激進，算法要能搶過流氓軟體和一些基于丢包的算法。第二要對百毫秒級或者是毫秒級的碼率進行實時調整，間隔盡量減小，盡量快的适應傳輸條件，這樣卡頓時間不會太長，也能夠帶來更好的使用者體驗。第三是要能應對延遲型和丢包型的擁塞，同時能夠進行分段計算。
2. BBR
BBR是基于接收端回報和發送端調節碼率的擁塞控制算法。
2.1 模型
遠端packet feedback回報資訊輸送到BBR之後，經過一系列運算得到擁塞控制的視窗大小（TCP發送端口）和發送碼率。
2.2 網絡FIFO概念
首先整個網絡分為正在傳輸和發生堆積兩部分，BBR在構模組化型中隻計算網絡正在傳輸的部分，計算過程中引入了BDP（擁塞控制視窗）的概念。目前路由器的吞吐和緩沖能力大大加強，包在發送到路由器時雖然會發生擁塞，但在足夠的記憶體和磁盤存儲空間的條件下不會發生丢包現象，記憶延遲對網絡更加敏感，但記憶丢包如果不發生丢包碼率就不會下降，在這種情況下記憶延遲搶不過丢包。
BDP的計算方式是網絡周期性最小延遲*網路周期性最大帶寬。
BDP中網絡周期性最小延遲和網路周期性最大帶寬是通過BBR的四個狀态機來計算的，第一個狀态是STARTUP，BBR剛進入STARTUP時會進行慢啟動，慢啟動不斷地增加帶寬到帶寬不再增長或者發生丢包現象就會切入DRAIN排空狀态，進入排空狀态是由于BPD已滿，飛行資料發生堆積。DRAIN狀态會在發送資料小于BDP時進入重新評估帶寬的過程，如果持續一定周期還沒有探測到最小RTT的值，就需要進行最小RTT的探測工作，BBR将視窗設定為4個miss大小或者保留3/4的大小去估算最小延遲，估算結束後重新回到STARTUP狀态。
BDP/RTT就是我們認為可以發送的碼率。
發送出去會有pace sender通過平滑發送發到接收端，接收端會把一個一個的包傳回給發送端，發送端通過事件可以很快得到最小延遲和最大帶寬的樣本，結合一定的算法得到相對應的BDP，由BDP可以得到pacing rate，最後不斷調整帶寬形成循環，達成擁塞控制的目的。
3. 實時視訊傳輸與BBR
3.1 實時視訊傳輸與BBR相結合
網絡協定進入網絡接收器以後，通過RTCP的方式獲得feedback資訊直接輸入BBR，再通過一系列狀态機計算出帶寬和視窗大小，碼率配置設定器會根據各種情況對碼率進行重新配置設定，調節視訊編碼器使碼率達到縮放自如的回報。實時視訊有非持續性的特點，關鍵幀之間流量不均勻，幀間存在時延，突然發送實時視訊會導緻中間為空的狀态，為了防止這樣的情況發生設計了pacer用來平滑發送。
3.2 Feedback
RTT在實際應用中設計的是記憶幀的回報，這樣減少了回報數量的同時也提升了效率，通過上圖中的公式可以得到RTT的回報序列。
即時速率是通過發送的資料和接收/發送端的互相統計，由于網絡發生抖動會使send bitrate變得非常大，即時速率不能超過發送端本身的速度，是以要在兩值中取最小值以減少誤差。
3.3 Pacer
pacer的發送機制基于BDP發送資料和pacing rate發送資料，如果發送資料已經超過了BDP的吞吐量，此時pacer不會再向外發送資料加重網絡擁塞，pacing是間隔5毫秒的間隔發送，pacing rate是基于5毫秒發送的資料量，基于這兩個條件就可以建構出定時發送的pacer。
在探測最高帶寬時，使用pacer的padding來滿足BBR的probe_bw狀态最大帶寬探測要求。
3.4 AIMD碼率決策
BBR是及時發送的碼率而不是編碼器需要采用的碼率，這樣會導緻網絡擁塞問題更加複雜，是以設計了AIMD碼率決策來控制video碼率的機制。如果BDPinfight_size時，并不會采用即時碼率而是用和式加來對碼率進行控制，通過添加一個固定倍數位率來平滑地控制整個運作的回報機制，避免網絡惡化。
3.5 擁塞控制與QoS
QoS和擁塞控制是兩個概念，QoS是在擁塞控制的範疇之下進行的，碼率和擁塞控制的視窗大小會制約QoS的行為。FEC/NACK之間是制約關系，是以一定要基于決策碼率來做。
3.6 BBR與GCC比較
上圖中可以明顯看到BBR在網絡限速的情況下表現要比GCC良好一些，不會有大幅度的網絡抖動和衰減。
3.7 多路競争測試
上圖是關于BBR多路競争的測試，測試過程是在300kBps的帶寬下分時間段引入三路BBR資料流，最終觀察發送碼率是否是平均配置設定的。
4. 總結
BBR的比較豪放激進，具有不容易被其他應用搶占帶寬、碼率調節實時性高，能很好應對網絡變化、可以對應各種類型的網絡丢包和技術成熟等優勢。
但BBR的不足也表現在，評估最小RTT時會減小視窗，這樣會使發送碼率下降，極端情況下會使實時視訊瞬間品質變差。BBR在誕生之初并不是用做小帶寬傳輸，是以在小碼率視訊傳輸過程中，BBR的效果并不明顯。最重要的問題還有padding計算流量不經濟實用，需要在使用過程中重點考量。BBR所有的帶寬統計和實效性都是基于RTT，如果RTT過大會導緻帶寬的條件不太平滑。
源碼實作：
https://github.com/yuanrongxi/razor————————————————
版權聲明：本文為CSDN部落客「LiveVideoStack_」的原創文章，遵循CC 4.0 BY-SA版權協定，轉載請附上原文出處連結及本聲明。
原文連結：
https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/96226078「視訊雲技術」你最值得關注的音視訊技術公衆号，每周推送來自阿裡雲一線的實踐技術文章，在這裡與音視訊領域一流工程師交流切磋。