Hi~這裡是25萬+社交，泛娛樂，出海開發者青睞的全球網際網路通訊雲·融雲若你對國產化，協同辦公解決方案感興趣，歡迎關注本號的【兄弟號】關注【融雲 RongCloud】，瞭解協同辦公平臺更多幹貨。
今天，你劉畊巨集女孩了嗎？關注【融雲全球網際網路通訊雲】瞭解更多
持續大熱的“李佳琦女生”和近期大勢的“劉畊巨集女孩”都在證明著，直播行業依然熱度不減。經過多年發展，直播已經衍生出了越來越豐富的玩法，比如連麥 PK、一起看等。而這些場景，都非常依賴 RTC 實時音視訊技術的興起。
疫情反覆，很多人又進入了居家時刻。把生活和工作轉向線上成為大家對抗“停擺”焦慮的解決方案。除了直播、語聊房等娛樂社交場景，還有線上課堂、視訊會議，乃至線上問診諮詢。
在我們把娛樂、社交和生活的方方面面搬到線上的過程中，RTC 實時音視訊技術迅速發展，不斷打卡新應用，滲透新場景。
一體兩面，當先進技術為線上場景帶來巨大增長的同時，也面臨使用者越來越高的體驗要求，更低延時、更高畫質、更加順暢。
這三個使用者體驗的影響因素，對應著的也是 RTC 的三大核心指標，即實時性、清晰度、流暢度。
三者之間，往往魚與熊掌不可兼得。實時性要求較高的場景可能會犧牲清晰度來保障低延時；而清晰度要求高的場景則可能用一定的延時換取高質量的音視訊資料。
但是，小孩子才做選擇。為了做到“既要又要”，我們通常需要通過網路傳輸優化來追求更低的延時、更高的清晰度和流暢性。其中的大 BOSS 就是弱網，這是造成擁塞、丟包、延時抖動等影響使用者體驗問題的主要因素。
弱網對抗技術就是針對上述問題以及其他網路損傷問題的技術解決方案統稱。本文分享 RTC 系統音視訊傳輸弱網對抗技術概覽。
關於 TCP/IP 傳輸層協議的選擇
首先，簡要介紹一下傳輸層協議。
傳輸層協議在 TCP/IP 分層協議中位於應用層之下，一般由作業系統內部提供實現，包括 TCP 和 UDP 兩種協議。TCP 是面向連線的可靠傳輸協議，為資料傳輸的完整性和有序性提供了保障；UDP 是無連線的不可靠傳輸協議，資料傳輸的可靠性完全交由應用層處理。
實時音視訊應用場景下，UDP 作為優先選擇已經是業界廣泛共識。原因主要包括以下幾點：
TCP 協議並非為音視訊實時應用場景設計，其內部的擁塞控制和差錯控制等機制為了可靠性和高吞吐量而導致延時的增加，在弱網環境下延時的惡化更為明顯。ITU StandardG.114 對延時的定義是，端到端延時大於 400ms 時，使用者的互動體驗將受到明顯的影響。
TCP 的擁塞控制機制和差錯控制機制位於作業系統內部實現，應用層無法優化，無法應對不同場景需求進行調整，嚴重缺乏靈活性。
UDP 協議本身開銷比 TCP 小，傳輸控制策略完全交由應用層來實現，具有足夠的靈活性。
因此，本文後續討論的弱網問題及相應的弱網對抗技術基於 UDP 協議以及執行在 UDP 之上的被音視訊領域廣泛應用的 RTP/RTCP 協議來討論。
弱網主要問題及其對抗技術
音視訊傳輸弱網問題簡單來說就是指影響音視訊通訊使用者體驗的網路環境問題，主要指網路擁塞、網路丟包、抖動等問題。
這些問題是造成音視訊卡頓、實時性不佳的主要原因。由於網路環境具有較強複雜性、異構性，上述的弱網問題在不同環境下的嚴重程度也有很大差異。如何保障使用者在複雜網路環境下進行順暢的溝通，一直是 RTC 領域關注的重點問題。
擁塞問題
當網路中傳輸的資料流量超過網路瓶頸容量，就會產生擁塞問題。
擁塞的直接影響是突發丟包或者突發抖動，如果不及時預測擁塞的發生，及時降低傳送資料量，接收端將會出現卡頓、延時大、畫質差等等問題。
對抗擁塞問題的主要方案是，通過設計擁塞控制演算法對網路擁塞進行及時的探測，並從擁塞狀態儘可能快地恢復，儘量降低對使用者體驗的影響。
擁塞控制演算法的需求考慮
RFC8836 對實時互動式音視訊應用的擁塞控制演算法需求進行了較為全面的總結，簡單概括如下：
- 延時：擁塞控制演算法應該儘可能降低延時，尤其是演算法本身引入的延時。與此同時仍然需要提供可用的頻寬水平。
- 吞吐率：在相應場景下吞吐率應儘可能高。
- 公平性：擁塞控制演算法應該能夠和其他實時流量和 TCP 流量公平地共享鏈路頻寬。
- 避免“餓死”：媒體流在與 TCP 流競爭中不應被“餓死”，也不能把 TCP 流“餓死”。
- 收斂速度：在媒體流啟動階段儘可能快地收斂到穩定狀態。
- 網路支援：演算法不應要求特殊網路特性支援。
- 穩定性：演算法應該在媒體流變化時保持穩定，比如媒體流暫時的傳輸中斷。
- 快速響應：演算法應該快速響應網路環境的變化，比如瓶頸頻寬變化、鏈路延時變化等。
綜合上述需求，擁塞控制演算法要解決的問題可歸類為兩個方面，一是如何快速準確地進行網路擁塞探測；二是採取適當的擁塞應對措施儘量避免擁塞以及儘可能快地從擁塞狀態恢復。
擁塞探測演算法
擁塞探測演算法根據觀測資料的差異可用分為兩類：
基於丟包的演算法（Loss-based）：通過丟包事件來檢測網路擁塞。
基於延時的演算法（Delay-based）：通過對延時的測量來判斷網路擁塞。
對於實時音視訊互動式應用，基於延時的演算法是更優的選擇，主要原因是基於延時的演算法能夠更早地發現網路擁塞，從而避免由於擁塞導致的丟包。
此外，基於丟包的演算法往往為了探測鏈路容量而不斷增加傳送頻寬，直至丟包事件發生。這種策略將導致無法控制的網路排隊延時增長，尤其是網路節點的緩衝區較大時，甚至造成秒級延時的增長。
選擇基於延時的演算法要重點考慮需求總結中的避免“餓死”問題。基於延時的演算法對延時增長相對要敏感，在與基於丟包的演算法競爭網路資源時要採取適當的策略，相對公平地分享網路頻寬資源。
基於延時的演算法一般通過測量 RTT（round-trip time 往返延時）或者 OWD（one-way delay 單向延時）來判斷擁塞。
RTT 測量比較直觀，但是由於是測量雙向延時的總體情況，因此反向的延時變化會對媒體流方向的網路擁塞判斷造成干擾。OWD 延時觀測則避免了這個問題。如下圖所示：
（單向延時變化）
OWD 通過觀測傳送間隔與接收間隔的變化來判斷網路排隊延時的狀況。
擁塞應對措施
簡而言之，擁塞應對措施就是根據網路當前的擁塞狀況計算出合適的傳送速率來控制媒體傳送端的總髮送速率。根據傳送端所採取的其他弱網對抗策略，可能的速率調節手段包括調節音視訊編碼器速率、調節重傳速率、調節 FEC 冗餘度等，詳見本文後續介紹。如果傳送端是中間轉發節點，則調節手段還包括 SVC 碼流適配、大小流碼流適配等，如下圖所示：
（SVC 碼流分發示意圖）
典型擁塞控制框架
典型的擁塞控制演算法框架如下圖所示：
（WebRTC 擁塞控制架構 1）
這是早期 Google 在其 WebRTC 框架中採用的擁塞控制框架。採用傳送端和接收端混合控制模式，傳送端採用基於丟包的演算法，基本策略如下：
- 丟包率<2%，增加傳送頻寬 8%；
- 丟包率 2% ~ 10%，傳送頻寬保持不變；
- 丟包率>10%，降低傳送頻寬（1-0.5*丟包率）。
接收端採用基於延時的演算法。通過統計單向延時變化並通過卡爾曼濾波對當前的傳輸延時進行估計，再結合當前的實際接收頻寬評估一個最佳的目標頻寬，通過 RTCP 訊息反饋給傳送端。傳送端取兩個演算法結果的最小值作為最終的目標頻寬。
下圖是 WebRTC 改進後的擁塞控制框架。
（WebRTC 擁塞控制架構 2）
我們可以看到整個擁塞控制機制都在傳送端實現，接收端只是反饋相應的測量資料。
新的框架改進了網路延時估計演算法，通過對單向延時變化資料進行線性迴歸分析，評估當前網路排隊延時變化趨勢，即判斷出延時正在增加、沒有變化、正在降低三種趨勢，再結合當前傳送速率，給出最佳目標頻寬估計。
除了改進擁塞探測演算法，新的框架也引入了主動頻寬探測機制，優化了整個擁塞控制演算法的效能，經過比較，在啟動階段收斂速度、網路環境變化的響應速度上都有比較明顯的改進。
丟包問題
如前所述，實時互動式媒體傳輸基於 RTP/UDP 協議，丟包問題由應用層處理。
網路傳輸方面（即通道側）的抗丟包技術手段主要包括重傳（ARQ）、前向糾錯（FEC）。信源編碼方面根據資料以及編碼方的不同也可以提供某些特定的抗丟包能力，比如視訊編碼中採用 B 幀降低丟包的影響。下面主要介紹網路傳輸方面的抗丟包技術。
丟包重傳（ARQ）
在 RTP/RTCP 協議中，丟包重傳技術簡單來講就是接收端根據包序列號的連續性判斷是否丟包，通過向源端傳送 RTCP 中的 NACK 請求，要求源端重傳指定的資料包。丟包重傳流程如下圖所示：
（丟包重傳流程）
重傳流程有以下細節需要考慮：
- 首次請求延時：應結合其他策略考慮發現丟包時是否立即請求，比如結合 FEC 策略考慮。
- 重複請求間隔考慮：同一個資料包重複請求間隔要大於當前 RTT。
- 請求次數限制：結合當前 RTT 與容忍的最大延時來計算。
- 傳送端重傳頻寬限制：重傳頻寬作為總傳輸頻寬的一部分，不能超出總體頻寬限制。
- 重傳包回傳機制：建議採用單獨的 RTP 碼流傳送，利於丟包率統計與重傳頻寬計算。
前向糾錯（FEC）
在實時音視訊應用中，前向糾錯（FEC）技術在抗丟包方面因其實時性好而被廣泛應用。
FEC 的基本思路粗略來講就是傳送端在傳送音視訊資料包之外，根據具體丟包狀況再額外傳送一定量的冗餘資料包用於接收端進行丟包恢復，基本流程如下圖所示：
（FEC 處理流程，其中 D 為資料包，C 為修復包）
目前常用的關於修復資料包的編碼演算法有基於異或的演算法、基於矩陣的演算法以及其他演算法，本文不做詳細闡述。
下面介紹一下 FEC 在實時音視訊系統中的基本應用框架，傳送端應用框架如下圖所示：
（FEC 傳送端框架）
上圖中的 ADU 為應用資料單元，在音視訊 RTC 系統中也就是音視訊資料包，作為源資料塊輸入到 FEC 編碼器，FEC 編碼器根據一定的修復比率產生 FEC 修復包（repair payloads），修復包和源包及其之間保護關係一起傳送給接收端。
接收端的 FEC 處理框架如下圖所示：
（FEC 接收端框架）
接收端收到 FEC 源包和修復包後送到 FEC 解碼器。如果源包丟失，解碼器根據包組的保護關係以及收到的包組狀況進行解碼修復，最後將修復完成的音視訊包交由上層進一步處理，完成音視訊解碼與顯示播放。
上述中的修復包與源包的保護關係簡而言之就是哪些源包被哪些修復包保護，這個保護關係由傳送端通過一定的封包格式通知到接收端。
在 RTP/RTCP 協議框架下，ULPFEC（RFC5109）和 FlexFEC（RFC8627）兩個標準定義了兩種不同的策略和包格式：
ULPFEC：ULP（Uneven Level Protection，不均等保護）根據資料包重要程度使用不同級別的保護策略。
FlexFEC：Flexible Forward Error Correction，此標準在 RTP 協議框架下定義了交織與非交織的奇偶校驗 FEC 編碼包格式。
ARQ 與 FEC 的配合
相較於 FEC，ARQ 的缺點是會引入延時，優點是有較高的頻寬利用率。抗丟包技術的優化目標概括來講就是在滿足延時要求的前提下，儘量以最小的額外頻寬與計算成本，獲得足夠的保護力度。
因此，在考慮 ARQ 與 FEC 的配合策略時應考慮以下原則：
- 在延時限制容許的前提下儘可能使用 ARQ，可根據當前 RTT 和最大延時限制計算最大重傳次數；
- 如果最大重傳次數可以將丟包率降低到一定程度以下（<%1)，則不必開啟 FEC 保護；
- 如果需開啟 FEC，FEC 的保護程度要依據應用 ARQ 修復之後剩餘的丟包概率來計算，進行兜底保護。
下圖是在一定場景下的 FEC 與 ARQ 配合示意圖，RTT 在 20ms 內，如果傳輸延時要求在 100ms 以內，在丟包 30% 的弱網鏈路上，則 ARQ 可以將丟包率降低到 1% 以下，則由 ARQ 負責丟包修復。
隨著 RTT 的上漲，FEC 的保護佔比增加，最終由 FEC 單獨負責丟包修復。
（ARQ 與 FEC 機制配合）
抖動問題
概括而言，抖動問題就是網路傳輸延時變化問題，抖動越大表示網路傳輸延時變化越大。
抖動問題會造成接收端卡頓、播放快進等嚴重影響音視訊溝通體驗的問題。造成抖動問題的原因是多方面的，比如新的流加入造成網路資源競爭加劇、源端資料傳送速率本身不平穩以及其他網路原因。
目前處理抖動的通用策略是接收端建立抖動緩衝區(JitterBuffer)來消除抖動，其原理如下圖所示：
（抖動緩衝原理）
接收端通過增加抖動延時（JitterDelay）來吸收不均勻的延時，達到均勻播放的目的。
其中，抖動延時大小的計算是抖動緩衝區效能好壞的關鍵，過大的抖動延時會引入額外延時，這在實時互動式應用領域是極力要避免的；過小又無法吸收全部的抖動。
關於抖動延時的估計，Google 在其 WebRTC 框架中用了兩種方法，在音訊抖動處理中用直方圖加遺忘因子的方式進行估計，如下圖所示：
（NetEQ 抖動延時統計）
WebRTC 的音訊抖動延時估計在其內部的 NetEQ 模組中，圖中的 Iat 意為間隔達到時間，WebRTC 通過對音訊包到達間隔用直方圖進行統計，取 95 分位數的延時時長作為音訊抖動延時。
為了跟蹤延時變化，NetEQ 中採用遺忘因子對直方圖中的歷史資料進行遺忘。當然，NetEQ 所提供的是一個綜合的音訊 QoS 保障技術，還有許多其他的技術參與處理音訊抖動，如峰值抖動檢測、語音變速等，這裡不再詳述。
視訊抗抖動方面，WebRTC 採用不同於音訊的抖動延時估計演算法，通過對實際的幀尺寸變化與延時變化資料的測量與統計，利用卡爾曼濾波器動態地進行最優抖動延時估計。
然而，WebRTC 主要為一對一實時溝通的應用場景設計，在如視訊會議等一對多、多對多場景下，音視訊流更多的是通過流媒體中轉服務轉發。通過實測，該演算法對多節點轉發場景下的全鏈路抖動延時估計效果有待改進。
融雲的弱網對抗技術優化實踐
融雲的優化措施
- 擁塞控制方面，基於 Google GCC 演算法進行改進。除了統計單向延時變化進行擁塞趨勢判斷之外，同時對丟包模式進行進一步分析，提升頻寬預測的準確率。
- 抗丟包方面，基於 FlexFEC 框架，採用高修復能力的 FEC 編碼，並進行綜合調優來提升抗丟包能力。
- 優化 ARQ 與 FEC 機制的配合，力求抗丟包付出的代價最小。
- 抗抖動方面，採用場景適應性更強的抖動延時估計方法，力求提升流暢度的同時減少延時。
部分結果
下圖展示了目前高丟包場景下弱網抗性測試結果。
（高丟包場景測試結果）
在 60%、70% 的高丟包場景下，Android 和 iOS 移動端測試結果在流暢度方面 MOS 值仍可以達到 4 分。
在具體弱網優化過程中，由於網路的複雜性、異構性，以及場景需求的多樣性，實時音視訊傳輸策略與弱網對抗技術充滿著各種選擇、平衡與取捨的考量，新的基於線上學習、強化學習的技術思路也在該領域開始進行嘗試。
我們也將繼續探索實踐，為提升融雲實時音視訊 RTC 產品的綜合使用者體驗而不斷努力。