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

關(guān)鍵詞：多路并行傳輸；數(shù)據(jù)調(diào)度；鏈路狀態(tài)；分流合并；SRT協(xié)議；OpenWRT系統(tǒng)

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

0 引 言

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

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

1 系統(tǒng)總體設(shè)計

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

2 多鏈路設(shè)計

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

2.1 多鏈路的初始化

鏈路組的概念是可以有多條鏈路歸屬于一個組，使得應(yīng)用程序可以將操作發(fā)送到一個鏈路組，而不必逐個處理每條鏈路。同時，鏈路組還可以實現(xiàn)數(shù)據(jù)流的負載均衡和容錯機制，以提高數(shù)據(jù)傳輸?shù)姆€(wěn)定性和可靠性。

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

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

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

多路ACK機制用于確認不同鏈路接收到的數(shù)據(jù)包。在多路傳輸中，每條鏈路都負責對應(yīng)鏈路數(shù)據(jù)包ACK的傳輸，并且為了讓每條鏈路保持連接狀態(tài)，服務(wù)端每10 ms會回復一個ACK，通知對端已經(jīng)接收到該數(shù)據(jù)包，組內(nèi)成員在收到ACK消息后則將數(shù)據(jù)包從對應(yīng)緩沖區(qū)中移除，并向?qū)Χ税l(fā)送ACK包通知對端已成功接收到該數(shù)據(jù)包。

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

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

（1）

（2）

（3）

（4）

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

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

3 多路分流與接收的實現(xiàn)

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

3.1 鏈路狀態(tài)切換

鏈路組根據(jù)組內(nèi)每條鏈路的狀態(tài)進行數(shù)據(jù)的分流發(fā)送，其中每條鏈路的狀態(tài)由服務(wù)端的響應(yīng)時間所決定。將鏈路狀態(tài)分為6個等級，鏈路狀態(tài)從好到差依次為q0、q1、q2、q3、q4、q5，見表1。

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

（5）

" （6）

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

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

（7）

Tlstm ≤ Tlst ≤ Tlantancy （8）

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

3.2 數(shù)據(jù)包分配

鏈路組根據(jù)組內(nèi)成員鏈路的狀態(tài)進行數(shù)據(jù)包的分配，若鏈路狀態(tài)為同一等級，按鏈路數(shù)量等額分配數(shù)據(jù)包；若鏈路狀態(tài)判定為不同等級，采用差額速率分配數(shù)據(jù)包；若鏈路狀態(tài)判定為q3、q4、q5時，則該鏈路不會承擔數(shù)據(jù)傳輸?shù)娜蝿?wù)；當鏈路狀態(tài)被判定為q2時，鏈路性能歸一化速率vx表示為：

" （9）

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

（10）

為保證每條鏈路數(shù)據(jù)的傳輸速率和系統(tǒng)傳輸?shù)目煽啃裕蛻舳诵枰鶕?jù)上述速率分配原則進行數(shù)據(jù)包的分流發(fā)送，并且當其中一條鏈路出現(xiàn)故障變得不穩(wěn)定或是直接斷開連接時，客戶端則需要進行數(shù)據(jù)調(diào)度，將分發(fā)在異常鏈路的數(shù)據(jù)包重新分配到其他狀態(tài)良好的鏈路中。例如：在客戶端和服務(wù)端直接建立3條并行連接，其狀態(tài)等級分別為q0、q1和q2。在數(shù)據(jù)傳輸過程中，若狀態(tài)等級為q2的鏈路發(fā)生異常，發(fā)送端會將其數(shù)據(jù)分配到其他鏈路上。在鏈路正常情況下，各鏈路按照式（11）的原則分配速率：

（11）

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

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

（12）

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

此時，q0和q1兩條鏈路可以快速重傳鏈路q2由于異常所未能發(fā)送的數(shù)據(jù)包。因此，根據(jù)該數(shù)據(jù)調(diào)度分配方法，可以減少異常鏈路的丟包，從而提高系統(tǒng)傳輸?shù)目煽啃浴?/p>

3.3 鏈路狀態(tài)分流算法

綜上所述，鏈路狀態(tài)分流算法的實現(xiàn)流程如下：

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

輸出：鏈路狀態(tài)qi，鏈路分配速率vqi

while（客戶端與服務(wù)端建立鏈路數(shù)量li）

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

if（Tprobing結(jié)束）

qi=q0;

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

qi=q2;

else

qi切換到對應(yīng)狀態(tài);

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 接收合并

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

4 實驗與分析

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

4.1 實驗環(huán)境搭建

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

4.2 實驗結(jié)果與分析

本文選取端到端時延、吞吐量作為性能評價指標。端到端時延是指數(shù)據(jù)包從客戶端到服務(wù)端的總傳輸時間。網(wǎng)絡(luò)吞吐量是指單位時間內(nèi)在網(wǎng)絡(luò)中成功傳輸?shù)淖止?jié)數(shù)。

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

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

5 結(jié) 語

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

參考文獻

[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協(xié)議的流媒體傳輸系統(tǒng)的研究與實現(xiàn)[D].西安：西安電子科技大學，2021.

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

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

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