webrtc包含三種擁塞控制演算法，gcc、bbr和pcc。其中，bbr一開始是針對tcp的擁塞控制提出來的。它的輸入為ack/sack，輸出為擁塞視窗(congestion_window)傳送速度(pacing_rate)。bbr是怎樣運用到udp，甚至運用到實時流**傳輸之上的？拜讀一下在webrtc中關於擁塞控制的模組吧！
擁塞控制模組位於平緩傳送這個區域。平緩傳送指的是，不會將所有能發的包一股腦都發出去，而是根據擁塞控制模組計算出來的傳送速率和擁塞視窗大小，將其平緩的傳送出去，從而避免阻塞傳輸網路，導致rtt劇烈抖動。
這裡對比tcp的reno擁塞控制演算法，reno會維護乙個cwnd，然後不停的傳送包，直至inflight填滿cwnd才停止傳送，在收到ack時，釋放in_flight，使其可以繼續傳送後續的包。
對於webrtc的擁塞控制，它是乙個定時迴圈，在正常情況下，每固定時刻（min_packet_limit_ms_預設值5ms，這個值可能會變化）迴圈一次。擁塞控制演算法會計算出當前可用頻寬。接下來，計算迴圈週期時間 ✖️當前可用頻寬，這個值便是當前週期可傳送的資料量的預算值。
整體傳送的資料量（throughput）理想情況下應該如圖所示。每間隔5ms，會傳送一些資料來填滿頻寬。5ms時間很短，整體來看，是平滑傳送的。
從**實現角度：每次迴圈，都從資料報的佇列中取出一些包，直到消耗完資料量的預算（budget）或者消耗完cwnd（導致處於擁塞狀態）。擁塞狀態的判定是未收到確認（outstanding_bytes）的資料量大於擁塞視窗（cwnd）的值。
另外，如果資料報佇列中的資料量不夠了，也就是預算太多，實際並沒有這麼多資料要傳送。這時候會傳送一些paddingdata用於填補頻寬。這個填補對於擁塞控制演算法是十分關鍵的，要不然它無法正確測得到當前可用的頻寬。
1、引子
上文明確了如何使用擁塞控制演算法的產出結果（bandwidth和cwnd）。下文將介紹bbr演算法如何準確獲得這兩個值。
bbr 擁塞控制演算法解析（來自 google 的 tcp 擁塞控制演算法）ccie.lol
原理介紹參考這個
rtp extensions for transport-wide congestion controltools.ietf.org
這個transport-wide-cc拓展，其實提供了一種udp的ack機制，為擁塞控制的實現提供了可能。另外值得注意的是，transport-wide-cc機制在rtcp中的反饋資訊，是聚合的，也就是說，每次可能反饋（ack或lost）的是多個packet。
2、最大頻寬的計算
對於每個ack的資料報，都會計算頻寬。並不是只有probe_bw模式時才計算。
當前的傳送頻寬是根據send_rate和ack_rate之中最小值而來的。send_rate和ack_rate都需要使用兩個點，計算斜率（資料量之差➗時間差）而來。具體選點可以參考原始碼，這個不太重要。
如果這個頻寬計算值比較好，則將其放入最大頻寬的取樣記錄中。這個記錄是最好的三個值（排序的前三名），他們都有乙個有效視窗時間，在視窗時間到期或者新的取樣值更為優秀，則會替代他們。
這個視窗時間是回合數（round_trip_count）的視窗。那什麼算一回合呢？需要乙個當前回合結束、下乙個回合開始的標誌。這個標誌是在回合開始時，當前傳送的最後乙個包的序號。如果在之後收到了這個標誌包（或者大於這個標誌包序號的包）的ack。則代表該回合結束，下回合開始。
若干的回合之後，前面測量的取樣值就會過期。
3、rtt的計算
同理，在收到每個ack時，都會計算這個取樣點的rtt值。當這個取樣的rtt小於當前測量的最小rtt時，可以延長最小rtt的過期時間（這個延長rtt過期時間的功能暫時沒有啟用）。否則，在一定物理時間過後，該最小rtt過期，必須進入probe_rtt模式。
4、擁塞視窗和bdp的計算
bdp指的是乙個pipe中所能承載的資料量的值。bbr中的bdp為最大頻寬✖️最小rtt。擁塞視窗大小乘以乙個增益係數，在startup階段和drain階段（這個可能是個bug，應該為1/2.885）為2.885，在probe_bw階段為2.0，在probe_rtt階段，擁塞視窗直接設定為4。
這個cwnd不是一下子直接設定乙個新值的，而是每次增加當次ack的資料量（類似於tcp的慢啟動過程）。
5、pacingrate的增益變化
在startup階段為2.885，drain階段為1/2.885。preobe_bw的階段1為1.25，階段2為0.75。其他時刻為1.0。
6、模式變化
每當收到ack，都有可能引起模式的變化。
7、recovery模式
bbr有乙個recovery模式。每當收到反饋資訊，發現存在丟包的時候，將recovery_state設定為conservation。如果下一次收到反饋資訊時，還有丟包，則更新狀態為growth。當處於growth狀態時，如果下次收到反饋資訊時，沒有丟包。則更新狀態為not_in_recovery。
這個recovery模式考慮了丟包的因素，會得出recovery_window。根據bbr的配置，可能會與cwnd相比較，取二者之中的較小值作為最後的擁塞視窗值。
對於實時流**來說，將視窗降為4個包來探測rtt，是乙個很糟糕的事情。這裡可以通過選項配置的方式改為0.75倍的bdp來探測rtt。
其次，啟用延長rtt過期時間的選項，減少進入probe_rtt模式的次數。
TCP協議 擁塞控制演算法
網路擁塞控制演算法 tcp的擁塞控制主要原理依賴於乙個擁塞視窗來控制，在之前我們還討論過tcp還有乙個對端通告的接收視窗用於流量控制。視窗值得大小就代表能夠傳送出去的但還沒有接收到ack的最大資料報文段，顯然視窗越大那麼資料傳送的速度也就越快，但是也有越可能使得網路出現擁塞，如果視窗值為1，那麼就簡...
WEBRTC 傳送端擁塞控制
資料流圖 函式主要呼叫次順 擁塞演算法得到的位元速率如何作用於編碼模組和傳送模組 congestioncontroller process congestioncontroller maybetriggeronnetworkchanged bitratecontrollerimpl getnetwo...
WebRTC的擁塞控制技術
對於共享網路資源的各類應用來說，擁塞控制技術的使用有利於提高頻寬利用率，同時也使得終端使用者在使用網路時能夠獲得更好的體驗。在協議層面上擁塞控制是tcp的乙個總要的組成部分 但是對於非面向鏈結的傳輸層協議，如udp，其在協議層面上並沒有對擁塞控制進行強制性的要求，這樣做保證了最優的傳輸效能，且在擁塞...