本文為個(gè)人原創(chuàng)凌简，歡迎轉(zhuǎn)載恃逻，但請(qǐng)務(wù)必在明顯位置注明出處！
http://www.reibang.com/p/9061b6d0a901
1. 概述
對(duì)于共享網(wǎng)絡(luò)資源的各類應(yīng)用來說凸郑，擁塞控制技術(shù)的使用有利于提高帶寬利用率矛市，同時(shí)也使得終端用戶在使用網(wǎng)絡(luò)時(shí)能夠獲得更好的體驗(yàn)。在協(xié)議層面上擁塞控制是TCP的一個(gè)總要的組成部分而昨；但是對(duì)于非面向鏈接的傳輸層協(xié)議，如UDP，其在協(xié)議層面上并沒有對(duì)擁塞控制進(jìn)行強(qiáng)制性的要求午阵，這樣做保證了最優(yōu)的傳輸性能底桂，且在擁塞控制的設(shè)計(jì)上也保留了更大的靈活性。
WebRTC為我們提供了強(qiáng)大的音視頻媒體引擎籽懦，前端開發(fā)者可以通過調(diào)用幾個(gè)簡單的js接口就能實(shí)現(xiàn)基于Web瀏覽器的實(shí)時(shí)音視頻通信暮顺。而在媒體數(shù)據(jù)傳輸上，WebRTC采用了實(shí)時(shí)性較強(qiáng)UDP協(xié)議捶码，并使用了RTP/RTCP技術(shù)惫恼。本文的主要內(nèi)容就是介紹WebRTC中基于RTP/RTCP實(shí)現(xiàn)的擁塞控制技術(shù)。
2. 擁塞控制算法
WebRTC采用了兩種擁塞控制算法：（1）基于延遲（delay-based）的擁塞控制算法令宿；（2）基于丟包（loss-based）的擁塞控制算法腕窥。算法（1）由數(shù)據(jù)的接收方實(shí)現(xiàn)，接收方需要記錄每個(gè)數(shù)據(jù)包到達(dá)的時(shí)間和大小革娄，并計(jì)算每個(gè)數(shù)據(jù)分組之間（inter-group）的延遲的變化冕碟，由此判斷當(dāng)前網(wǎng)絡(luò)的擁塞情況，并最終輸出碼率估計(jì)值由RTCP feedback（TMMBR或 REMB）反饋給發(fā)送方厕妖；算法（2）則由數(shù)據(jù)的發(fā)送方來實(shí)現(xiàn)挑庶，發(fā)送方通過從接收方周期性發(fā)來的RTCP RR（Receiver Report）中獲取丟包信息以及計(jì)算RTT软能，并結(jié)合TMMBR或REMB中攜帶的碼率信息算得最終的碼率值查排，然后由媒體引擎根據(jù)碼率來配置編碼器抄沮，從而實(shí)現(xiàn)碼率的自適應(yīng)調(diào)整。從上面的描述可以看出砂代，這兩個(gè)算法在系統(tǒng)中并不是孤立存在的率挣。
2.1 基于延遲（delay-based）的擁塞控制算法
基于延遲的擁塞控制算法可以分成以下4個(gè)部分：（1）到達(dá)時(shí)間模型（arrive-time model）;（2）預(yù)過濾（Pre-filtering）椒功；（3）到達(dá)時(shí)間濾波器（arrive-time filter）；（4）過載檢測(cè)器（over-use detector）讼呢。
2.1.1 到達(dá)時(shí)間模型（arrive-time model）
設(shè)相鄰兩個(gè)數(shù)據(jù)分組到達(dá)接收方的時(shí)間間隔為t(i) - t(i-1)谦炬，而兩者被發(fā)送的時(shí)間間隔則為T(i) - T(i-1)，那么就有延遲變量d(i)=t(i)-t(i-1) - (T(i)-T(i-1))础爬。如果d(i) > 0吼鳞，就說明數(shù)據(jù)在網(wǎng)絡(luò)傳輸時(shí)存在延遲的現(xiàn)象赔桌。
在WebRTC中延遲變量d(i) = w(i)被視為隨機(jī)過程W中一個(gè)采樣點(diǎn)，并且是鏈路承載能力疾党、網(wǎng)絡(luò)當(dāng)前傳輸狀況以及當(dāng)前發(fā)送速率等因素綜合作用的結(jié)果雪位。該隨機(jī)過程W符合正態(tài)分布。當(dāng)網(wǎng)絡(luò)發(fā)生過載（over-use）時(shí)，我們期望w(i)會(huì)上升卧波；當(dāng)網(wǎng)絡(luò)空閑（Under-use）時(shí)庇茫，則期望w(i)會(huì)下降旦签。
測(cè)量方程進(jìn)一步改寫為 d(i) = m(i) + v(i)，其中m(i)符合均值為0的正態(tài)分布（標(biāo)準(zhǔn)正態(tài)分布）咪惠，v(i)表示為網(wǎng)絡(luò)抖動(dòng)等因素帶來的對(duì)數(shù)據(jù)延遲的影響淋淀。
2.1.2 預(yù)過濾（Pre-filtering）
預(yù)過濾的目的是處理由于通道中斷造成的延遲瞬間變大的情況覆醇。在通道發(fā)生中斷時(shí)，數(shù)據(jù)包會(huì)持續(xù)進(jìn)入網(wǎng)絡(luò)隊(duì)列中袍辞，而當(dāng)通道恢復(fù)時(shí)常摧，所有的數(shù)據(jù)包會(huì)在一個(gè)burst時(shí)間（5 ms）里面全部發(fā)送落午，而這些數(shù)據(jù)包可能原先包分布于多個(gè)數(shù)據(jù)分組。而預(yù)過濾所要做的就是將這些在同一個(gè)burst時(shí)間里發(fā)送的數(shù)據(jù)包合為一個(gè)數(shù)據(jù)分組溃斋。
這里涉及到了WebRTC中關(guān)于數(shù)據(jù)傳輸?shù)囊粋€(gè)設(shè)計(jì)--PacedSender梗劫。Encoded數(shù)據(jù)完成RTP封裝之后先是被保存在本地應(yīng)用的隊(duì)列中，而不是直接發(fā)送到網(wǎng)絡(luò)蛉威。此時(shí)可以將PacedSender視為一個(gè)數(shù)據(jù)發(fā)送的節(jié)拍器走哺，它每隔一個(gè)burst時(shí)間啟動(dòng)一次，啟動(dòng)之后會(huì)將隊(duì)列中的RTP包全數(shù)發(fā)出齐帚。
數(shù)據(jù)包會(huì)在下面兩種情況下被劃分到一個(gè)數(shù)據(jù)分組：
- 在同一個(gè)burst時(shí)間區(qū)間內(nèi)被發(fā)送的數(shù)據(jù)包序列；
- 一個(gè)數(shù)據(jù)包與相鄰數(shù)據(jù)包的到達(dá)時(shí)間間隔小于一個(gè)burst時(shí)間湘今，同時(shí)d(i) < 0剪菱，那么這個(gè)數(shù)據(jù)包將會(huì)被劃到當(dāng)前的分組中。
2.1.3 到達(dá)時(shí)間濾波器（arrive-time filter）
在此系統(tǒng)希望通過預(yù)測(cè)m(i)來檢測(cè)當(dāng)前的網(wǎng)絡(luò)是否過載旗们；而這里所采用的預(yù)測(cè)方法是卡爾曼濾波（Kalman filter）构灸。
狀態(tài)方程：m(i+1) = m(i) + u(i)喜颁， 其中u(i)表示為狀態(tài)噪聲，符合0均值正態(tài)分布隔披。
測(cè)量方程：d(i) = m(i) + v(i)寂拆， 其中v(i)表示為測(cè)量噪聲，符合0均值正態(tài)分布鬓长。
卡爾曼濾波器根據(jù)“5組公式”來迭代更新m(i) 的估計(jì)值m_hat(i)渺蒿，該估計(jì)值m_hat(i)則是下文過載檢測(cè)器的檢測(cè)依據(jù)。關(guān)于卡爾曼濾波器如何實(shí)現(xiàn)預(yù)測(cè)的詳細(xì)介紹在這里就不做展開了怠蹂，可參考文獻(xiàn)[3]少态。
2.1.4 過載檢測(cè)器（over-use detector）
通過Kalman 濾波器能夠獲得延遲變量m(i)的估計(jì)值彼妻，而過載檢測(cè)器的工作原理其實(shí)就是通過m(i)與閾值del_var_th進(jìn)行比較來對(duì)當(dāng)前的網(wǎng)絡(luò)擁塞狀況進(jìn)行檢測(cè)豆茫。如果m(i) > del_var_th且m(i) > m(i-1)屋摇，同時(shí)該狀態(tài)至少持續(xù)了overuse_time_th毫秒，則判斷為網(wǎng)絡(luò)過載（Over-use）火脉；如果m(i) < -del_var_th柒啤，則判斷為網(wǎng)絡(luò)空閑（Under-use）担巩；剩余的情況都被判斷為Normal狀態(tài)。
由此可見犯戏，閾值del_var_th的設(shè)計(jì)對(duì)于整個(gè)算法的性能來說至關(guān)重要祖很。如果del_var_th的值設(shè)得過大漾脂，那么整個(gè)算法的動(dòng)態(tài)就會(huì)顯得過于平滑，此時(shí)只有在數(shù)據(jù)分組嚴(yán)重delay時(shí)檢測(cè)器才會(huì)觸發(fā)over-use的信號(hào)笨鸡；相反的坦冠，如果del_var_th的值設(shè)得過小辙浑，那么檢測(cè)器就會(huì)對(duì)delay非常敏感，從而導(dǎo)致頻繁觸發(fā)over-use信號(hào)判呕。因此侠草，WebRTC提出了針對(duì)閾值del_var_th的動(dòng)態(tài)調(diào)整算法：
del_vat_th(i) = del_var_th(i-1)+ (t(i) - t(i-1)) * K(i) * (|m(i)| - del_var_th(i-1))
其中，當(dāng)|m(i)| < del_var_th(i-1)時(shí)K(i)=K_d晤碘；否則，K(i)=K_u宠蚂。
在WebRTC中本小節(jié)所涉及的各參數(shù)的參考值如下：
del_var_th(0) = 12.5 ms, overuse_time_th = 10 ms, K_u=0.01, K_d=0.00018
2.1.5 速率控制（rate control）
速率控制子系統(tǒng)根據(jù)當(dāng)前網(wǎng)絡(luò)的擁塞情況（由過載檢測(cè)器提供）童社，計(jì)算帶寬估計(jì)值并請(qǐng)求發(fā)送方對(duì)速率進(jìn)行調(diào)整叠洗。該子系統(tǒng)通過有限狀態(tài)機(jī)對(duì)速率進(jìn)行自適應(yīng)調(diào)整。其狀態(tài)遷移如下圖所示：
- 狀態(tài) Increase： 表明當(dāng)前沒有檢測(cè)到網(wǎng)絡(luò)擁塞十艾，在此狀態(tài)下傳輸速率需要逐步增加腾节；它先是通過乘性增加來調(diào)整速率（乘性因子為1.08）案腺，當(dāng)速率接近臨界值時(shí)再通過加性增加逐步收斂，而這里所謂的臨界值是指上一次在狀態(tài)Decrease 時(shí)統(tǒng)計(jì)的下行碼率劈榨；
- 狀態(tài) Decrease： 表明當(dāng)前檢測(cè)到了網(wǎng)絡(luò)擁塞同辣，在此狀態(tài)下傳輸速率需要逐步下降；在這里响巢，WebRTC所采用的方法是乘性下降棒妨，其乘性因子為0.85；
- 狀態(tài) Hold： 表明保持當(dāng)前的速率不做改變伏穆。
速率控制子系統(tǒng)最終會(huì)輸出一個(gè)帶寬估計(jì)值A(chǔ)_hat颅眶，并通過RTCP Feedback（TMMBR/REMB）請(qǐng)求發(fā)送方進(jìn)行速率調(diào)整涛酗。
2.2 基于丟包（Loss-based）的擁塞控制算法
基于丟包的擁塞控制是通過對(duì)丟包率偷厦，RTT和帶寬估計(jì)值A(chǔ)_hat這三個(gè)參數(shù)進(jìn)行決策而實(shí)現(xiàn)的只泼。其中帶寬估計(jì)值A(chǔ)_hat正是由上節(jié)中的速率控制子系統(tǒng)所提供卵洗。
基于丟包的擁塞控制在每次收到對(duì)方發(fā)送RTCP之后都會(huì)運(yùn)行：
- 當(dāng)丟包率保持在[2%, 10%]時(shí)，當(dāng)前數(shù)據(jù)發(fā)送方的帶寬估計(jì)值A(chǔ)s_hat保持不變十绑；
- 當(dāng)丟包率大于10%時(shí)酷勺，帶寬估計(jì)值將會(huì)降低：As_hat(i) = As(i-1)*(1-p)，其中p為丟包率甚亭；
- 當(dāng)丟包率小于2%時(shí)亏狰，帶寬估計(jì)值將會(huì)上升：As_hat(i) = As(i-1)*1.05偶摔。
As_hat更新之后將與A_hat進(jìn)行比較，然后取兩者中的較小值作為最終的帶帶寬估計(jì)值信不。
其實(shí)在原生的代碼中亡呵，系統(tǒng)還會(huì)將丟包率和RTT作為參數(shù)硫戈，通過TFRC [RFC 5348]的吞吐率計(jì)算公式對(duì)當(dāng)前的帶寬進(jìn)行估計(jì)丁逝，而最終的估計(jì)值則是取三者中的最小值。
3. 后語
通過上文的介紹嫩码，我們知道WebRTC中的擁塞控制算法還是非常完備的罪既。其分別針對(duì)數(shù)據(jù)包的延遲和丟包設(shè)計(jì)了delay-based和loss-based擁塞控制算法铡恕，在兩者的共同作用之下探熔，WebRTC能夠滿足大部分場景下的實(shí)時(shí)視頻通話業(yè)務(wù)烘挫。但是，如果有要對(duì)WebRTC中的媒體引擎進(jìn)行移植的朋友其垄，首先要分析一下WebRTC的擁塞控制算法是否滿足你的業(yè)務(wù)需求：如果是開發(fā)獨(dú)立應(yīng)用卤橄，由于業(yè)務(wù)閉環(huán)虽风，直接使用現(xiàn)有的算法應(yīng)該問題不大；但是无牵，如果是用于開發(fā)提供類似VoLTE/VoWIFI這樣的運(yùn)營商增值服務(wù)的應(yīng)用厂抖，需要依據(jù)運(yùn)營商的技術(shù)手冊(cè)和3GGP協(xié)議等來對(duì)擁塞控制算法進(jìn)行適配忱辅。
Reference
[1] A Google Congestion Control Algorithm for Real-Time Communication draft-ietf-rmcat-gcc-02
[2] RFC 5348
[3] http://blog.csdn.net/xiahouzuoxin/article/details/39582483
[4] 3GPP TS 26.114
