包嘉琪，胡 暢，趙國強(qiáng)，黃俊杰，崔傲疊

（武漢紡織大學(xué) 計(jì)算機(jī)與人工智能學(xué)院，湖北 武漢 430200）

0 引言

2020 年Cisco 的年度互聯(lián)網(wǎng)報(bào)告顯示，視頻流是互聯(lián)網(wǎng)流量的主要部分，預(yù)計(jì)占2022 年全球視頻總流量的82%［1］。5G 的快速發(fā)展，為網(wǎng)絡(luò)創(chuàng)造了高帶寬、低時(shí)延的環(huán)境，但由于多種因素影響，如何保證良好的用戶體驗(yàn)質(zhì)量（Quality of Experience，QoE）仍是一項(xiàng)具有挑戰(zhàn)性的任務(wù)，尤其是對傳輸QoE 敏感的應(yīng)用，例如音視頻傳輸、在線游戲等。

MPTCP（Multipath TCP）作為TCP 的擴(kuò)展，被廣泛運(yùn)于不同領(lǐng)域，是目前主流的傳輸協(xié)議。該協(xié)議可聚合多條路徑的帶寬提升網(wǎng)絡(luò)應(yīng)用程序性能。在實(shí)際傳輸過程中，TCP 為了保證數(shù)據(jù)的可靠性會(huì)按照順序傳輸數(shù)據(jù)，當(dāng)某一個(gè)數(shù)據(jù)包過大時(shí)，后面的數(shù)據(jù)需要等待該數(shù)據(jù)成功傳輸至應(yīng)用層后才能組裝成完整的數(shù)據(jù)，也可能由于某一個(gè)數(shù)據(jù)包因網(wǎng)絡(luò)中斷或傳輸過程中丟失，只能在重新傳輸后才能繼續(xù)后續(xù)步驟，然而一旦發(fā)生上述問題將導(dǎo)致視頻流傳輸發(fā)生明顯卡頓，影響用戶觀看體驗(yàn)。因此，TCP 不適用于能容忍少量丟包的流媒體服務(wù)。

此外，MPTCP 的使用前提需要用戶設(shè)備配備多宿主接口，系統(tǒng)內(nèi)核需要更新以支持MPTCP，對于流媒體服務(wù)而言部署代價(jià)較大。為此，本文提出了一種新的傳輸協(xié)議快速UDP Internet 連接（Quick UDP Internet Connection，QUIC），設(shè)計(jì)了一種針對視頻流的基于SDN 的分段路由多路徑QUIC 傳輸框架（SDNMQS），以提高流媒體的傳輸性能。

1 相關(guān)研究

1.1 QUIC

QUIC 相較于TCP 進(jìn)行了多項(xiàng)改進(jìn)，例如基于UDP 設(shè)計(jì)了多路復(fù)用的操作，不存在隊(duì)頭阻塞情況。如圖1 所示，在一條QUIC 連接上可發(fā)送多個(gè)請求（Stream），Stream間相互獨(dú)立，Stream2 丟失了一個(gè)Pakcet，不會(huì)影響Stream3、Stream4，如此可有效解決視頻卡頓問題，提升音視頻資源的訪問效率［2］。

QUIC 還有一個(gè)顯著特征是0RTT 連接，如圖2 所示。QUIC 從請求連接到正式接發(fā)送HTTP 數(shù)據(jù)一共消耗1 個(gè)往返時(shí)延（Round-Trip Time，RTT）以獲取Server Config，后續(xù)連接如果客戶端緩存了Server Config 就可直接發(fā)送HTTP 數(shù)據(jù)，建立0RTT 連接，對于視頻傳輸而言首幀更快、延遲更小。此外，QUIC 屬于用戶態(tài)協(xié)議，無需更新內(nèi)核即可進(jìn)行修改，進(jìn)一步提升了QUIC 的可擴(kuò)展性，還可靈活調(diào)整可靠傳輸機(jī)制、擁塞控制算法等。

Fig.2 TCP connection establishment and QUIC connection establishment圖2 TCP建立連接和QUIC建立連接

2022 年，IETF QUIC 和HTTP 工作組成員Robin Mark在推特上正式發(fā)布基于QUIC 協(xié)議的HTTP/3，標(biāo)志著QUIC將有可能為互聯(lián)網(wǎng)數(shù)據(jù)傳輸打開新局面。多路徑QUIC（Multipath QUIC，MPQUIC）通過多個(gè)網(wǎng)絡(luò)路徑組成一個(gè)QUIC 連接傳輸數(shù)據(jù)，但協(xié)議標(biāo)準(zhǔn)目前只規(guī)定了多路徑實(shí)現(xiàn)的機(jī)制，而多路徑調(diào)度需要額外單獨(dú)實(shí)現(xiàn)。因此，如何合理調(diào)度多路徑QUIC 數(shù)據(jù)包，為用戶提供一個(gè)高帶寬、低時(shí)延的網(wǎng)絡(luò)環(huán)境仍需時(shí)間進(jìn)行解決。

由于新型網(wǎng)絡(luò)架構(gòu)軟件定義網(wǎng)絡(luò)（Software Defined Network，SDN）具有靈活性、可管理性及對流量需求快速變化的響應(yīng)性［3］。因此，在多路徑QUIC 傳輸中根據(jù)網(wǎng)絡(luò)條件，可通過SDN 控制器合理分配每個(gè)MPQUIC 子流，但在多路徑場景中多媒體流被劃分為多個(gè)子流，將每個(gè)子流視為一個(gè)獨(dú)立數(shù)據(jù)流并在數(shù)據(jù)平面單獨(dú)傳遞，將顯著增加存儲(chǔ)在SDN 交換機(jī)轉(zhuǎn)發(fā)條目的數(shù)量及SDN 控制器和交換機(jī)的負(fù)載。為了解決該問題，F(xiàn)ilsfils 等［4］提出一種源路由方法——分段路由（SR），將路由信息以有序的標(biāo)簽列表形式編碼到數(shù)據(jù)包頭部中，以此極大減少網(wǎng)絡(luò)節(jié)點(diǎn)中的轉(zhuǎn)發(fā)規(guī)則數(shù)量。

綜上，針對用戶在線觀看視頻的應(yīng)用場景，本文設(shè)計(jì)了一種具有分段路由的軟件定義網(wǎng)絡(luò)多路徑QUIC 傳輸框架（SDNQMS），為視頻流提供高效的路由分配，并提出多路徑QUIC 路由算法，通過分段路由合理分配路徑以提升網(wǎng)絡(luò)吞吐量和視頻傳輸質(zhì)量，在SDN 網(wǎng)絡(luò)中利用MPQUIC和分段路由為用戶提供高質(zhì)量的視頻流傳輸。

從流量工程（Traffic Engineering，TE）角度而言，采用集中式SDN 控制器可根據(jù)可用網(wǎng)絡(luò)資源智能分配多條不相交的路徑以平衡流量負(fù)載，提升網(wǎng)絡(luò)資源利用率。從用戶體驗(yàn)質(zhì)量角度而言，根據(jù)實(shí)時(shí)網(wǎng)絡(luò)條件動(dòng)態(tài)控制子流、分配路徑，能有效減少數(shù)據(jù)包混亂的情況，提升了視頻傳輸?shù)馁|(zhì)量。

此外，為了優(yōu)化視頻內(nèi)容傳輸鏈，提升終端用戶體驗(yàn)質(zhì)量（Quality of Experience，QoE），學(xué)術(shù)、工業(yè)界專家在SDN 技術(shù)、多路徑傳輸和QUIC 在傳輸領(lǐng)域進(jìn)行了許多研究，取得了一定的效果。

1.2 SDN技術(shù)與多路徑傳輸

Sandri 等［5］提出一種在支持OpenFlow 網(wǎng)絡(luò)中使用MPTCP 的方案，以保證相同MPTCP 連接的子流通過不相交的路徑發(fā)送。Zannettou 等［6］提出一個(gè)MPTCP 感知的SDN 控制器，使用數(shù)據(jù)包檢測為路徑提供確定性子流分配，并優(yōu)化了MPTCP 子流的替代路由機(jī)制。Nam 等［7］使用SDN 動(dòng)態(tài)添加、刪除MPTCP 路徑，以減少大量無序數(shù)據(jù)包，提升了自適應(yīng)速率視頻流的下載速度和用戶體驗(yàn)質(zhì)量。Duan 等［8］提出一種響應(yīng)式的MPTCP 系統(tǒng)，采用集中式SDN 控制器計(jì)算子流的轉(zhuǎn)發(fā)路徑，并在每臺服務(wù)器上運(yùn)行監(jiān)視器來主動(dòng)調(diào)整子流數(shù)量。

雖然上述方法均提升了網(wǎng)絡(luò)吞吐量，但在SDN 交換機(jī)上安裝了更多的流規(guī)則，從而增加了SDN 交換機(jī)的負(fù)載，并且根據(jù)網(wǎng)絡(luò)變化情況缺乏有效的路由和自適應(yīng)機(jī)制控制子流數(shù)量。實(shí)際上，基于SDN 的分段路由可有效管理資源，并在網(wǎng)絡(luò)中提供更好的流量工程（Traffic Engineering，TE）解決方案［9］。例如，李藝等［10］提出在軟件定義網(wǎng)絡(luò)中基于分段路由的多路徑調(diào)度算法，有效提升了網(wǎng)絡(luò)吞吐量，降低了傳輸時(shí)延，同時(shí)具有較低的流表項(xiàng)存儲(chǔ)開銷。

1.3 QUIC傳輸優(yōu)化

國內(nèi)外關(guān)于QUIC 傳輸優(yōu)化的研究較多，但大部分與數(shù)據(jù)包調(diào)度相關(guān)。Vu 等［11］開發(fā)了MPQUIC 流復(fù)用器與MPQUIC 調(diào)度器，利用選擇性多路徑冗余控制實(shí)時(shí)視頻流的尾部損失延遲。Mogensen 等［12］添加了具有嚴(yán)格優(yōu)先級的選擇性數(shù)據(jù)復(fù)制來擴(kuò)展MPQUIC 傳輸協(xié)議，以支持使用無線5G 多UE 設(shè)備的關(guān)鍵應(yīng)用，相較于單路徑連接和最新MPQUIC 協(xié)議傳輸延遲更低。Rabitsch 等［13］認(rèn)為MPQUIC與MPTCP 的區(qū)別在于數(shù)據(jù)傳輸粒度不同，調(diào)度器設(shè)計(jì)應(yīng)考慮流完成時(shí)間，受MPTCP ECF 調(diào)度器［14］啟發(fā)設(shè)計(jì)了流級調(diào)度器，減少了頁面加載時(shí)間（Page Load Time，PLT）的流完成時(shí)間。Shi 等［15］設(shè)計(jì)了一個(gè)考慮路徑帶寬的流級調(diào)度器，基于優(yōu)先級機(jī)制同時(shí)傳輸多個(gè)流。Wang 等［16］通過ACK 快速響應(yīng)來減少PLT，及時(shí)恢復(fù)丟失的數(shù)據(jù)。文獻(xiàn)［14-16］雖然在網(wǎng)絡(luò)應(yīng)用中減少了PLT，但調(diào)度器不適合視頻流場景。為此，李炫杉等［18］針對QUIC 應(yīng)用在實(shí)時(shí)通信場景下的優(yōu)缺點(diǎn)改進(jìn)QUIC 協(xié)議，使QUIC 更適應(yīng)實(shí)時(shí)通信場景，并自適應(yīng)優(yōu)化CUBIC 擁塞控制算法，對改進(jìn)后的QUIC 協(xié)議進(jìn)行應(yīng)用與驗(yàn)證。

近年來，國內(nèi)大型互聯(lián)網(wǎng)公司對QUIC 進(jìn)行了研究與應(yīng)用，快手公司在2019 年結(jié)合自身業(yè)務(wù)特點(diǎn)設(shè)計(jì)了KQUIC 算法［19］，針對短視頻場景對QUIC 進(jìn)行一系列優(yōu)化，但技術(shù)細(xì)節(jié)尚未公布。騰訊公司的騰訊云云計(jì)算負(fù)載平衡業(yè)務(wù)目前已支持使用QUIC 協(xié)議［20］，這也是國內(nèi)首家支持QUIC 協(xié)議的云廠商。

2 系統(tǒng)框架設(shè)計(jì)

2.1 系統(tǒng)總體框架

本文系統(tǒng)框架由管理平面與數(shù)據(jù)平面組成，基于SDN的多路徑QUIC 視頻流傳輸框架（SDNMQS）如圖3 所示。該框架為視頻流服務(wù)提供了有效的管理，并提升了用戶觀看視頻的質(zhì)量。框架并未將子流路徑作為轉(zhuǎn)發(fā)規(guī)則安裝在SDN 的交換機(jī)中，而使用分段路由方法將有序的分段列表配置到入口交換機(jī)的轉(zhuǎn)發(fā)表，以根據(jù)不斷變化的網(wǎng)絡(luò)條件為SDN 網(wǎng)絡(luò)提供多路徑保護(hù)和動(dòng)態(tài)鏈路恢復(fù)機(jī)制，具體工作流程如圖4所示。

Fig.4 SDNMQS framework workflow圖4 SDNMQS框架工作流程

2.2 控制平面

控制平面通過SDN 的擴(kuò)展Ryu 控制器實(shí)現(xiàn)，所有MPQUIC 數(shù)據(jù)包流量均由Ryu 控制器控制。Ryu 控制器由MPQUIC 流量管理器、分段路由模塊、網(wǎng)絡(luò)資源管理、數(shù)據(jù)庫模塊、網(wǎng)絡(luò)拓?fù)涫占骱团渲媚K組成。

2.2.1 網(wǎng)絡(luò)拓?fù)涫占K

該模塊主要監(jiān)控網(wǎng)絡(luò)狀態(tài)，負(fù)責(zé)計(jì)算鏈路帶寬和時(shí)延，特別當(dāng)一個(gè)鏈路或節(jié)點(diǎn)發(fā)生故障時(shí)將這些網(wǎng)絡(luò)信息報(bào)告給SDN 控制器，以便立即采取操作（例如恢復(fù)故障鏈路）。

2.2.2 MPQUIC流量管理器

該模塊計(jì)算最短且連接數(shù)最小的路徑，然后分配子流路徑。為了最大限度減少鏈路擁堵對數(shù)據(jù)傳輸造成的質(zhì)量影響，MPQUIC 模塊采用接入控制，只有所分配的子流速率之和不超過鏈路容量，MPQUIC 子流才能在每個(gè)鏈路上被允許傳輸。與此同時(shí)，MPQUIC 模塊動(dòng)態(tài)控制在入口源節(jié)點(diǎn)產(chǎn)生子流數(shù)量，并根據(jù)收集到的鏈路信息，將資源分配給子流路徑，以滿足用戶觀看體驗(yàn)。

2.2.3 分段路由模塊

控制器將路徑計(jì)算模塊計(jì)算的子流路徑映射到SR 路徑。本文使用文獻(xiàn)［10］提出的算法，在等價(jià)最優(yōu)路徑集合中尋找一條SR 段（SID）數(shù)目最少的路徑，作為該網(wǎng)絡(luò)流的傳輸路徑。例如，給定一個(gè)MPQUIC 客戶端請求的視頻流f，入口節(jié)點(diǎn)為交換機(jī)S1，出口節(jié)點(diǎn)為交換機(jī)S4，那么子流sf1與中間節(jié)點(diǎn){S2，...，SN-1} 的完整路徑為Psf1={S1 →S2 →S3 →S4}，如圖5所示。

該算法將路徑與拓?fù)浣Y(jié)構(gòu)圖作為輸入，映射子流的具體路徑，并將返回段序列作為指定SR 路徑的輸出。具體為，考慮子流路徑的入口節(jié)點(diǎn)S1、出口節(jié)點(diǎn)S4，如果只存在一條最優(yōu)路徑并且等于從S1 到S4 的子流路徑，入口節(jié)點(diǎn)將作為從S1 到S4 的SID 節(jié)點(diǎn)，這個(gè)子流路徑到SR 路徑的映射結(jié)束（見圖5）；當(dāng)發(fā)生映射的最優(yōu)路徑不等于子流路徑或存在多條等價(jià)最優(yōu)路徑時(shí)，可考慮其他節(jié)點(diǎn)段。

2.2.4 配置模塊

該模塊為網(wǎng)絡(luò)資源設(shè)置提供接口，還為終端用戶的QoE 配置提供接口，例如多媒體應(yīng)用流規(guī)則、吞吐量、丟包。

2.2.5 數(shù)據(jù)庫模塊

該模塊將網(wǎng)絡(luò)配置參數(shù)與監(jiān)測狀態(tài)存儲(chǔ)在數(shù)據(jù)庫中，將條目設(shè)置在預(yù)定時(shí)間內(nèi)過期，以便路徑隨流量分布和鏈路故障變化而刷新。當(dāng)SDN 控制器接收到一個(gè)新的MPQUIC 連接子流時(shí)，該模塊首先在數(shù)據(jù)庫中查詢與該MPQUIC 連接相對應(yīng)的現(xiàn)有路徑，如果路徑存在，該子流將被分配到同一MPQUIC 連接先前分配的子流路徑中的一個(gè)特定路徑，否則將使用路徑計(jì)算模塊為該子流計(jì)算新路徑。同時(shí)，新路徑將存儲(chǔ)在數(shù)據(jù)庫中，便于后續(xù)被同一MPQUIC 連接的子流使用，以進(jìn)一步降低SDN 控制器的CPU 利用率。

2.2.6 網(wǎng)絡(luò)資源管理模塊

該模塊實(shí)現(xiàn)了流媒體應(yīng)用相關(guān)的資源分配。為了確保系統(tǒng)整體性能，該模塊既測量延遲、抖動(dòng)、網(wǎng)絡(luò)吞吐量和丟包率等，還執(zhí)行鏈路故障檢測和恢復(fù)機(jī)制，以確保配置、恢復(fù)SDN 網(wǎng)絡(luò)中的任何故障點(diǎn)，從而不影響終端用戶的觀看質(zhì)量。

2.3 數(shù)據(jù)平面

數(shù)據(jù)平面由支持SR 技術(shù)的SDN 交換機(jī)組成，使用有線連接或公共無線信道進(jìn)行互聯(lián)，交換機(jī)分為加載交換機(jī)和轉(zhuǎn)發(fā)交換機(jī)。加載交換機(jī)即SR 路徑中的入口交換機(jī)，負(fù)責(zé)將段序列加載到數(shù)據(jù)包中；轉(zhuǎn)發(fā)交換機(jī)只根據(jù)SR 數(shù)據(jù)包中的頭字段轉(zhuǎn)發(fā)數(shù)據(jù)包。

圖5 為基于SDN 的分段路由操作示例。當(dāng)MPQUIC 客戶端向MPQUIC 服務(wù)器發(fā)送請求時(shí)，SDN 控制器基于網(wǎng)絡(luò)狀況（鏈路延遲和帶寬）計(jì)算傳輸路徑Psf1={S1 →S2 →S3 →S4}，該路徑被映射到入口交換機(jī)S1 并存儲(chǔ)在數(shù)據(jù)包報(bào)頭中，段序列僅由標(biāo)識SR 域目標(biāo)節(jié)點(diǎn)的標(biāo)簽組成，即SL={S4}。然后，SDN 控制器根據(jù)該段序列標(biāo)簽配置入口交換機(jī)S1 的轉(zhuǎn)發(fā)表，一個(gè)子流的數(shù)據(jù)包通過中間節(jié)點(diǎn)從S1 轉(zhuǎn)發(fā)至S4，當(dāng)數(shù)據(jù)包到達(dá)中間節(jié)點(diǎn)時(shí)，頂部標(biāo)簽被彈出。接下來，使用代表下一個(gè)標(biāo)簽的段節(jié)點(diǎn)將數(shù)據(jù)包轉(zhuǎn)發(fā)至目的點(diǎn)，當(dāng)網(wǎng)絡(luò)節(jié)點(diǎn)或鏈路發(fā)生故障時(shí)，SR可支持并提供基于SDN 網(wǎng)絡(luò)的動(dòng)態(tài)流量恢復(fù)。

例如，當(dāng)鏈路S2 →S3 發(fā)生故障時(shí)，網(wǎng)絡(luò)拓?fù)涫占K可通過備份路徑{S1 →S2 →S7 →S8 →S4}重定向流量，在節(jié)點(diǎn)S2 彈出頂部標(biāo)簽，并通過其相鄰的SID 3 將數(shù)據(jù)包傳輸至S7。在S7，數(shù)據(jù)包使用接口2 的鄰接SID 沿著路徑達(dá)到目的地。

2.4 SDN網(wǎng)絡(luò)的多路徑QUIC分配算法

在用戶在線觀看視頻的應(yīng)用場景下，利用SDN 和多路徑QUIC 的優(yōu)勢設(shè)計(jì)算法1，該算法通過多條不相交路徑來路由網(wǎng)絡(luò)流量，提升網(wǎng)絡(luò)資源利用率，保障用戶觀看視頻的質(zhì)量。

算法1多路徑QUIC 路由算法

網(wǎng)絡(luò)拓?fù)鋱DG=(V，E)，V為網(wǎng)絡(luò)中的節(jié)點(diǎn)集合（交換機(jī)），E為節(jié)點(diǎn)間邊的集合（鏈路）。每個(gè)e∈E均與一個(gè)非負(fù)的整數(shù)鏈路權(quán)重相關(guān)，表示為W(e)。在現(xiàn)實(shí)網(wǎng)絡(luò)場景中，鏈路權(quán)重為一個(gè)非固定參數(shù)，受鏈路帶寬、丟包、延遲和鏈路利用率影響，本文利用這些信息計(jì)算從源到目的地的最短路徑最優(yōu)集合，通過bw表示一對節(jié)點(diǎn)的可用鏈路帶寬表示MPQUIC 的一個(gè)子流sf連接到k所需的帶寬，流量需求f從源s∈V到目的地t∈V的最短路徑表示為p(s，t)。

本文將鏈路(i，j)權(quán)重Weij定義為鏈路延遲dlij和丟包率plij值的加權(quán)和，β為比例因子，當(dāng)β較大時(shí)路由對丟包率更敏感，反之路線選擇對延遲更敏感。

為了得到最小成本路由MPQUIC 子流路徑，本文定義了一個(gè)目標(biāo)函數(shù)，如式（2）所示。傳輸連接k的MPQUIC 子流選擇最短路徑中的每條鏈路(i，j)，通過最小成本優(yōu)化視頻質(zhì)量。

通常情況下，一個(gè)視頻流f由子流｛sf1，sf2，...，sfN｝組成，為了路由MPQUIC 連接的子流，本文首先根據(jù)鏈路權(quán)重和網(wǎng)絡(luò)情況尋找網(wǎng)絡(luò)中端點(diǎn)間的最短路徑。在真實(shí)網(wǎng)絡(luò)運(yùn)行環(huán)境中，當(dāng)一條鏈路無法提供所需資源時(shí)可能出現(xiàn)瓶頸問題。為此，本文引入鏈路臨界值lc參數(shù)解決該問題。假設(shè)Pst為MPQUIC 服務(wù)器到MPQUIC 客戶端前h條的最短路徑集合，Pst(c)為鏈路e∈E被包含在前h條最短路徑中的次數(shù)，對于任何一對通信節(jié)點(diǎn)，鏈路e在前h條最短路徑中的出現(xiàn)率可計(jì)算為Pst(c)/h，鏈路e的總預(yù)期負(fù)載可表示為SDN 系統(tǒng)中連接源和目的地所有可能路徑對該鏈路預(yù)期流量需求數(shù)之和。

式中：TD為每個(gè)時(shí)間T內(nèi)記錄并存儲(chǔ)在數(shù)據(jù)庫中的流量需求。

本文通過控制器更新每個(gè)時(shí)間T后的鏈路臨界值，使網(wǎng)絡(luò)負(fù)載均衡。首先，通過鏈路約束條件計(jì)算最短路徑；然后，控制器將這些MPQUIC 子流映射并分配到分段路由的路由表中；最后啟動(dòng)MPQUIC 連接，在視頻流傳輸期間報(bào)告QoE 指標(biāo)。

2.5 SDN網(wǎng)絡(luò)中鏈路恢復(fù)算法

在傳統(tǒng)網(wǎng)絡(luò)中，當(dāng)檢測到鏈路故障時(shí)通常采用回退路由方法，即流量被退回到源節(jié)點(diǎn)，然后從源節(jié)點(diǎn)再次轉(zhuǎn)發(fā)到目標(biāo)節(jié)點(diǎn)。由于路徑長度較長，故障檢測窗口隨之增加，回退路由增加了網(wǎng)絡(luò)恢復(fù)時(shí)間。為避免該問題，本文使用了SR 的路徑保護(hù)和鏈路恢復(fù)機(jī)制新方法，如圖6所示。

Fig.6 Link recovery example圖6 鏈路恢復(fù)示例

當(dāng)鏈路故障時(shí)，檢測到鏈路故障的節(jié)點(diǎn)重新路由數(shù)據(jù)包（見圖6 步驟①），直至尋找到能將數(shù)據(jù)包轉(zhuǎn)發(fā)至目的節(jié)點(diǎn)的新路由路徑。該方法的創(chuàng)新之處在于：首先標(biāo)記MPQUIC 流的相同數(shù)據(jù)包（例如使用包含故障鏈路信息的SR 標(biāo)簽）；然后通過主路徑發(fā)回，在接收到標(biāo)記的數(shù)據(jù)包后（見圖6 步驟②）重新路由節(jié)點(diǎn)（例如S2）；最后將標(biāo)記的數(shù)據(jù)包轉(zhuǎn)發(fā)到其目的節(jié)點(diǎn)（見圖6步驟③）。

當(dāng)重路由節(jié)點(diǎn)處理第一個(gè)標(biāo)記的數(shù)據(jù)包時(shí)，在Open-Flow 交換機(jī)中執(zhí)行狀態(tài)轉(zhuǎn)換，創(chuàng)建故障轉(zhuǎn)移表并安裝備份操作，其中來自源節(jié)點(diǎn)的所有后續(xù)數(shù)據(jù)包在重新路由的節(jié)點(diǎn)上轉(zhuǎn)發(fā)（見圖6）。該方法的優(yōu)點(diǎn)是減少了路徑成本、網(wǎng)絡(luò)恢復(fù)時(shí)間和備份路徑長度。

為了保障在鏈路故障后快速恢復(fù)，必須使用重新計(jì)算的新路由路徑繞過故障鏈路lij。

式中：N為鏈路(i，j)故障后重新計(jì)算的最短路徑集合；Pi為第i條重路由路徑（1 ≤i≤n）；n為鏈路(i，j)故障后重新計(jì)算的路由路徑數(shù)量。

重新計(jì)算的路徑還應(yīng)存在一個(gè)循環(huán)避免約束，如式（5）所示。

當(dāng)SDN 網(wǎng)絡(luò)發(fā)生故障時(shí)，分配給重路由路徑Pi的中斷MPQUIC 流的帶寬不能超過路徑Pi的可用容量。當(dāng)鏈路(i，j)發(fā)生故障時(shí)，使用算法3 修改、更新網(wǎng)絡(luò)拓?fù)?。算?將更新后的網(wǎng)絡(luò)拓?fù)渥鳛檩斎?，并根?jù)公式（1）重新計(jì)算鏈路成本。SDN 控制器計(jì)算MPQUIC 流從s傳輸?shù)絫的最短路徑，然后將MPQUIC 子流路徑psf映射到SR 路徑。當(dāng)客戶端和服務(wù)器建立MPQUIC 連接時(shí)，根據(jù)用戶服務(wù)需求啟動(dòng)子流傳輸，控制器監(jiān)控系統(tǒng)事件和網(wǎng)絡(luò)拓?fù)錉顟B(tài)。具體流程如算法2所示。

算法2故障鏈路恢復(fù)算法

算法3從網(wǎng)絡(luò)拓?fù)渲袆h除故障鏈路的腳本

3.1 實(shí)驗(yàn)環(huán)境搭建與性能分析

3.1 實(shí)驗(yàn)環(huán)境

為了證明本文框架的可行性，使用3 臺Linux 系統(tǒng)（Ubuntu V18.04 LTS）虛擬機(jī)作為實(shí)驗(yàn)平臺。其中一臺安裝了Mininet2.3.0、Ryu4.1.8 控制器和OpenSwitch2.4.0，用于模擬SDN 環(huán)境，另外兩臺作為MPQUIC 服務(wù)器連接到Mininet網(wǎng)絡(luò)上，如圖7所示。

Fig.7 Experimental environment圖7 實(shí)驗(yàn)環(huán)境

由圖7 可見，Mininet 網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)包括邊緣層、聚合層和核心層3 個(gè)層級，分別由8、4、2 個(gè)OpenFlow 交換機(jī)組成，并且邊緣層中每個(gè)交換機(jī)均接入一個(gè)MPQUIC 客戶端，同時(shí)將AStream 作為客戶端的播放器。AStream 是通過Python 編寫的一個(gè)開源虛擬播放器，可模擬視頻播放過程并收集QoE 結(jié)果，例如播放比特率、回退和質(zhì)量切換。

3.2 實(shí)驗(yàn)數(shù)據(jù)集

本文選用Blender 基金會(huì)制作的著名開源動(dòng)畫電影Big Buck Bunny 作為測試視頻，通過多媒體視頻處理工具ffmpeg 5.0.1 的libx265 以1080 p、720 p、480 p 進(jìn)行編碼，視頻編碼率分別為3.473 Mb/s、2.496 Mb/s 和1.536 Mb/s，并且在路徑管理器的配置上限制每個(gè)MPQUIC 連接只能有3 個(gè)MPQUIC 子流，實(shí)驗(yàn)設(shè)置的鏈路參數(shù)如表1所示。

Table 1 List of network link parameters表1 網(wǎng)絡(luò)鏈路參數(shù)列表

視頻從MPQUIC 服務(wù)器到MPQUIC 客戶端重復(fù)傳輸50 次，將本文框架與MPQUIC 在傳統(tǒng)SDN 下的傳輸方式（盡力而為的方式），在吞吐量、故障鏈路恢復(fù)時(shí)間和終端用戶視頻接收質(zhì)量方面進(jìn)行比較。

3.3 實(shí)驗(yàn)結(jié)果與分析

3.3.1 系統(tǒng)吞吐量

50 次傳輸后所取得的平均吞吐量如圖8 所示，具體數(shù)據(jù)如表2 所示。由此可見，本文框架吞吐量均高于MPQUIC 在傳統(tǒng)SDN 下的傳輸方式，原因?yàn)樵趥鬏斠曨l過程中SDNMQS 通過多條不相交的最優(yōu)路徑進(jìn)行傳輸，并在數(shù)據(jù)平面使用無需任何路徑信令的分段路由（SR），因此可選擇最有效的視頻流轉(zhuǎn)發(fā)路徑。

Table 2 Average throughput表2 平均吞吐量（Mb/s）

Fig.8 Throughput of different resolutions圖8 不同分辨率的吞吐量

3.3.2 故障鏈路恢復(fù)時(shí)間

在比較故障鏈路恢復(fù)時(shí)間時(shí)，將本文提出的故障鏈路算法與基于OpenFlow 協(xié)議組表恢復(fù)方法進(jìn)行比較，實(shí)驗(yàn)結(jié)果如圖9 所示。當(dāng)鏈路{S1 →S4}發(fā)生故障時(shí)，由于鏈路{S1 →S4}屬于核心層與匯聚層，交換機(jī)S1 與SDN 控制器的直接連接可極大縮短故障鏈路恢復(fù)時(shí)間。當(dāng)鏈路{S5 →S11}發(fā)生故障時(shí)，由于鏈路{S5 →S11}屬于匯聚層和邊緣層，因此故障恢復(fù)時(shí)間最大。由于OpenFlow 方法恢復(fù)故障只在本地有效，所有流量必須轉(zhuǎn)發(fā)到故障點(diǎn)才能觸發(fā)故障恢復(fù)組表功能，因此延遲時(shí)間過長。本文所提算法相較于基于OpenFlow 協(xié)議組表恢復(fù)方法降低了流表數(shù)量，控制器及時(shí)選擇最優(yōu)路徑進(jìn)行轉(zhuǎn)發(fā)流量，縮短了傳輸時(shí)間。

Fig.9 Fault link recovery time圖9 故障鏈路恢復(fù)時(shí)間

3.3.3 視頻接收質(zhì)量

本文針對視頻質(zhì)量，使用下載吞吐量和視頻碼率間的比率——接收質(zhì)量(ρ)為指標(biāo)［17］。如果ρ＞1，證明該視頻具有良好的接收質(zhì)量，否則質(zhì)量較差。圖10 為不同分辨率視頻流接收的質(zhì)量，由此可見本文所提傳輸框架相較于傳統(tǒng)SDN 傳輸方式，在3 種視頻分辨率下的接收質(zhì)量最好。

Fig.10 Reception quality of different videos圖10 不同視頻接收質(zhì)量

4 結(jié)語

本文針對視頻流傳輸優(yōu)化開展研究，提出了一種基于SDN 的分段路由多路徑QUIC 傳輸框架，設(shè)計(jì)了SDN 網(wǎng)絡(luò)上的多路徑QUIC 路由算法，通過多條最短路徑傳輸MPQUIC 子流。

在仿真平臺Mininet 與傳統(tǒng)方式的比較實(shí)驗(yàn)結(jié)果表明，在SDN 控制器中設(shè)計(jì)的多個(gè)模塊能提升QUIC 的路由控制和資源分配能力，提升系統(tǒng)吞吐量，縮短故障鏈路恢復(fù)時(shí)間，使得高質(zhì)量傳輸視頻流得到保障。