久久国产精品一区二区三区四区,久色婷婷小香蕉久久,国产日韩欧美在线播放不卡,另类av一区二区

傳統的數據傳輸方式大多是利用一個鏈路、選擇設備的默認網卡進行傳輸，使用這種方式實現實時音視頻通話時，如果默認網絡出現問題（如斷網、弱網等），用戶的通信就會發生中斷或者卡頓，影響用戶體驗。

多鏈路傳輸，顧名思義，就是使用多個鏈路進行傳輸數據的一種技術。近年來，單設備上支持多個可用網卡的技術越來越普遍，比如我們的手機就同時支持無線網卡和 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. 多鏈路傳輸技術的實踐與收益

目前，弱網雙發已經在飛書會議、抖音社交等業務上線，以下是抖音社交業務開啟弱網雙發后較對照組的表現：

可以看到，開啟音頻弱網雙發策略后，線上的音頻卡頓率有了明顯的下降，且性能指標幾乎不受影響。

4. 未來展望

以上是多鏈路傳輸技術在火山引擎 RTC 的演進和實踐。

不過，上文提到的兩種多鏈路設計方式均是在連接底層實現的多鏈路傳輸模式，這種多鏈路傳輸模式對于上層的模塊完全透明，上層的擁塞控制、重傳、FEC、PACER、編解碼等模塊，并不“知道”底層是單鏈路還是多鏈路的傳輸模式，因此會帶來兩個問題：

（1）上層的擁塞控制模塊不感知底層的鏈路，無法獨立評估每一個鏈路的帶寬和擁塞情況，也就無法根據每個鏈路的質量來更精確的分配數據；

（2）數據的冗余發送在連接層實現，連接層無法感知數據更多的屬性，也就無法實現更豐富的傳輸策略，比如如果我們只想用備用鏈路來傳輸關鍵幀、FEC 等數據，上面兩種架構就較難實現這種策略。

未來，我們還會使用一種更進階的架構來代替弱網冗余傳輸架構，并持續優化音頻、視頻的多鏈路傳輸策略，做到使用最小的額外帶寬和功耗，最大限度地提升用戶的音視頻通話體驗。

加入我們

火山引擎 RTC，致力于提供全球互聯網范圍內高質量、低延時的實時音視頻通信能力，幫助開發者快速構建語音通話、視頻通話、互動直播、轉推直播等豐富場景功能，目前已覆蓋互娛、教育、會議、游戲、汽車、金融、IoT 等豐富實時音視頻互動場景，服務數億用戶。

關鍵詞：