基于多路徑QUIC的視頻流傳輸優(yōu)化

包嘉琪，胡 暢，趙國強，黃俊杰，崔傲疊

（武漢紡織大學 計算機與人工智能學院，湖北 武漢 430200）

0 引言

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

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

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

1 相關(guān)研究

1.1 QUIC

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

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

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

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

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

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

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

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

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

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

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

1.3 QUIC傳輸優(yōu)化

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

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

2 系統(tǒng)框架設計

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

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

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

2.2 控制平面

控制平面通過SDN 的擴展Ryu 控制器實現(xiàn)，所有MPQUIC 數(shù)據(jù)包流量均由Ryu 控制器控制。Ryu 控制器由MPQUIC 流量管理器、分段路由模塊、網(wǎng)絡資源管理、數(shù)據(jù)庫模塊、網(wǎng)絡拓撲收集器和配置模塊組成。

2.2.1 網(wǎng)絡拓撲收集模塊

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

2.2.2 MPQUIC流量管理器

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

2.2.3 分段路由模塊

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

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

2.2.4 配置模塊

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

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

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

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

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

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

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

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

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

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

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

算法1多路徑QUIC 路由算法

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

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

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

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

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

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

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

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

Fig.6 Link recovery example圖6 鏈路恢復示例

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

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

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

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

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

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

算法2故障鏈路恢復算法

算法3從網(wǎng)絡拓撲中刪除故障鏈路的腳本

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

3.1 實驗環(huán)境

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

Fig.7 Experimental environment圖7 實驗環(huán)境

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

3.2 實驗數(shù)據(jù)集

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

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

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

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

3.3.1 系統(tǒng)吞吐量

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

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

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

3.3.2 故障鏈路恢復時間

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

Fig.9 Fault link recovery time圖9 故障鏈路恢復時間

3.3.3 視頻接收質(zhì)量

本文針對視頻質(zhì)量，使用下載吞吐量和視頻碼率間的比率——接收質(zhì)量(ρ)為指標［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 傳輸框架，設計了SDN 網(wǎng)絡上的多路徑QUIC 路由算法，通過多條最短路徑傳輸MPQUIC 子流。

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