本文為個(gè)人原創(chuàng)，歡迎轉(zhuǎn)載，但請(qǐng)務(wù)必在明顯位置注明出處！
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ì)上也保留了更大的靈活性。
為我們提供了強(qiáng)大的音視頻媒體引擎，前端開發(fā)者可以通過調(diào)用幾個(gè)簡(jiǎn)單的js接口就能實(shí)現(xiàn)基于Web瀏覽器的實(shí)時(shí)音視頻通信。而在媒體數(shù)據(jù)傳輸上，采用了實(shí)時(shí)性較強(qiáng)UDP協(xié)議，并使用了RTP/RTCP技術(shù)。本文的主要內(nèi)容就是介紹中基于RTP/RTCP實(shí)現(xiàn)的擁塞控制技術(shù)。
2. 擁塞控制算法
采用了兩種擁塞控制算法：（1）基于延遲（delay-based）的擁塞控制算法；（2）基于丟包（loss-based）的擁塞控制算法。算法（1）由數(shù)據(jù)的接收方實(shí)現(xiàn)，接收方需要記錄每個(gè)數(shù)據(jù)包到達(dá)的時(shí)間和大小js取系統(tǒng)時(shí)間有延遲，并計(jì)算每個(gè)數(shù)據(jù)分組之間（inter-group）的延遲的變化，由此判斷當(dāng)前網(wǎng)絡(luò)的擁塞情況，并最終輸出碼率估計(jì)值由RTCP （TMMBR或 REMB）反饋給發(fā)送方；算法（2）則由數(shù)據(jù)的發(fā)送方來實(shí)現(xiàn)，發(fā)送方通過從接收方周期性發(fā)來的RTCP RR（ ）中獲取丟包信息以及計(jì)算RTT，并結(jié)合TMMBR或REMB中攜帶的碼率信息算得最終的碼率值，然后由媒體引擎根據(jù)碼率來配置編碼器，從而實(shí)現(xiàn)碼率的自適應(yīng)調(diào)整。從上面的描述可以看出，這兩個(gè)算法在系統(tǒng)中并不是孤立存在的。
擁塞控制算法時(shí)序圖.png
2.1 基于延遲（delay-based）的擁塞控制算法
基于延遲的擁塞控制算法可以分成以下4個(gè)部分：（1）到達(dá)時(shí)間模型（-time model）;（2）預(yù)過濾（Pre-）；（3）到達(dá)時(shí)間濾波器（-time ）；（4）過載檢測(cè)器（over-use ）。
基于延遲的擁塞控制算法.png
2.1.1 到達(dá)時(shí)間模型（-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)象。
在中延遲變量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-）
預(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ù)分組。
這里涉及到了中關(guān)于數(shù)據(jù)傳輸?shù)囊粋€(gè)設(shè)計(jì)--。數(shù)據(jù)完成RTP封裝之后先是被保存在本地應(yīng)用的隊(duì)列中，而不是直接發(fā)送到網(wǎng)絡(luò)。此時(shí)可以將視為一個(gè)數(shù)據(jù)發(fā)送的節(jié)拍器，它每隔一個(gè)burst時(shí)間啟動(dòng)一次，啟動(dòng)之后會(huì)將隊(duì)列中的RTP包全數(shù)發(fā)出。
數(shù)據(jù)包會(huì)在下面兩種情況下被劃分到一個(gè)數(shù)據(jù)分組：
2.1.3 到達(dá)時(shí)間濾波器（-time ）
在此系統(tǒng)希望通過預(yù)測(cè)m(i)來檢測(cè)當(dāng)前的網(wǎng)絡(luò)是否過載；而這里所采用的預(yù)測(cè)方法是卡爾曼濾波（ ）。
狀態(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 ）
通過 濾波器能夠獲得延遲變量m(i)的估計(jì)值，而過載檢測(cè)器的工作原理其實(shí)就是通過m(i)與閾值進(jìn)行比較來對(duì)當(dāng)前的網(wǎng)絡(luò)擁塞狀況進(jìn)行檢測(cè)。如果m(i) > 且m(i) > m(i-1)，同時(shí)該狀態(tài)至少持續(xù)了毫秒，則判斷為網(wǎng)絡(luò)過載（Over-use）；如果m(i) < -，則判斷為網(wǎng)絡(luò)空閑（Under-use）；剩余的情況都被判斷為狀態(tài)。
由此可見，閾值的設(shè)計(jì)對(duì)于整個(gè)算法的性能來說至關(guān)重要。如果的值設(shè)得過大，那么整個(gè)算法的動(dòng)態(tài)就會(huì)顯得過于平滑，此時(shí)只有在數(shù)據(jù)分組嚴(yán)重delay時(shí)檢測(cè)器才會(huì)觸發(fā)over-use的信號(hào)；相反的，如果的值設(shè)得過小，那么檢測(cè)器就會(huì)對(duì)delay非常敏感，從而導(dǎo)致頻繁觸發(fā)over-use信號(hào)。因此，提出了針對(duì)閾值的動(dòng)態(tài)調(diào)整算法：
(i) = (i-1)+ (t(i) - t(i-1)) * K(i) * (|m(i)| - (i-1))
其中，當(dāng)|m(i)| < (i-1)時(shí)K(i)=K_d；否則，K(i)=K_u。
在中本小節(jié)所涉及的各參數(shù)的參考值如下：
(0) = 12.5 ms, = 10 ms, K_u=0.01, K_d=0.00018
2.1.5 速率控制（rate ）
速率控制子系統(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)機(jī).png
速率控制子系統(tǒng)最終會(huì)輸出一個(gè)帶寬估計(jì)值A(chǔ)_hat，并通過RTCP （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)行：
更新之后將與A_hat進(jìn)行比較，然后取兩者中的較小值作為最終的帶帶寬估計(jì)值。
其實(shí)在原生的代碼中，系統(tǒng)還會(huì)將丟包率和RTT作為參數(shù)，通過TFRC [RFC 5348]的吞吐率計(jì)算公式對(duì)當(dāng)前的帶寬進(jìn)行估計(jì)，而最終的估計(jì)值則是取三者中的最小值。
3. 后語
通過上文的介紹，我們知道中的擁塞控制算法還是非常完備的。其分別針對(duì)數(shù)據(jù)包的延遲和丟包設(shè)計(jì)了delay-based和loss-based擁塞控制算法，在兩者的共同作用之下，能夠滿足大部分場(chǎng)景下的實(shí)時(shí)視頻通話業(yè)務(wù)。但是，如果有要對(duì)中的媒體引擎進(jìn)行移植的朋友js取系統(tǒng)時(shí)間有延遲，首先要分析一下的擁塞控制算法是否滿足你的業(yè)務(wù)需求：如果是開發(fā)獨(dú)立應(yīng)用，由于業(yè)務(wù)閉環(huán)，直接使用現(xiàn)有的算法應(yīng)該問題不大；但是，如果是用于開發(fā)提供類似VoLTE/這樣的運(yùn)營(yíng)商增值服務(wù)的應(yīng)用，需要依據(jù)運(yùn)營(yíng)商的技術(shù)手冊(cè)和3GGP協(xié)議等來對(duì)擁塞控制算法進(jìn)行適配。
[1] A for Real-Time draft-ietf-rmcat-gcc-02
[2] RFC 5348
[3]
[4] 3GPP TS 26.114