基于鏈路狀態的OpenWRT多路并行傳輸系統的設計

摘 要：針對傳統的單一鏈路傳輸無法滿足流媒體業務高帶寬、低延時需求的問題，基于流媒體傳輸協議SRT在OpenWRT系統上實現了多路并行傳輸，并提出了一種基于鏈路狀態的數據分流算法。該算法根據服務器端反饋的鏈路信息確定鏈路的狀態，按照每條鏈路的狀態分配相應的傳輸任務量，并且在服務端實現分流合并，可以有效降低數據包的端到端時延，并提高系統傳輸的穩定性。實驗結果表明：采用該多路并行傳輸系統進行傳輸時，數據包的端到端時延比單一鏈路更加穩定并且平均時延降低50%左右，系統的吞吐量也明顯提高，能夠較好地保證負載均衡，并且在OpenWRT系統下實現了更有利于實際業務的部署。

關鍵詞：多路并行傳輸；數據調度；鏈路狀態；分流合并；SRT協議；OpenWRT系統

中圖分類號：TP39；TN915.04 文獻標識碼：A 文章編號：2095-1302（2025）01-00-05

0 引 言

隨著信息技術的發展，高清視頻直播、AI全場景、遠程醫療、無人駕駛等新興業務不斷興起，它們都有嚴格的服務質量（QoS）要求，需要對大量的實時視頻數據進行快速、可靠的傳輸，這都給單一鏈路傳輸方式帶來了極大的負擔，傳統的流媒體傳輸協議已經無法滿足新興業務對于低時延、高可靠的要求。

傳統的傳輸層協議TCP和UDP并不支持多路并行傳輸技術，為了解決該問題，國際互聯網工程任務組于2013年提出了MPTCP（Multi-Path TCP）協議[1]，它通過擴展傳統的TCP連接來實現多路徑傳輸，允許同一個基于TCP的應用程序建立多個TCP連接并同時進行通信，但是該協議在擁塞控制、數據調度和路徑選擇等方面還有許多不足之處[2]，這些都會影響鏈路帶寬的利用率，從而造成時延的增大，因此想要廣泛部署MPTCP也面臨著重大阻礙[3]。標準化組織IETF提出了流控制傳輸協議（Stream Control Transmission Protocol， SCTP）[4]，它允許在端到端之間使用多個可用的IP地址實現多路的特性。但在SCTP的主要版本中，多個路徑仍然只作為主路徑的備份路徑存在[5]。針對SCTP協議存在的不足，文獻[6]中對SCTP協議做出了修改，提出了一種可支持多路徑并行傳輸的CMT協議，此協議支持源端到目的端之間同時存在多條路徑傳輸數據，提高了傳輸速率并充分利用了多種網絡資源，為多路徑并行傳輸提供了協議上的保障[7]，但是該協議并不兼容現有網絡和應用。SRT（Secure Reliable Transport）協議是由Haivision和Wowza共同開發的安全可靠協議，該協議具有安全可靠以及低時延的特點，并且它還針對音視頻數據流作了特別優化，適合在互聯網這種不可預知的網絡中實時傳輸數據[8-9]，但是該協議目前并不支持多路并行傳輸技術。OpenWRT是一個嵌入式的GNU/Linux發行版，擁有豐富的網絡組件和良好的可擴展性，可以作為一個多功能、易于修改的路由操作系統[10]。因此在該協議上進行多路并行傳輸的研究并將其部署在OpenWRT系統中是一個全新的方向。

1 系統總體設計

本文的多路并行傳輸系統的總體設計如圖1所示，其主要分為客戶端和服務端2部分。客戶端與服務端的端到端是通過綁定的源和目的IP地址進行連接的。客戶端將原始的YUV視頻序列編碼，根據服務端反饋的鏈路信息進行信息處理后，決策每條鏈路的狀態；根據本文所提出的基于鏈路狀態的分流算法進行速率分配，從而實現客戶端的數據分流，數據包再經過無線通信鏈路傳輸到服務端；服務端接收到對端的數據包后，會將數據包按照其包號映射至G_Buf中，然后根據G_Buf中的數據包號進行數據包的排序，從而遞交給上層應用進行視頻解碼播放。

2 多鏈路設計

SRT協議具有多流的特性，能夠在端到端之間創建多個可用的IP地址來進行數據傳輸，但該模式下一次只有一條路徑用于數據傳輸，而其他路徑處于備用狀態，以確保在主鏈路發生故障時傳輸仍能繼續。針對SRT協議存在的不足，本文在其基礎上實現了多鏈路的初始化，然后根據多路ACK（Acknowledgement）、ACK-ACK以及NAK（Negative Acknowledgement）的反饋確定鏈路組內的鏈路狀態，再進行數據包的分流發送以及數據包的重傳，最后進行數據包的接收合并，并遞交給上層應用進行解碼播放。

2.1 多鏈路的初始化

鏈路組的概念是可以有多條鏈路歸屬于一個組，使得應用程序可以將操作發送到一個鏈路組，而不必逐個處理每條鏈路。同時，鏈路組還可以實現數據流的負載均衡和容錯機制，以提高數據傳輸的穩定性和可靠性。

多路徑的初始化過程如圖2所示。

客戶端創建一個鏈路組ID，然后創建每條鏈路的ID對應的IP地址并加入組中，通過對組的操作來管理組內的成員鏈路，組內成員向對端發送握手包進行連接，服務端通過設置的G_CONNECT標志位與客戶端建立組連接，通過該標志位客戶端和服務端進行多路傳輸，否則，雙方進行單路傳輸；服務端在握手成功后根據客戶端地址和自身密鑰生成一個cookie，然后將cookie送回客戶端，后續客戶端請求需要附帶該cookie進行參數通告，服務端對相應參數進行響應后即可進行數據包的傳輸，從而實現多鏈路的初始化。

2.2 多路ACK、NAK以及重傳定時器

多路ACK機制用于確認不同鏈路接收到的數據包。在多路傳輸中，每條鏈路都負責對應鏈路數據包ACK的傳輸，并且為了讓每條鏈路保持連接狀態，服務端每10 ms會回復一個ACK，通知對端已經接收到該數據包，組內成員在收到ACK消息后則將數據包從對應緩沖區中移除，并向對端發送ACK包通知對端已成功接收到該數據包。

多路NAK機制用于指示客戶端需要重傳的數據包。服務端通過向客戶端發送周期NAK報告來實現數據包的重傳，該周期NAK報告的發送周期一般為往返時延的一半，這個周期的設定主要是為了減少NAK包在鏈路中丟失造成反饋不及時的情況，并且鏈路組可根據該報告以及組內成員的鏈路狀態進行重傳數據包的分配。

多路重傳定時器用于檢查是否需要重傳未被確認的數據包。當鏈路組每發送一個數據包時，會啟動一個針對該數據包的重傳定時器。定時器的時長由重傳超時時間（Retransmission Timeout， RTO）決定，RTO的值通常根據網絡延遲和連續丟包數等因素進行調整，將重傳超時時間RTO表示為：

（1）

（2）

（3）

（4）

式中：Crexmit表示自上次收到ACK后重傳的數據包個數；Ttimeout表示初始的重傳超時時間；Tsyn_interval表示同步時間間隔，一般為10 ms；RTTvar為RTT方差。當服務端收到對端反饋的ACK消息時，可以根據最新測量到的往返時延RTTnew更新實際的RTT以及RTTvar。

客戶端鏈路組會根據周期性NAK報告構建一個丟失數據包列表用于重傳，當進行傳輸時，客戶端會查看丟失列表中的數據包是否具有優先級，并根據組內鏈路狀態將其發送。當丟失列表中的數據包數量達到一定閾值時，客戶端就會在擁塞窗口未滿之前快速重傳這些未確認的數據包，以避免在擁塞窗口滿時觸發超時重傳機制，從而減少實時數據流的抖動和延遲。上述3種定時器模型如圖3所示。

3 多路分流與接收的實現

本文所實現的多路并行傳輸系統的主要目標是對傳統的單一鏈路進行擴展，以實現實時視頻的多路并行傳輸。因此，提出了一種基于鏈路狀態的分流策略，保證了該多路傳輸系統的穩定性以及低延時性，并提高了該系統的吞吐量。

3.1 鏈路狀態切換

鏈路組根據組內每條鏈路的狀態進行數據的分流發送，其中每條鏈路的狀態由服務端的響應時間所決定。將鏈路狀態分為6個等級，鏈路狀態從好到差依次為q0、q1、q2、q3、q4、q5，見表1。

當客戶端與服務端建立連接后，組內鏈路狀態為Idle，這時鏈路組將激活組內成員進行數據傳輸，并記錄每條鏈路從Idle切換到Fresh-Activated的時間為Tactivated；鏈路被激活后會進入探測周期進行鏈路狀態的探測和穩定性判斷，其探測周期Tprobing定義如下：

（5）

" （6）

式中：Tilst表示初始鏈路穩定性超時時間；τ為常數，可根據不同傳輸業務進行相應修改；Tlstm表示鏈路穩定性超時最小值，可根據不同傳輸業務進行設置；Tlantancy表示客戶端與服務端所設置的共同延時量。

在該探測周期內，組內成員從服務端接收到最新響應（ACK、NAK、定期 NAK報告、KEEP_ALIVE 消息或者數據包）的時間與上次接收響應的時間間隔Tinterval大于鏈路穩定性超時值Tlst時，鏈路狀態將會切換到Unstable；反之，該探測周期結束后，鏈路狀態將會切換到Stable，其中Tlst的定義如下：

（7）

Tlstm ≤ Tlst ≤ Tlantancy （8）

當鏈路狀態維持在Stable期間，如果 Tinterval≥Tlst，則該鏈路狀態會切換到Unstable。鏈路狀態處在Unstable期間，如果Tintervallt;Tlst，則會立即切換到Unstable-Wary；進入到Unstable-Wary狀態時，鏈路組會對當前鏈路進行一個周期的探測，該周期結束后會進入到Stable，在這期間如果Tinterval≥Tlst，則鏈路狀態還會回到Unstable，所以Unstable-Wary作為一個從Unstable到Stable的臨界值，表示該鏈路仍有切換到Stable的機會。當鏈路狀態維持在Unstable和Unstable-Wary且Tu_stable、Tu_wary超過5 s未收到對端響應時，都會切換為Broken狀態，其鏈路切換狀態機如圖4所示。

3.2 數據包分配

鏈路組根據組內成員鏈路的狀態進行數據包的分配，若鏈路狀態為同一等級，按鏈路數量等額分配數據包；若鏈路狀態判定為不同等級，采用差額速率分配數據包；若鏈路狀態判定為q3、q4、q5時，則該鏈路不會承擔數據傳輸的任務；當鏈路狀態被判定為q2時，鏈路性能歸一化速率vx表示為：

" （9）

式中：l0、l1、l2 分別表示等級為q0、q1、q2的鏈路數量；w表示鏈路等級所對應的權重。若鏈路等級最低被判定為q1時，鏈路性能歸一化速率vx表示為：

（10）

為保證每條鏈路數據的傳輸速率和系統傳輸的可靠性，客戶端需要根據上述速率分配原則進行數據包的分流發送，并且當其中一條鏈路出現故障變得不穩定或是直接斷開連接時，客戶端則需要進行數據調度，將分發在異常鏈路的數據包重新分配到其他狀態良好的鏈路中。例如：在客戶端和服務端直接建立3條并行連接，其狀態等級分別為q0、q1和q2。在數據傳輸過程中，若狀態等級為q2的鏈路發生異常，發送端會將其數據分配到其他鏈路上。在鏈路正常情況下，各鏈路按照式（11）的原則分配速率：

（11）

式中：V0表示等級為q0的分配速率；V1表示等級為q1的分配速率；V2表示等級為q2的分配速率。

當鏈路等級q2切換為q3或q5時，等級為q0、q1的鏈路歸一化傳輸速率為：

（12）

式中：V' 0 表示等級為q0鏈路的實時分配速率；V1'表示等級為q1鏈路的實時分配速率。

此時，q0和q1兩條鏈路可以快速重傳鏈路q2由于異常所未能發送的數據包。因此，根據該數據調度分配方法，可以減少異常鏈路的丟包，從而提高系統傳輸的可靠性。

3.3 鏈路狀態分流算法

綜上所述，鏈路狀態分流算法的實現流程如下：

輸入：Tprobing、Tlst、Tinterval，鏈路數量li∈[0， n]，n為鏈路總數

輸出：鏈路狀態qi，鏈路分配速率vqi

while（客戶端與服務端建立鏈路數量li）

n條鏈路建立連接成功并激活， qi=ql ;

if（Tprobing結束）

qi=q0;

else if（qi=q3amp;amp;Tintervallt;Tlst）

qi=q2;

else

qi切換到對應狀態;

for（li）

if（qi∈（q3， q4， q5））

continue;

end if

if（qi∈（q0， q1， q2））

vqi依照式（9）、式（10）進行速率分配；

while（qi∈（q0， q1， q2）→ （q3， q4， q5））

vqi依照式（11）、式（12）進行速率分配；

end while

end if

end for

end while

3.4 接收合并

由于每條鏈路建立連接時第一個數據包的初始序列號（Initial Sequence Number， ISN）會出現重復的問題，導致服務端在收到不同鏈路的數據包時會將其判定為相同報文，從而進行丟包處理。為解決這個問題，采用了一種以數據包序號為標志進行服務端分流合并的方法。該方法在將接收隊列中的數據包存入緩沖區的同時會將該數據包的序號映射至G_Buf數組中，并持續監聽該數組是否有最新的數據包到達接收緩沖區。一旦有新的數據包到達，將根據數組中的數據包序號，將接收緩沖區中的數據包有序提交給上層應用進行解碼播放，從而實現服務端的數據合并，其處理流程如圖5所示。通過這種方式，可以有效處理重復報文問題，確保數據在服務端被正確有序地合并和處理。

4 實驗與分析

本文使用Windows系統的主機作為宿主機，并安裝一個Ubuntu系統的虛擬機對OpenWRT進行功能定制和固件編譯；然后將生成的固件通過燒錄器寫進軟路由；最后再通過交叉編譯工具鏈將多路SRT移植到軟路由中。

4.1 實驗環境搭建

實驗測試選用HoloWan網絡仿真儀[11]來模擬多條5G鏈路真實網絡環境，客戶端利用FFmpeg進行編碼和推流，服務端利用4KH.264視頻解碼板進行解碼播放。網絡拓撲如圖6所示。客戶端OpenWRT軟路由通過2個WAN口連接到仿真儀，由于該仿真儀只具備一個網絡接口并需要設置在同一網段下，故通過新增一個路由器以及交換機進行IP地址轉換；然后在仿真儀中分別設置2條路徑的網絡參數；最終在服務端的OpenWRT軟路由中進行數據的接收與合并，再遞交給解碼器進行解碼播放。為了獲得相對客觀的統計結果，本文使用了4個不同場景的YUV序列進行測試，分辨率均為1 080P。

4.2 實驗結果與分析

本文選取端到端時延、吞吐量作為性能評價指標。端到端時延是指數據包從客戶端到服務端的總傳輸時間。網絡吞吐量是指單位時間內在網絡中成功傳輸的字節數。

圖7和圖8分別展示了不同視頻序列在多路SRT與單路SRT傳輸下的平均端到端時延以及Dinner序列下瞬時端到端時延的對比。可以看出，單路SRT的平均端到端時延是多路SRT的2倍左右，并且單路SRT的瞬時端到端時延波動更加明顯，而多路SRT的瞬時端到端時延相對比較平穩，沒有出現太大波動。這是由于多路SRT在其中一條路徑出現故障，且網絡狀況不穩定時，可以根據本文的分流算法將該路徑的數據包分配到其他狀態良好的鏈路進行傳輸，從而減少數據包的重傳以及到達對端的時間。為了直觀顯示瞬時端到端時延分布，圖9展示了Dinner序列下瞬時端到端時延的CDF圖，可以觀察到多路SRT數據包的準時到達率明顯高于單路SRT。

圖10展示了多路SRT和單路SRT在傳輸Dinner視頻序列時的吞吐量對比。在網絡鏈路負載低且無擁塞產生時，多路SRT的吞吐量增長明顯快于單路SRT，并且隨著鏈路負載的增加或者出現擁塞，單路SRT相比多路SRT的吞吐量出現明顯下降。因此在多路SRT中，通過對單一路徑的擴展以及基于鏈路狀態的分流策略，可以有效減少鏈路出現擁塞的現象，提高系統的吞吐量以及穩定性。

5 結 語

為了滿足如今許多流媒體業務對于高帶寬、低時延的要求，本文在SRT協議的基礎上，實現多鏈路的初始化，引入多路ACK、NAK以及數據包重傳機制，并根據對端反饋的鏈路信息確定鏈路狀態，提出了一種基于鏈路狀態的數據分流算法。客戶端根據該算法能夠實時調整分流策略，實現鏈路的負載均衡，在服務端進行數據包的有序合并，能夠有效減少數據包的亂序數量。該算法解決了單一鏈路傳輸時的鏈路帶寬和數據包的端到端時延問題，適用于實時音視頻傳輸。將該系統移植到OpenWRT軟路由中，更有利于其部署在真實應用場景中。

參考文獻

[1] COMINCK Q D， BAERTS M， HESMANS B， et al. Observing real smartphone applications over multipath TCP [J]. IEEE communications magazine， 2016， 54（3）： 88-93.

[2] HURTIG P， GRINNEMO K J， BRUNSTROM A， et al. Low-latency scheduling [J]. IEEE/ACM transactions on networking， 2019， 27（1）： 302-315.

[3] ADARSH V， SCHMITT P， BELDING E. Performance over heterogenous subpaths [C]//2019 28th International Conference on Computer Communication and Networks （ICCCN）. Valencia， Spain： [s.n.]， 2019： 1-9.

[4] FU S， ATIQUZZAMAN M. SCTP： State of the art in research， products， and technical challenges [J].IEEE communications magazine， 2004， 42（4）： 64-76.

[5] MA L， YU F R， LEUNG V C M. Performance improvements of mobile SCTP in integrated heterogeneous wireless networks [J]. IEEE transactions on wireless communications， 2007， 6（10）： 3567-3577.

[6] IYENGAR J， AMER P， STEWART R. Concurrent multipath transfer using SCTP multihoming over independent end-to-end paths [J]．IEEE / ACM transactions on networking， 2006， 14（5）： 951-964.

[7] BECKE M， ADHARI H， RATHGEB E P， et al. Comparison of multipath TCP and CMT-SCTP based on intercontinental measurements [C]//2013 IEEE Global Communications Conference （GLOBECOM）. [S.l.]： IEEE， 2013： 1360-1366.

[8]葛寶堯. 基于SRT協議的流媒體傳輸系統的研究與實現[D].西安：西安電子科技大學，2021.

[9]張博力.安全可靠傳輸（SRT）協議在5G直播中的鏈路分析和部署策略[J].廣播與電視技術，2021，48（1）：58-62.

[10]曹為華，凌強，張雷，等.基于OpenWrt系統路由器的模式切換與網頁設計[J].微型機與應用，2015，34（23）：91-94.

[11] MSY Company. HoloWAN simulator [EB/OL]. （2018-12-29）. http： //www.msytest. cn.