WebRTC的擁塞控制技術

**：

對於共享網路資源的各類應用來說，擁塞控制技術的使用有利於提高頻寬利用率，同時也使得終端使用者在使用網路時能夠獲得更好的體驗。在協議層面上擁塞控制是tcp的乙個總要的組成部分；但是對於非面向鏈結的傳輸層協議，如udp，其在協議層面上並沒有對擁塞控制進行強制性的要求，這樣做保證了最優的傳輸效能，且在擁塞控制的設計上也保留了更大的靈活性。

webrtc採用了兩種擁塞控制演算法：（1）基於延遲（delay-based）的擁塞控制演算法；（2）基於丟包（loss-based）的擁塞控制演算法。演算法（1）由資料的接收方實現，接收方需要記錄每個資料報到達的時間和大小，並計算每個資料分組之間（inter-group）的延遲的變化，由此判斷當前網路的擁塞情況，並最終輸出位元速率估計值由rtcp feedback（tmmbr或 remb）反饋給傳送方；演算法（2）則由資料的傳送方來實現，傳送方通過從接收方週期性發來的rtcp rr（receiver report）中獲取丟包資訊以及計算rtt，並結合tmmbr或remb中攜帶的位元速率資訊算得最終的位元速率值，然後由**引擎根據位元速率來配置編碼器，從而實現位元速率的自適應調整。從上面的描述可以看出，這兩個演算法在系統中並不是孤立存在的。

擁塞控制演算法時序圖.png

基於延遲的擁塞控制演算法可以分成以下4個部分：（1）到達時間模型（arrive-time model）;（2）預過濾（pre-filtering）；（3）到達時間濾波器（arrive-time filter）；（4）過載檢測器（over-use detector）。

基於延遲的擁塞控制演算法.png

設相鄰兩個資料分組到達接收方的時間間隔為t(i) - t(i-1)，而兩者被傳送的時間間隔則為t(i) - t(i-1)，那麼就有延遲變數d(i)=t(i)-t(i-1) - (t(i)-t(i-1))。如果d(i) > 0，就說明資料在網路傳輸時存在延遲的現象。

在webrtc中延遲變數d(i) = w(i)被視為隨機過程w中乙個取樣點，並且是鏈路承載能力、網路當前傳輸狀況以及當前傳送速率等因素綜合作用的結果。該隨機過程w符合正態分佈。當網路發生過載（over-use）時，我們期望w(i)會上公升；當網路空閒（under-use）時，則期望w(i)會下降。

測量方程進一步改寫為 d(i) = m(i) + v(i)，其中m(i)符合均值為0的正態分佈（標準正態分佈），v(i)表示為網路抖動等因素帶來的對資料延遲的影響。

預過濾的目的是處理由於通道中斷造成的延遲瞬間變大的情況。在通道發生中斷時，資料報會持續進入網路佇列中，而當通道恢復時，所有的資料報會在乙個burst時間（5 ms）裡面全部傳送，而這些資料報可能原先包分布於多個資料分組。而預過濾所要做的就是將這些在同乙個burst時間裡傳送的資料報合為乙個資料分組。

這裡涉及到了webrtc中關於資料傳輸的乙個設計--pacedsender。encoded資料完成rtp封裝之後先是被儲存在本地應用的佇列中，而不是直接傳送到網路。此時可以將pacedsender視為乙個資料傳送的節拍器，它每隔乙個burst時間啟動一次，啟動之後會將佇列中的rtp包全數發出。

在此系統希望通過**m(i)來檢測當前的網路是否過載；而這裡所採用的**方法是卡爾曼濾波（kalman filter）。

狀態方程：m(i+1) = m(i) + u(i)， 其中u(i)表示為狀態雜訊，符合0均值正態分佈。

測量方程：d(i) = m(i) + v(i)， 其中v(i)表示為測量雜訊，符合0均值正態分佈。

卡爾曼濾波器根據「5組公式」來迭代更新m(i) 的估計值m_hat(i)，該估計值m_hat(i)則是下文過載檢測器的檢測依據。關於卡爾曼濾波器如何實現**的詳細介紹在這裡就不做展開了，可參考文獻[3]。

通過kalman 濾波器能夠獲得延遲變數m(i)的估計值，而過載檢測器的工作原理其實就是通過m(i)與閾值del_var_th進行比較來對當前的網路擁塞狀況進行檢測。如果m(i) > del_var_th且m(i) > m(i-1)，同時該狀態至少持續了overuse_time_th毫秒，則判斷為網路過載（over-use）；如果m(i) < -del_var_th，則判斷為網路空閒（under-use）；剩餘的情況都被判斷為normal狀態。

由此可見，閾值del_var_th的設計對於整個演算法的效能來說至關重要。如果del_var_th的值設得過大，那麼整個演算法的動態就會顯得過於平滑，此時只有在資料分組嚴重delay時檢測器才會觸發over-use的訊號；相反的，如果del_var_th的值設得過小，那麼檢測器就會對delay非常敏感，從而導致頻繁觸發over-use訊號。因此，webrtc提出了針對閾值del_var_th的動態調整演算法：

del_vat_th(i) = del_var_th(i-1)+ (t(i) - t(i-1)) * k(i) * (|m(i)| - del_var_th(i-1))

其中，當|m(i)| < del_var_th(i-1)時k(i)=k_d；否則，k(i)=k_u。

在webrtc中本小節所涉及的各引數的參考值如下：

del_var_th(0) = 12.5 ms, overuse_time_th = 10 ms, k_u=0.01, k_d=0.00018

速率控制狀態機.png

速率控制子系統最終會輸出乙個頻寬估計值a_hat，並通過rtcp feedback（tmmbr/remb）請求傳送方進行速率調整。

基於丟包的擁塞控制是通過對丟包率，rtt和頻寬估計值a_hat這三個引數進行決策而實現的。其中頻寬估計值a_hat正是由上節中的速率控制子系統所提供。

基於丟包的擁塞控制在每次收到對方傳送rtcp之後都會執行：

as_hat更新之後將與a_hat進行比較，然後取兩者中的較小值作為最終的帶頻寬估計值。

其實在原生的**中，系統還會將丟包率和rtt作為引數，通過tfrc [rfc 5348]的吞吐率計算公式對當前的頻寬進行估計，而最終的估計值則是取三者中的最小值。

tcp擁塞控制演算法 WebRTC擁塞控制原理解析

webrtc包含三種擁塞控制演算法，gcc bbr和pcc。其中，bbr一開始是針對tcp的擁塞控制提出來的。它的輸入為ack sack，輸出為擁塞視窗 congestion window 傳送速度 pacing rate bbr是怎樣運用到udp，甚至運用到實時流 傳輸之上的？拜讀一下在webrt...

WEBRTC 傳送端擁塞控制

資料流圖 函式主要呼叫次順 擁塞演算法得到的位元速率如何作用於編碼模組和傳送模組 congestioncontroller process congestioncontroller maybetriggeronnetworkchanged bitratecontrollerimpl getnetwo...

TCP的擁塞控制

計算機網路中的頻寬 交換結點中的快取和處理機等，都是網路的資源。在某段時間，若對網路中某一資源的需求超過了該資源所能提供的可用部分，網路的效能就會變壞。這種情況就叫做擁塞。擁塞控制就是防止過多的資料注入網路中，這樣可以使網路中的路由器或鏈路不致過載。擁塞控制是乙個全域性性的過程，和流量控制不同，流量...