魏榮賓 位元組跳動技術團隊 2023-05-31 12:01 發表于北京
幹貨不迷路
傳統的資料傳輸方式大多是利用一個鍊路、選擇裝置的預設網卡進行傳輸，使用這種方式實作實時音視訊通話時，如果預設網絡出現問題（如斷網、弱網等），使用者的通信就會發生中斷或者卡頓，影響使用者體驗。
多鍊路傳輸，顧名思義，就是使用多個鍊路進行傳輸資料的一種技術。近年來，單裝置上支援多個可用網卡的技術越來越普遍，比如我們的手機就同時支援無線網卡和 4G/5G 網卡，有些雙卡手機還能同時支援兩個 4G/5G 網卡。而多鍊路技術就是充分利用使用者裝置上的多個網絡資源進行資料傳輸，當某一個網絡出現問題時，其他可用網絡可以繼續不間斷地傳輸資料，避免因單一網絡問題導緻通話中斷或者卡頓，提升使用者通話的可用性和流暢性。
目前，多鍊路傳輸技術已經在火山引擎 RTC 打磨基本成熟，并在抖音和飛書會議等業務場景落地，有效地降低了使用者的通話卡頓率，提升了使用者的體驗。
1. 行業現狀和挑戰
多鍊路技術在一些行業已經實作了應用，如 Apple 的 MPTCP(Multi-Path TCP) 就是一種多鍊路技術，Apple 把它用在了 Siri、Apple Maps、Apple Music 等應用上，用來解決使用者在戶外移動時，系統網絡經常在 Wifi 和蜂窩網絡之間切換導緻的應用使用不流暢的問題。我們在使用微信的音視訊通話功能時，微信也會開啟音頻雙發功能，即使用 Wifi 網絡和蜂窩網絡同時發送音頻資料，以提高使用者的通話體驗。
使用多鍊路傳輸技術讓資料傳輸多了一層“可靠性”的保障，還能讓網絡切換變得更加絲滑，當然，在享受多個網絡傳輸帶來的好處時，我們也需要解決一些多鍊路技術實作上的問題。
一是多鍊路傳輸的架構比單鍊路傳輸複雜，比如需要考慮多個鍊路傳輸帶來的資料包備援、去重問題，多個鍊路的帶寬、品質如何評估準确問題等；二是需要 平衡使用者體驗和流量、電量消耗，利用多個鍊路傳輸資料時，不可避免地會引起流量消耗變大，尤其是使用者蜂窩流量變大，而流量消耗變大不僅會影響到帶寬消耗和擠占，還會影響使用者手機的功耗消耗，嚴重影響使用者的使用體驗。
業界目前的多鍊路使用方式主要有兩種：一種是完全備援的雙鍊路傳輸，即，隻要開啟雙鍊路，無論在什麼情況下，都會傳輸雙份資料。這種方式的缺點是明顯的，它不判斷 使用者網絡的好壞 “無腦”進行雙鍊路傳輸 ，會明顯帶來流量和功耗的增長，可能導緻 使用者 手機發熱等問題，影響使用者體驗；另外一種是 在 兩條鍊路之間切換使用，這種方式能避免第一種完全備援傳輸方式帶來的功耗和流量增加，但這種方式也有缺點，比如兩條鍊路在切換使用時，可能造成不平滑和卡頓，并且這種 傳輸 方式也不能充分利用兩條鍊路 資源帶來的“增加可靠保障”的好處。
火山引擎 RTC 在完全備援模式基礎上，研發了一個兼顧使用者體驗和流量、功耗消耗的傳輸模式：弱網備援傳輸。弱網備援傳輸，顧名思義，就是在 RTC 系統檢測到弱網時才開啟雙鍊路的能力進行傳輸資料。這種模式既能在使用者弱網時充分利用兩條鍊路傳輸資料，使使用者體驗基本不會受弱網影響；又能在使用者網絡正常時使用單鍊路傳輸，減少對使用者流量和功耗的消耗。
2. 多鍊路傳輸技術演進
2.1 完全備援傳輸
完全備援傳輸是指資料，包含音視訊、信令、消息等資料，通過兩條獨立的路徑在用戶端和服務端之間傳輸，主鍊路的資料會完全複制一份到備選鍊路。完全備援傳輸依靠多路徑架構、多徑協定、去重算法實作，其中多徑協定和去重算法是關鍵部分。完全備援傳輸可以有效地避免因單個路徑産生問題而導緻的通信中斷問題，進而提升使用者通話的可用性。
2.1.1 架構設計
架構設計上，完全備援傳輸隻存在于 SDK 連接配接子產品和邊緣媒體節點之間。在發送端，SDK 傳輸子產品負責把上層的資料進行備援，并通過兩個通道同時發送出去，邊緣媒體節點負責在接收到資料時，把資料進行去重還原，然後交給上層的服務。在接收端，邊緣媒體節點負責對資料進行備援發送，而 SDK 傳輸子產品則負責對接收資料進行去重和還原，并把資料交給上層子產品。
完全備援的多鍊路傳輸架構
2.1.2 多徑協定
多徑協定的設計至少要滿足兩個要求，一是能區分備援多徑包和正常資料包（如 RTP/RTCP 包、STUN 包等），二是能對備援包進行去重。
于是我們設計了如上 4 個位元組的多徑標頭部：Packet Type 字段用來識别備援的多徑包，并和正常的 RTP/RTCP、STUN 包進行區分；Packet Sequence Number 則用來對多徑包進行編号，用于去重；最後一個為保留字段。
例如，一個多徑下的 RTP 包格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xc8 | packet sequence number | default to 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|1| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| 0x10 | 0x00 | length=0 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| RTP payload |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1.3 去重算法
我們利用傳輸子產品儲存一個 65536(16bit) 長度的 bit 數組 bitArrary，初始化狀态為 0，采用滑動視窗的方式過濾重複序号的資料包。
去重算法圖示
如上圖，resetSeq 為視窗最左端值，latestSeq 為視窗最右端值，resetSeq 到 latestSeq 之間為有效判斷視窗，即windowSize，設定為 30000。當子產品收到一個包時，記此包 seqNum 為 curSeq，做如下處理：
- 如果此包是子產品收到的第一個包，則置 latestSeq = seqNum，resetSeq = latestSeq - windowSize，并通知上層收到一個新包；
- 如果此包不是子產品收到的第一個包，則判斷 curSeq 與 latestSeq 之間的距離，如果大于 windowSize，則認為此包為一個無效包（sequence number跳變太大），進行丢棄；如果不大于 windowSize，則認為是一個有效包；
- 接第二步，如果 curSeq < latestSeq，判斷 bitArray 中 curSeq 對應的 bit 位是否為 1。如果不是，則說明我們收到了一個新包，置此位為 1，并告知上層；如果已經為 1，則表示我們收到了一個重複包，直接丢棄。如果curSeq > latestSeq，則也認為是收到新包，告知上層，并移動視窗，置 latestSeq = seqNum，resetSeq = latestSeq - windowSize。
2.1.4 效果
我們模拟了各種網絡環境來測試完全備援的多鍊路傳輸（以下簡稱“完全雙發”）對音視訊品質、裝置性能、功耗的影響。
以下測試資料為在 Wifi 和蜂窩雙鍊路網絡均開啟的情況下，對主鍊路（Wifi）增加弱網時的音視訊通話測試結果。
使用者體驗
整體來看，當開啟完全雙發後，單個路徑的弱網對整體音畫質、端到端延時表現基本沒有影響，使用者仍然能獲得高品質的音視訊通話體驗；關閉完全雙發後，單個路徑的弱網會導緻明顯的卡頓和延時問題。
開啟/關閉完全雙發後，單路徑弱網對音畫質的影響
如上圖，開啟完全雙發後，音質（MOS 分）、畫質（視訊幀率）在不同弱網環境下的表現穩定，音質、畫質基本不受弱網影響。關閉完全雙發後，音質、畫質會随着弱網場景的不同受到不同程度的影響，特别是在 200kbps 限速時，音質、畫質下降嚴重。
開啟/關閉完全雙發後，單路徑弱網對音視訊端到端延時的影響
如上圖，開啟完全雙發後，端到端延時在不同弱網環境下的表現良好且穩定，基本不受弱網影響。關閉完全雙發後，當出現高丢包、高延時弱網時，端到端延時明顯增加，使用者體驗明顯下降。
CPU 和記憶體性能
在各種網絡環境下，開啟或關閉完全雙發對 CPU 和記憶體的消耗沒有太大差别。
開啟/關閉完全雙發後，單路徑弱網對音視訊端到端延時的影響
功耗
測試結果顯示，開啟完全雙發會對裝置功耗造成一定影響，增加通話的電量消耗。
開啟/關閉完全雙發對手機電量消耗的影響（圖為使用 iphone 11 的測試結果）
我們使用同款手機進行持續的音視訊通話，開啟完全雙發比關閉雙發消耗的電量更多、更快，在通話 1 小時後，開啟雙發比關閉雙發多消耗了 4% 的電量。
2.1.5 方案優劣
完全備援的多鍊路傳輸可以有效解決因單一網絡出現問題而造成的音視訊卡頓、延時問題，提升使用者體驗，并且它的實作方式比較簡單。然而，它的缺點也很明顯，一是對流量消耗大，特别是在視訊場景，會消耗比較多的使用者移動流量；二是對功耗的開銷也較大。是以，完全雙發并不符合實際業務上的需求和使用者體驗，我們需要在盡量減少流量消耗和功耗消耗的情況下來提升使用者通話體驗。
2.2 弱網備援傳輸
完全備援傳輸是無論在什麼情況下，資料都會被複制一份到另外一個鍊路上傳輸，這麼做會導緻消耗使用者比較多的流量和功耗。實際上，使用者大部分情況下的網絡是正常的，并不需要開啟備援傳輸，對于正常網絡來說，開啟備援傳輸反而是一種浪費，效果是負面的。是以，我們需要更加有針對性地來開啟多鍊路傳輸，這樣既能提升使用者的通話體驗，也能節省流量和功耗。
弱網備援傳輸，顧名思義，就是在完全備援傳輸的基礎上加上弱網的判斷，即，隻有在弱網時才開啟多鍊路傳輸，它的關鍵在于對弱網判斷的及時性和精準性，系統需要準确判斷出現弱網并及時開啟多鍊路傳輸（以下簡稱“弱網雙發”），這樣才能有效避免網絡卡頓問題。
2.2.1 架構設計
弱網雙發使用的多徑協定、去重算法和完全雙發基本相同，不同點主要在于，弱網雙發在完全雙發的基礎上添加了弱網條件的判斷，隻有當檢測到主鍊路發生弱網時系統才會開啟雙發（使用移動網絡發送資料），否則不開啟，這樣既保證了正常網絡下不額外消耗流量和電量，又做到了弱網下提升使用者體驗。
完全備援與弱網備援的多鍊路傳輸流程比較
2.2.2 效果
我們比較了不同弱網下，采用完全雙發、弱網雙發和關閉雙發對對音視訊品質、裝置性能、功耗的影響。
使用者體驗
整體來看，無論是完全雙發還是弱網雙發，單個路徑的弱網對整體音質、端到端延時表現基本沒有影響，而關閉雙發後，單個路徑的弱網對音質、延時表現影響較大，音質明顯下降，延時明顯升高。在相同弱網條件下，完全雙發的端到端延時比弱網雙發更低。
完全雙發、弱網雙發、關閉雙發時單路徑弱網對音畫質的影響
完全雙發、弱網雙發、關閉雙發時單路徑弱網對端到端延時的影響
CPU 和記憶體性能
在各種網絡環境下，完全雙發、弱網雙發、關閉雙發對 CPU 和記憶體的消耗并沒有太大差别。
功耗
不管是完全雙發還是弱網雙發，都會增加通話的電量消耗，但弱網雙發的耗電量比完全雙發小，能比較有效地降低功耗消耗。
完全雙發、弱網雙發、關閉雙發對手機電量消耗的影響
2.2.3 方案優劣
相比完全備援傳輸，弱網備援傳輸隻有在檢測到主鍊路弱網時才開啟對應資料的雙發，是以更節省流量；同時，因減少了在移動網絡的資料發送，相應地也就減少了電量消耗。不過，由于判斷弱網本身需要時間，弱網判斷的準确性也會影響效果，是以，弱網雙發的端到端延時比完全雙發略大一些，但在一般的實時音視訊使用場景中，這種延時差異對使用者來說體驗不大。
3. 多鍊路傳輸技術的實踐與收益
目前，弱網雙發已經在飛書會議、抖音社交等業務上線，以下是抖音社交業務開啟弱網雙發後較對照組的表現：
可以看到，開啟音頻弱網雙發政策後，線上的音頻卡頓率有了明顯的下降，且性能名額幾乎不受影響。
下面兩段視訊可以讓我們更直覺地感受到開啟弱網雙發對使用者音視訊體驗的提升效果（模拟 50% 丢包網絡環境，上方為本地實時采集畫面，下方為對端傳輸畫面）。
，時長00:10
開啟弱網雙發，對端地球儀和本地一樣運轉流暢
，時長00:10
關閉弱網雙發，對端地球儀明顯運轉卡頓
4. 未來展望
以上是多鍊路傳輸技術在火山引擎 RTC 的演進和實踐。
不過，上文提到的兩種多鍊路設計方式均是在連接配接底層實作的多鍊路傳輸模式，這種多鍊路傳輸模式對于上層的子產品完全透明，上層的擁塞控制、重傳、FEC、PACER、編解碼等子產品，并不“知道”底層是單鍊路還是多鍊路的傳輸模式，是以會帶來兩個問題：
（1）上層的擁塞控制子產品不感覺底層的鍊路，無法獨立評估每一個鍊路的帶寬和擁塞情況，也就無法根據每個鍊路的品質來更精确的配置設定資料；
（2）資料的備援發送在連接配接層實作，連接配接層無法感覺資料更多的屬性，也就無法實作更豐富的傳輸政策，比如如果我們隻想用備用鍊路來傳輸關鍵幀、FEC 等資料，上面兩種架構就較難實作這種政策。
未來，我們還會使用一種更進階的架構來代替弱網備援傳輸架構，并持續優化音頻、視訊的多鍊路傳輸政策，做到使用最小的額外帶寬和功耗，最大限度地提升使用者的音視訊通話體驗。
加入我們
火山引擎 RTC，緻力于提供全球網際網路範圍内高品質、低延時的實時音視訊通信能力，幫助開發者快速建構語音通話、視訊通話、互動直播、轉推直播等豐富場景功能，目前已覆寫互娛、教育、會議、遊戲、汽車、金融、IoT 等豐富實時音視訊互動場景，服務數億使用者。