摘要

火山引擎智能擁塞控制算法 VICC（Volcano Intelligent Congestion Control）是一種自適應(yīng)的擁塞控制算法，旨在解決全球不同網(wǎng)絡(luò)環(huán)境下，不同音視頻應(yīng)用對帶寬利用率和延時的差異化要求。它結(jié)合了傳統(tǒng)擁塞控制算法（如 GCC 和 BBR）的優(yōu)點，并且能夠根據(jù)不同的網(wǎng)絡(luò)條件、業(yè)務(wù)偏好和碼率特征進(jìn)行自適應(yīng)調(diào)整，包括自適應(yīng)擁塞響應(yīng)速度、自適應(yīng)帶寬探測幅度、自適應(yīng)丟包檢測策略、自適應(yīng)抗抖動能力和自適應(yīng) Padding。通過這些自適應(yīng)調(diào)整，VICC 算法能夠提升各種復(fù)雜弱網(wǎng)下的帶寬利用率，同時在滿足不同延時的條件下，盡量提升帶寬的穩(wěn)定性，為用戶提供更好的音視頻體驗。

1.  行業(yè)現(xiàn)狀和挑戰(zhàn)

實時音視頻應(yīng)用的網(wǎng)絡(luò)傳輸面臨諸多方面的挑戰(zhàn)，其中包括：

• 帶寬利用率：為了提供高質(zhì)量的音視頻體驗，需要充分利用網(wǎng)絡(luò)帶寬，這就要求網(wǎng)絡(luò)傳輸算法具有高效的帶寬探測能力。
• 延遲和響應(yīng)時間：實時音視頻應(yīng)用要求快速的響應(yīng)時間和超低延遲，這就要求網(wǎng)絡(luò)傳輸技術(shù)具有快速的傳輸速度和低延遲的特性。
• 可靠性和穩(wěn)定性：網(wǎng)絡(luò)傳輸過程中可能會出現(xiàn)擁塞、丟包等問題，這會影響到音視頻的質(zhì)量和穩(wěn)定性，因此要求網(wǎng)絡(luò)傳輸技術(shù)具有可靠性和穩(wěn)定性，能夠保證數(shù)據(jù)的正確傳輸和恢復(fù)。
• 公平性和資源分配：在多用戶場景下，需要保證網(wǎng)絡(luò)傳輸?shù)墓叫院唾Y源分配的合理性，以避免某些用戶獲得過多的資源，導(dǎo)致其他用戶的服務(wù)質(zhì)量下降。

除了上述挑戰(zhàn)，實時音視頻傳輸還需要關(guān)注體驗指標(biāo)，如實時性、流暢性、清晰度、音畫同步性等，這些指標(biāo)對于提供高質(zhì)量的音視頻體驗至關(guān)重要。

1.1 現(xiàn)網(wǎng)音視頻卡頓歸因

為了快速提升線上用戶弱網(wǎng)相關(guān)的體驗，火山引擎根據(jù)抖音集團(tuán)真實用戶的負(fù)反饋數(shù)據(jù)打磨研發(fā)了“音視頻卡頓歸因模型”，它可以對線上音視頻卡頓的所有 case 進(jìn)行自動歸因和聚類，為弱網(wǎng)問題的優(yōu)化和優(yōu)先級給出有效指導(dǎo)。

根據(jù)模型對線上用戶音視頻卡頓反饋的歸因和聚類，我們發(fā)現(xiàn)，當(dāng)前引起線上卡頓問題的主要原因是上下行大小緩存問題。

線上用戶視頻/音頻卡頓歸因類型占比

大小緩存的描述，可以參考：https://www.ietf.org/archive/id/draft-cardwell-iccrg-bbr-congestion-control-00.txt

大緩存：Deep buffers，at bottleneck links with deep buffers, congestion happens before packet loss.

小緩存：shallow buffers， in shallow buffers, packet loss happens before congestion.

1.2 RTC 主流擁塞控制算法分析

自 Google 開源 WebRTC 實時音視頻框架以來，GCC 作為默認(rèn)擁塞控制算法備受行業(yè)研究和關(guān)注，而 WebRTC 在演進(jìn)過程中，也在不斷演進(jìn)集成 BBR、PCC 等擁塞控制算法，以期望進(jìn)一步提升實時音視頻的傳輸性能。

下文以 GCC 和 BBR 算法為例，我們來看一看當(dāng)前主流擁塞控制算法的特性和不足。

1.2.1 GCC 算法

GCC 算法是專為實時音視頻傳輸設(shè)計的擁塞控制算法，但隨著網(wǎng)絡(luò)環(huán)境日益復(fù)雜、音視頻應(yīng)用場景越來越豐富，GCC 算法難以提升上限以獲得更好的音視頻傳輸體驗。

GCC 算法帶寬估計與觸發(fā)擁塞延時示意圖

GCC 算法的關(guān)鍵特征

GCC 算法的發(fā)送/接收碼率的聯(lián)動是非連續(xù)性的。在檢測到擁塞之前，發(fā)送碼率和接收碼率是不聯(lián)動的；檢測到擁塞之后，發(fā)送碼率和接收碼率才開始聯(lián)動。如果要降低非聯(lián)動過程中的網(wǎng)絡(luò)延遲，GCC 算法需要過降帶寬排空非聯(lián)動過程中網(wǎng)絡(luò)中堆積的數(shù)據(jù)。另外，GCC 的網(wǎng)絡(luò)探測速度也較慢。

GCC 算法存在的問題

GCC 算法的幾個主要問題中，最核心的問題是帶寬估計的準(zhǔn)確性（帶寬利用率）和擁塞檢測的有效性（對網(wǎng)絡(luò)的沖擊）存在很難調(diào)和的矛盾，導(dǎo)致這個問題的主要原因是：

• GCC 算法的帶寬估計強(qiáng)依賴擁塞檢測，即，只有在算法判斷為網(wǎng)絡(luò)擁塞的情況下，才能進(jìn)行帶寬估計；
• GCC 算法的擁塞控制靈敏度受到帶寬估計的影響很大， 意味著當(dāng)實際發(fā)送碼率越貼近真實帶寬，擁塞檢測受到的干擾越大

1.2.2 BBR 算法

BBR 算法是互聯(lián)網(wǎng)通用的擁塞控制算法，其設(shè)計目標(biāo)追求高帶寬利用率、低擁塞延遲和丟包，BBR 在通用互聯(lián)網(wǎng)領(lǐng)域具備良好的性能表現(xiàn)，但因其設(shè)計目標(biāo)和算法特性，不適應(yīng)于實時音視頻傳輸場景。

BBR 算法帶寬估計與觸發(fā)擁塞延時示意圖

BBR 算法的關(guān)鍵特征

和 GCC 算法不同，BBR 算法的發(fā)送/接收碼率的聯(lián)動是連續(xù)性的，它實時跟蹤接收碼率，同時根據(jù)擁塞檢測的結(jié)果，來調(diào)整發(fā)送窗口（cwnd）的大小，并最終影響發(fā)送碼率。

BBR 算法存在的問題

雖然 BBR 在帶寬估計準(zhǔn)確性上等能力要高于 GCC，但它也存在一些明顯的問題：

• 突發(fā)擁塞時收斂速度慢；
• 當(dāng)鏈路丟包高于一定閾值時，吞吐量斷崖式下跌；
• 抗抖動能力一般；
• 反向鏈路丟包延時影響上行帶寬估計；
• 探測最小延遲劇烈降窗不適用實時音視頻傳輸；

由于 GCC 和 BBR 等算法在實時音視頻傳輸場景存在一些不足，火山引擎網(wǎng)絡(luò)傳輸團(tuán)隊自研了 VICC 算法，旨在優(yōu)化上述問題的同時，也為火山引擎實時音視頻業(yè)務(wù)提供更加良好的用戶體驗。

2. 火山引擎智能擁塞控制算法 VICC 介紹

VICC 算法主要通過網(wǎng)絡(luò)狀態(tài)統(tǒng)計進(jìn)行自適應(yīng)帶寬估計決策，并作出帶寬評估動作，以提升各種復(fù)雜網(wǎng)絡(luò)下?lián)砣刂频男阅鼙憩F(xiàn)。在近一年的實驗室和線上業(yè)務(wù)打磨過程中，我們深入分析了不同算法原理及現(xiàn)網(wǎng)痛點弱網(wǎng)問題，輸出了 40+ 項最佳工作點及 9 篇技術(shù)專利，線上業(yè)務(wù)的各項指標(biāo)，特別是視頻卡頓率、首幀時長等也得到了顯著的改善。

火山引擎智能擁塞控制算法 VICC 架構(gòu)圖

2.1 網(wǎng)絡(luò)狀態(tài)統(tǒng)計

評估當(dāng)前網(wǎng)絡(luò)狀態(tài)的重要指標(biāo)之一是網(wǎng)絡(luò)狀態(tài)統(tǒng)計參數(shù)，而準(zhǔn)確的基礎(chǔ)網(wǎng)絡(luò)狀態(tài)參數(shù)是提高帶寬估計準(zhǔn)確性和帶寬利用率的關(guān)鍵基石。VICC 算法提供了多種基礎(chǔ)網(wǎng)絡(luò)狀態(tài)參數(shù)，部分基礎(chǔ)網(wǎng)絡(luò)狀態(tài)統(tǒng)計參數(shù)如下：

2.2 自適應(yīng)擁塞控制

VICC 算法結(jié)合了傳統(tǒng)擁塞控制算法的優(yōu)點，并且能夠根據(jù)不同的網(wǎng)絡(luò)條件、業(yè)務(wù)偏好和碼率特征進(jìn)行自適應(yīng)調(diào)整，包括自適應(yīng)擁塞響應(yīng)速度、自適應(yīng)抗干擾能力、自適應(yīng)丟包檢測、自適應(yīng)帶寬探測幅度、自適應(yīng)擁塞排空等。

2.2.1 自適應(yīng)擁塞檢測

VICC 繼承并優(yōu)化了 GCC 和 BBR 擁塞檢測能力，通過對發(fā)送碼率、接收碼率及延遲參數(shù)的關(guān)系進(jìn)行建模，觀察延遲參數(shù)變化趨勢及其關(guān)聯(lián)性，以及對于延遲參數(shù)的容忍程度進(jìn)行擁塞響應(yīng)，從而快速排空網(wǎng)絡(luò)擁塞。

和 GCC / BBR 相比，VICC 擁塞響應(yīng)及收斂速度更快。

GCC / BBR / VICC 擁塞響應(yīng)及收斂速度比較（線上實測）

2.2.2 自適應(yīng)抗干擾能力

擁塞響應(yīng)越靈敏，意味著在網(wǎng)絡(luò)抖動場景下容易誤判，導(dǎo)致算法抗干擾能力下降。VICC 使用蟻穴算法來對抗網(wǎng)絡(luò)抖動和亂序，通過接收碼率和發(fā)送碼率來度量網(wǎng)絡(luò)透過率，并結(jié)合觀察延遲參數(shù)變化趨勢及關(guān)聯(lián)性，提升自適應(yīng)抗干擾能力。

VICC 可以對抗 2000ms 以內(nèi)的延遲抖動幅度，抗抖動能力顯著比 GCC 和 BBR 強(qiáng)。

GCC / BBR / VICC 抗抖動能力比較（線上實測）

靈活可配置的擁塞檢測靈敏度

在自適應(yīng)擁塞檢測的基礎(chǔ)上，VICC 還會根據(jù)業(yè)務(wù)偏好，提供靈活可配置的擁塞檢測靈敏度模式設(shè)置，以適用于不同業(yè)務(wù)場景的訴求，并做好擁塞響應(yīng)靈敏和抗干擾能力強(qiáng)的 trade-off。

以火山引擎 RTC 典型應(yīng)用場景為例，互娛、企業(yè)通訊等場景一般可以容忍 200-300ms 的延時，而遠(yuǎn)程車控、云游戲等場景只能容忍 50-100ms 的延時。VICC 提供多種模式來適應(yīng)不同場景的延時需求，在延時容忍度較高的場景，VICC 可以通過延遲擁塞響應(yīng)時間來獲得更高的帶寬估計的穩(wěn)定性，在延時容忍度較低的場景，VICC 可以通過快速擁塞響應(yīng)來降低網(wǎng)絡(luò)擁塞延遲。

火山引擎 RTC 典型應(yīng)用場景

2.2.3 自適應(yīng)丟包檢測能力

通過對發(fā)送碼率、接收碼率及丟包參數(shù)的關(guān)系進(jìn)行建模，并微幅調(diào)整發(fā)送碼率，檢測接收碼率和丟包參數(shù)之間的關(guān)聯(lián)性，VICC 可以自適應(yīng)檢測出丟包為隨機(jī)丟包和擁塞丟包。一旦識別出隨機(jī)丟包后，VICC 可以準(zhǔn)確地對隨機(jī)丟包進(jìn)行系數(shù)補(bǔ)償，以達(dá)到不誤降帶寬的效果。

和 GCC / BBR 相比，VICC 隨機(jī)丟包抗性可達(dá)到 70% 以上。

GCC / BBR / VICC 隨機(jī)丟包抗性比較（線上實測）

2.2.4 復(fù)雜弱網(wǎng)處理能力

考慮實時音視頻傳輸對于延遲的容忍，根據(jù)延遲參數(shù)的程度、自適應(yīng)上探幅度及下探幅度，在保留競爭力的同時，VICC 避免了因為頻繁探測引入的網(wǎng)絡(luò)延遲堆積問題。同時，在檢測到擁塞緩解后，VICC 通過對發(fā)送碼率、接收碼率及延遲參數(shù)的關(guān)系進(jìn)行建模，迅速提升帶寬上探幅度和調(diào)整時間窗口；在探測到帶寬滿足音視頻傳輸體驗后，再逐步放慢上探幅度和時間間隔。

當(dāng)網(wǎng)絡(luò)存在瓶頸帶寬時，VICC 的帶寬探測相對 GCC 和 BBR 更平穩(wěn)。當(dāng)瓶頸帶寬發(fā)生變化時，VICC 可以快速跟蹤實際瓶頸帶寬。

GCC / BBR / VICC 帶寬探測平穩(wěn)度比較

2.3 自適應(yīng) Padding 策略

VICC 使用自適應(yīng) Padding 策略來解決帶寬下溢疊加復(fù)雜弱網(wǎng)場景下的帶寬估計，在精準(zhǔn)探測網(wǎng)絡(luò)帶寬的同時，盡量避免網(wǎng)絡(luò)沖擊和帶寬浪費。在決策需要發(fā)送 Padding 時，會先根據(jù)帶寬估計值設(shè)定目標(biāo)發(fā)送碼率，并實時度量接收碼率，同時動態(tài)調(diào)整目標(biāo)碼率。

VICC 自適應(yīng) Padding 策略示意圖

3. VICC 表現(xiàn)及收益

通過對擁塞響應(yīng)速度、帶寬探測幅度、丟包檢測策略、抗抖動能力等一系列的“自適應(yīng)調(diào)整”，VICC 算法能夠提升各種復(fù)雜弱網(wǎng)下的帶寬利用率，同時在滿足不同延時的條件下，盡量提升帶寬的穩(wěn)定性，為用戶提供更好的音視頻體驗。

3.1 算法表現(xiàn)

為了更直觀地展示 VICC 算法對于用戶音視頻體驗的提升效果，我們在不同類型的弱網(wǎng)環(huán)境下進(jìn)行了音視頻通話測試，通過比較對端畫面的實時性和流暢性來比較 VICC 算法和市場上同類算法的擁塞控制能力。

在上行 70% 丟包網(wǎng)絡(luò)環(huán)境下，使用了 VICC 算法的火山引擎 RTC 依然保持穩(wěn)定傳輸，幾乎沒有表現(xiàn)出卡頓。

當(dāng)網(wǎng)絡(luò)突發(fā)上行 300kbps 限速小緩存時，使用了 VICC 算法的火山引擎 RTC 出現(xiàn)了短暫的卡頓，但算法很快進(jìn)行了對抗，迅速恢復(fù)穩(wěn)定和流暢，對用戶的體驗影響較小。

3.2 線上收益

VICC 算法經(jīng)過了字節(jié)內(nèi)部質(zhì)量專項評估實驗室打磨和驗證后，在火山引擎線上業(yè)務(wù)上也進(jìn)行了充分的流量驗證，在視頻通話、屏幕共享等場景中，視頻卡頓率和首幀指標(biāo)得到了顯著的改善，其中，視頻通話卡頓率下降 27%、首幀延時下降 100ms+；屏幕共享卡頓率下降 15%，首幀延遲下降 200ms。 同時，使用自適應(yīng) Padding 策略后，現(xiàn)網(wǎng)上下行碼率也得到了明顯的改善，其中，上行Padding碼率下降 90%，下行下降 70%。

VICC 算法上線后對視頻卡頓、首幀和 Padding 碼率指標(biāo)的改善

4. 未來展望

在網(wǎng)絡(luò)環(huán)境高度復(fù)雜的背景下，影響用戶體驗的因素眾多，有時通用算法難以精準(zhǔn)匹配所有場景的環(huán)境特點，因此，一些特定場景的用戶體驗難以做到極致，無法實現(xiàn)“個性化場景自適應(yīng)”的目標(biāo)。

未來，我們將根據(jù)線上問題歸因聚類建模，對用戶網(wǎng)絡(luò)場景精準(zhǔn)識別，提升網(wǎng)絡(luò)場景識別算法的準(zhǔn)度和范圍，并以此為驅(qū)動，針對不同的弱網(wǎng)場景進(jìn)行全鏈路的差異化優(yōu)化，使算法在各類網(wǎng)絡(luò)模型下的收斂達(dá)到最優(yōu)，持續(xù)提升用戶體驗。