面向時(shí)延敏感服務(wù)的多路徑傳輸調(diào)度算法

◎青島大學(xué)計(jì)算機(jī)科學(xué)技術(shù)學(xué)院◎馮飛宇◎陳飛◎

為了解決多路徑傳輸控制協(xié)議（MultiPath TCP，MPTCP）子流任務(wù)完成時(shí)間不同步、整體傳輸延遲過(guò)大的問(wèn)題。文章圍繞多路徑中的鏈路差異性設(shè)計(jì)了一種優(yōu)化傳輸調(diào)度算法。通過(guò)實(shí)時(shí)監(jiān)控多路徑的鏈路狀況和待發(fā)送數(shù)據(jù)流，將優(yōu)化調(diào)度方案分為兩部分，當(dāng)多路徑鏈路帶寬被充分利用時(shí)采用傳輸速率優(yōu)先，多條路徑并發(fā)的傳輸數(shù)據(jù)；當(dāng)多路徑鏈路帶寬未被充分利用時(shí)采用最快完成鏈路優(yōu)先，以緩解子流完成時(shí)間不同步的問(wèn)題。仿真結(jié)果顯示，在文件下載、網(wǎng)頁(yè)加載和視頻播放等場(chǎng)景下，該算法性能比默認(rèn)的最小往返延遲優(yōu)先（MinRtt）算法綜合提升了25%，可以降低傳輸延遲。

1.引言

傳統(tǒng)的TCP網(wǎng)絡(luò)架構(gòu)只允許設(shè)備利用一個(gè)網(wǎng)絡(luò)接口建立網(wǎng)絡(luò)連接，這導(dǎo)致了大量的網(wǎng)絡(luò)帶寬資源沒(méi)有被充分利用。為此，Multi-Connectivity的解決方案是通過(guò)在兩個(gè)網(wǎng)絡(luò)設(shè)備的網(wǎng)卡之間建立多條通訊鏈路，實(shí)現(xiàn)數(shù)據(jù)的聚合和分離[17]。其中MPTCP網(wǎng)絡(luò)協(xié)議是由IETF研發(fā)的位于傳輸層的實(shí)現(xiàn)，是目前使用最廣泛的多路徑網(wǎng)絡(luò)協(xié)議解決方案[1]。MPTCP允許設(shè)備利用其攜帶的多個(gè)網(wǎng)卡接口與對(duì)端設(shè)備建立多條網(wǎng)絡(luò)連接進(jìn)行數(shù)據(jù)傳輸任務(wù)，目前該協(xié)議應(yīng)用于多種實(shí)際場(chǎng)景，如：配備wifi和LTE的智能移動(dòng)終端[2][3]和數(shù)據(jù)中心中同時(shí)具有多條網(wǎng)絡(luò)鏈路的主機(jī)等[4]。MPTCP還可以與傳統(tǒng)TCP兼容且無(wú)需更改現(xiàn)有的上層應(yīng)用[5]，是目前最成熟的多路徑傳輸協(xié)議。

傳輸調(diào)度機(jī)制作為MPTCP中的一個(gè)重要組件，負(fù)責(zé)調(diào)度分配應(yīng)用層需要發(fā)送的數(shù)據(jù)，其通過(guò)傳輸調(diào)度算法將數(shù)據(jù)包分配給可用的子流進(jìn)行傳輸。作為傳輸調(diào)度機(jī)制核心的傳輸調(diào)度算法是決定MPTCP性能的主要因素之一[12]。但由于鏈路之間RTT、丟包率和擁塞窗口等網(wǎng)絡(luò)參數(shù)的差異性，會(huì)對(duì)傳輸調(diào)度算法性能造成很大的影響，甚至?xí)霈F(xiàn)性能比使用一條最佳TCP連接還要差的現(xiàn)象[6][11][13]。

目前MPTCP默認(rèn)的數(shù)據(jù)調(diào)度算法是MinRTT，該方法將優(yōu)先選擇RTT最小且存在擁塞窗口的鏈路以實(shí)現(xiàn)降低傳輸延遲的目的[7]。但由于終端設(shè)備的不同網(wǎng)絡(luò)接口普遍存在異構(gòu)性，網(wǎng)絡(luò)狀態(tài)也是動(dòng)態(tài)變化的，直觀的選擇RTT最小的鏈路并不一定獲得最佳的傳輸效率和系統(tǒng)資源利用率，具體體現(xiàn)在以下兩方面：首先，RTT并不能完全反映當(dāng)前網(wǎng)絡(luò)的擁塞狀況[14]，盲目選擇RTT小的鏈路分配傳輸任務(wù)很容易閑置其他擁有大量帶寬資源的鏈路，而且易造成較大的尾延遲。其次，雖然MinRTT可以結(jié)合機(jī)會(huì)重傳和懲罰機(jī)制避免丟包以降低網(wǎng)絡(luò)波動(dòng)造成的影響[11]，但其無(wú)法適應(yīng)網(wǎng)絡(luò)中類似視頻流等突發(fā)流量的場(chǎng)景[6]。

目前傳輸調(diào)度算法的設(shè)計(jì)主要存在以下兩個(gè)問(wèn)題：（1）調(diào)度算法選用的網(wǎng)絡(luò)參數(shù)無(wú)法完全描述當(dāng)前網(wǎng)絡(luò)狀況，鏈路傳輸完成時(shí)間存在較大的尾延遲，進(jìn)而影響總傳輸延遲；（2）調(diào)度算法易受網(wǎng)絡(luò)波動(dòng)的影響，無(wú)法適應(yīng)類似視頻流這樣的突發(fā)流量。

針對(duì)以上問(wèn)題，本文以協(xié)調(diào)多鏈路的總體傳輸延遲為主要目標(biāo)，解決了傳輸鏈路尾延遲較大的問(wèn)題，較好的應(yīng)對(duì)傳輸流量的突變，設(shè)計(jì)了不限制設(shè)備網(wǎng)絡(luò)接口數(shù)量的同步完成傳輸調(diào)度算法（synchronous completion transmission scheduling，SCTC），通過(guò)盡可能同步各鏈路傳輸任務(wù)完成時(shí)間以實(shí)現(xiàn)低延遲傳輸。

2.相關(guān)工作介紹

雖然目前仍沒(méi)有完善的調(diào)度算法，但已經(jīng)有很多工作針對(duì)不同的性能優(yōu)化目標(biāo)提出了一些改進(jìn)的調(diào)度算法。目前MPTCP調(diào)度器研究工作的性能優(yōu)化目標(biāo)主要分為：降低總的傳輸延遲、提高數(shù)據(jù)傳輸?shù)耐掏铝康取?/p>

低延遲是數(shù)據(jù)傳輸性能的一個(gè)關(guān)鍵指標(biāo)，是傳輸調(diào)度算法的優(yōu)化主要方向。MinRTT是目前l(fā)inux-MPTCP內(nèi)核中默認(rèn)的調(diào)度算法，該算法將優(yōu)先選擇RTT最小且存在擁塞窗口的鏈路以實(shí)現(xiàn)降低傳輸延遲的目的[7]，但RTT反映不了網(wǎng)絡(luò)的真實(shí)狀況，由于子鏈路的異構(gòu)性，會(huì)出現(xiàn)擁塞堵塞等降低網(wǎng)絡(luò)資源使用率的現(xiàn)象；REMP[10]中所有子流冗余的發(fā)送相同數(shù)據(jù)，以帶寬換取低延遲和魯棒性，網(wǎng)絡(luò)中往往會(huì)存在大量無(wú)用的冗余數(shù)據(jù)，增加了網(wǎng)絡(luò)的負(fù)載，帶寬有效利用率低；DEMS[8]通過(guò)同步兩個(gè)子流的完成時(shí)間來(lái)實(shí)現(xiàn)低延遲傳輸，同時(shí)通過(guò)添加適量的冗余數(shù)據(jù)以適應(yīng)網(wǎng)絡(luò)波動(dòng)，該算法的限制在于MPTCP連接只支持兩條子流，同時(shí)會(huì)占用接收端大量的緩存空間，只適用于中小型文件（小于8M）[8][9]；DAPS[15]根據(jù)每個(gè)鏈路的實(shí)時(shí)傳輸時(shí)間選擇要在每個(gè)路徑上傳輸?shù)姆纸M序列，以有序接收，降低緩存占有率，降低應(yīng)用層提取數(shù)據(jù)的延遲，但受鏈路差異性影響，無(wú)法對(duì)網(wǎng)絡(luò)變化做出快速反應(yīng)。

在一些高帶寬需求應(yīng)用場(chǎng)景，例如視頻流媒體，吞吐量成為影響用戶服務(wù)質(zhì)量的重要因素。ECF[6]通過(guò)通過(guò)計(jì)算慢路徑與快路徑的傳輸完成時(shí)間來(lái)選擇鏈路，提高快鏈路的使用效率，從而提高吞吐量，但該算法的復(fù)雜度隨鏈路數(shù)量增加而指數(shù)增加，且易受網(wǎng)絡(luò)波動(dòng)的影響。文獻(xiàn)[14]中提出的調(diào)度算法，在MinRTT的基礎(chǔ)上加入了鏈路擁塞狀況的考慮，通過(guò)分配與鏈路可用容量成比例的數(shù)據(jù)包，盡可能避免擁塞來(lái)提高吞吐量，但對(duì)于可用容量的計(jì)算會(huì)因?yàn)榫W(wǎng)絡(luò)變化出現(xiàn)誤差。BLEST[16]則通過(guò)檢測(cè)發(fā)送窗口是否阻塞，最大限度地減少異構(gòu)網(wǎng)絡(luò)中的LOL阻塞問(wèn)題，從而減少重傳數(shù)量提高吞吐量。

3.多路徑傳輸性能分析

為了驗(yàn)證MPTCP的可靠性，在VMware平臺(tái)安裝IEFT發(fā)布的Linux-MPTCP操作系統(tǒng)，配置了三個(gè)網(wǎng)絡(luò)接口，使用MPTCP默認(rèn)的三種傳輸調(diào)度算法MinRtt、Round Robin(RR)和Opportunity Redundant(OR)進(jìn)行文件傳輸速率測(cè)試，并于傳統(tǒng)TCP傳輸進(jìn)行比較。實(shí)驗(yàn)中設(shè)計(jì)了兩種實(shí)驗(yàn)場(chǎng)景，在鏈路差異較小的情況，三個(gè)網(wǎng)絡(luò)接口的帶寬分別為：10M，9M，8M；鏈路差異較大的場(chǎng)景下，網(wǎng)絡(luò)接口的帶寬為：10M，5M，1M；TCP實(shí)驗(yàn)組網(wǎng)絡(luò)接口帶寬固定為10M。每組實(shí)驗(yàn)做五次，并取實(shí)驗(yàn)結(jié)果平均值作為最終的結(jié)果。

實(shí)驗(yàn)結(jié)果顯示傳統(tǒng)TCP的平均傳輸速率為1.1M/s，而MPTCP的傳輸速率隨鏈路的差異大小而變化。如表1所示，在鏈路差異較小的情況下，MPTCP傳輸速率可以達(dá)到傳統(tǒng)TCP的250%；而在鏈路差異較大的情況下，MPTCP的傳輸性能只有傳統(tǒng)TCP的53%?？梢娋W(wǎng)絡(luò)環(huán)境的差異性對(duì)于MPTCP的傳輸性能影響很大。

表1 MPTCP與TCP下載性能對(duì)比

接下來(lái)通過(guò)動(dòng)態(tài)的加載網(wǎng)卡實(shí)驗(yàn)來(lái)表現(xiàn)網(wǎng)絡(luò)環(huán)境差異性與動(dòng)態(tài)性的綜合影響，該實(shí)驗(yàn)初始時(shí)只有一個(gè)網(wǎng)卡投入使用，之后每隔10秒多加載一塊網(wǎng)卡，最多同時(shí)加載三塊，實(shí)驗(yàn)結(jié)果如圖1所示。在鏈路差異較小的情況下動(dòng)態(tài)的加載網(wǎng)卡，整體的網(wǎng)絡(luò)傳輸速率呈線性的上升；而當(dāng)鏈路差異較大時(shí)，動(dòng)態(tài)的加載網(wǎng)卡對(duì)傳輸性能提升有限，而且隨著網(wǎng)卡數(shù)量的逐漸增加，傳輸性能反而大幅下降。

圖1 網(wǎng)絡(luò)接口動(dòng)態(tài)加載

4.問(wèn)題模型與解決方案

為了能夠在異構(gòu)網(wǎng)絡(luò)中降低傳輸延遲，我們進(jìn)行以下建模分析。

參數(shù)列表 說(shuō)明n 未發(fā)送的數(shù)據(jù)包數(shù)量n′ 可能造成尾延遲的數(shù)據(jù)包數(shù)量m可用鏈路數(shù)量i當(dāng)前鏈路i cwndi 鏈路i當(dāng)前可用的擁塞窗口rtti 鏈路i當(dāng)前的往返延遲

表2 參數(shù)說(shuō)明

每輪的發(fā)送周期以當(dāng)前時(shí)刻未發(fā)送的數(shù)據(jù)包作為接下來(lái)需要傳輸調(diào)度的數(shù)據(jù)。假設(shè)一個(gè)周期內(nèi)存在n個(gè)數(shù)據(jù)包需要發(fā)送，終端設(shè)備擁有m條可用鏈路，每條鏈路的擁塞窗口大小為cwndi，每條鏈路的往返時(shí)延為rtti，傳輸調(diào)度算法需要設(shè)計(jì)合理的調(diào)度算法來(lái)給每條鏈路分配數(shù)據(jù)包，使得傳輸任務(wù)總延遲T最低。假設(shè)一個(gè)周期內(nèi)，每條鏈路需要發(fā)送的數(shù)據(jù)包數(shù)量為si，則每條鏈路的傳輸完成時(shí)間ti可以通過(guò)公式（1）的分段函數(shù)求出。在實(shí)際傳輸過(guò)程中，未填充滿擁塞窗口的數(shù)據(jù)傳輸仍會(huì)耗時(shí)一個(gè)rtt，所以需要合理的給子流分配數(shù)據(jù)包，盡可能的同步子流的完成時(shí)間，提高每條鏈路的使用效率，減少每個(gè)周期傳輸任務(wù)的完成時(shí)間。即在求解ti的時(shí)候需要盡可能的滿足si%cwndi=0 的條件。（1）

通過(guò)對(duì)以上問(wèn)題的建模，可以得到： （2）

由于該模型目標(biāo)函數(shù)t 是非線性的，隨著數(shù)據(jù)包數(shù)量的增加，目標(biāo)函數(shù)圖像呈階梯狀。又由于決策變量s和鏈路的窗口cwnd、時(shí)延rtt為離散的整數(shù)，所以該問(wèn)題是混合整數(shù)非線性規(guī)劃問(wèn)題，是非凸優(yōu)化問(wèn)題[18]。這類問(wèn)題通常是NP的，無(wú)法在多項(xiàng)式時(shí)間內(nèi)求解出最優(yōu)解，可以使用近似算法得到近似解。

4.1多路徑并發(fā)傳輸

首先多路徑并發(fā)傳輸模塊作為SCTC算法的一部分，在發(fā)送緩沖區(qū)數(shù)據(jù)較大時(shí)調(diào)用，此時(shí)各鏈路可以充分利用帶寬資源。該部分按照鏈路的數(shù)據(jù)傳輸速率來(lái)為每條鏈路分配數(shù)據(jù)包，其中cwndi可以表示鏈路的實(shí)際網(wǎng)絡(luò)負(fù)載能力，rtti表示鏈路的往返時(shí)延，用來(lái)代表鏈路的實(shí)際網(wǎng)絡(luò)傳輸能力。該調(diào)度算法在終端需要發(fā)送數(shù)據(jù)的時(shí)候調(diào)用，分配的數(shù)據(jù)即為當(dāng)前發(fā)送緩沖區(qū)的數(shù)據(jù)，該調(diào)度算法根據(jù)各鏈路的傳輸速率的比例分配傳輸任務(wù)，盡量實(shí)現(xiàn)各子流完成時(shí)間同步。在傳輸過(guò)程中產(chǎn)生新的發(fā)送請(qǐng)求則等待當(dāng)前傳輸任務(wù)都結(jié)束后執(zhí)行，傳輸調(diào)度算法默認(rèn)每個(gè)發(fā)送周期內(nèi)網(wǎng)絡(luò)參數(shù)不變。偽代碼如下所示。

Repeat

篩選出當(dāng)前所有擁有擁塞窗口的鏈路集合sbfCandidates

if sbfCandidates is NULL

當(dāng)前無(wú)可用鏈路，退出并等待下一個(gè)發(fā)送周期

else

Until（鏈路選擇結(jié)束）

圖2 尾延遲

在每個(gè)發(fā)送周期內(nèi)，該模塊首先篩選出當(dāng)前所有的具備擁塞窗口的可用鏈路，之后計(jì)算的各個(gè)子流的傳輸速率并優(yōu)先選擇傳輸速率大的鏈路分配傳輸任務(wù)。這個(gè)方法可以在一定程度上緩解鏈路異構(gòu)性帶來(lái)的影響，但該方法通過(guò)公式（1）計(jì)算得到的子流完成時(shí)間差異仍比較大。如圖2所示，T′為理想的完成時(shí)間線，即n個(gè)數(shù)據(jù)包按照MPTCP所有鏈路的傳輸能力之和計(jì)算所需要花費(fèi)的時(shí)間，但一般情況下很難實(shí)現(xiàn)絕對(duì)同步的情況；T為執(zhí)行該調(diào)度算法完成傳輸任務(wù)的實(shí)際完成時(shí)間線，可以按照公式（1）計(jì)算，各鏈路最后一次都會(huì)傳輸少量的剩余數(shù)據(jù)。T-T′為尾延遲?？梢苑治龅玫轿惭舆t現(xiàn)象的原因是快速鏈路的使用效率較低，慢鏈路上負(fù)載了較多的數(shù)據(jù)傳輸任務(wù)，且尾延遲現(xiàn)象會(huì)隨著鏈路差異性的增加，越來(lái)越明顯。

4.2尾延遲處理

圖3 SCTC鏈路選擇流程

為了盡可能避免尾延遲現(xiàn)象對(duì)整體傳輸延遲的影響，需要進(jìn)一步完善傳輸調(diào)度算法SCTC。由于模型（2）是NP的，無(wú)法在有限時(shí)間內(nèi)求出最優(yōu)解，所以為了能夠盡可能的同步子流的完成時(shí)間，SCTC在造成尾延遲的部分?jǐn)?shù)據(jù)通過(guò)貪心算法來(lái)獲得次優(yōu)解。

在多路徑并發(fā)傳輸階段每條鏈路進(jìn)行數(shù)據(jù)傳輸?shù)臄?shù)據(jù)量是其擁塞窗口的整數(shù)倍，各子流完成所分配的數(shù)據(jù)傳輸任務(wù)所需要的時(shí)間為如公式（3）所示：

結(jié)合公式（1）與公式（3），子流的完成時(shí)間滿足等式（4），當(dāng)si剛好為子流擁塞窗口的整數(shù)倍時(shí)，不存在造成尾延遲的數(shù)據(jù)，所以其傳輸任務(wù)完成時(shí)間等于公式（1）計(jì)算所得時(shí)間；如果si不是子流擁塞窗口的整數(shù)倍，則此時(shí)其完成時(shí)間與公式（1）計(jì)算所得相差一個(gè)rtti的時(shí)間，傳輸調(diào)度算法所要做的正是優(yōu)化由于子流鏈路屬性差異性使得最后一次傳輸造成子流完成時(shí)間的不同步，以減少總的傳輸時(shí)間。（4）

SCTC用n′表示剩余未分配的數(shù)據(jù)包。通過(guò)公式（5）可求得n′。如果多路徑并發(fā)傳輸階段T′=T，則n′=0，各子流的傳輸完成時(shí)間完美同步，不需要優(yōu)化；若每條鏈路在最后一次傳輸時(shí)其擁塞窗口都只差一個(gè)數(shù)據(jù)包塞滿時(shí)，此時(shí)n′獲得最大值，是最壞情況，不存在優(yōu)化空間。n′取值范圍如公式（6）所示。

圖4 實(shí)驗(yàn)架構(gòu)

圖5 不同帶寬下文件下載實(shí)驗(yàn)

圖6 網(wǎng)頁(yè)對(duì)象加載實(shí)驗(yàn)

經(jīng)過(guò)上面的分析，尾延遲是由于快速鏈路的使用效率低造成的，所以分配最后的n′個(gè)數(shù)據(jù)包時(shí)，優(yōu)先選擇可以提前完成任務(wù)的鏈路k，貪心規(guī)則為：

其中ti為鏈路i當(dāng)前任務(wù)的完成時(shí)間，rtti為鏈路i的往返時(shí)延。

傳輸速率優(yōu)先模塊分配數(shù)據(jù)時(shí)，會(huì)出現(xiàn)數(shù)據(jù)無(wú)法完整的填充子流擁塞窗口的現(xiàn)象，剩下的數(shù)據(jù)雖然很少，但仍需要一個(gè)rtt的傳輸時(shí)間，所以使用傳輸速率優(yōu)先模塊的傳輸時(shí)間為T=t′i+rttmax；而做了尾延遲處理的SCTC傳輸完成時(shí)間是T′=Min(t′i+rtti)，可得出T′≤T。SCTC算法偽代碼與流程圖如下所示：

Repeat

篩選出當(dāng)前所有擁有擁塞窗口的鏈路集合sbfCandidates

if sbfCandidates is NULL

當(dāng)前無(wú)可用鏈路，退出并等待下一個(gè)發(fā)送周期

else

統(tǒng)計(jì)未發(fā)送數(shù)據(jù)包數(shù)量R1與所有鏈路剩余擁塞窗口數(shù)量R2。

if R1 < R2

貪心選擇最先完成傳輸任務(wù)的鏈路

else

優(yōu)先選擇傳輸速率最大的鏈路

Until（鏈路選擇結(jié)束）

具體流程如圖3所示，首先選取所有的可用鏈路，并統(tǒng)計(jì)未發(fā)生的數(shù)據(jù)包數(shù)量R1和當(dāng)前剩余的擁塞窗口R2，如果 R1>R2 時(shí)，此時(shí)優(yōu)先選擇發(fā)送速率大的鏈路分配數(shù)據(jù)，盡可能快的將數(shù)據(jù)傳遞到對(duì)端；若 R1≤R2 ,則說(shuō)明此時(shí)鏈路的擁塞窗口可能填充不滿，所以為了盡量避免尾延遲，需要優(yōu)先選擇可以提前完成傳輸任務(wù)的鏈路。

5.實(shí)驗(yàn)

5.1實(shí)驗(yàn)設(shè)置

為了驗(yàn)證SCTC傳輸調(diào)度算法的性能，通過(guò)VMware虛擬機(jī)平臺(tái)搭建了實(shí)驗(yàn)環(huán)境；其中服務(wù)端主機(jī)安裝了搭載PROGMP編程模型的MPTCP內(nèi)核，客戶端安裝IETF官網(wǎng)發(fā)布的Linux-MPTCP。實(shí)驗(yàn)環(huán)境中的主機(jī)操作系統(tǒng)均為ubuntu 18.04，配置多個(gè)網(wǎng)卡。實(shí)驗(yàn)過(guò)程中通過(guò)VMware網(wǎng)卡設(shè)置功能修改client端網(wǎng)卡的RTT、帶寬等網(wǎng)絡(luò)參數(shù)模擬各類網(wǎng)絡(luò)狀況，并與linux-mpTCP中集成的minRtt、Round Robin(RR)和 Opportunity Redundant(OR)三種調(diào)度算法進(jìn)行性能對(duì)比。實(shí)驗(yàn)架構(gòu)模型圖如圖4所示。

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

首先進(jìn)行文件下載場(chǎng)景下的性能測(cè)試。該試驗(yàn)共進(jìn)行四組實(shí)驗(yàn)，分別下載不同大小的文件，將SCTC與linux-MPTCP集成的三種傳輸調(diào)度算法進(jìn)行下載時(shí)間的比較，同時(shí)為了確定網(wǎng)卡性能差異性帶來(lái)的影響，先將一個(gè)網(wǎng)卡的帶寬設(shè)置為1M，將另一個(gè)網(wǎng)卡的帶寬值由1M逐漸變?yōu)?0M，圖5的橫坐標(biāo)表示的就是第二個(gè)網(wǎng)卡的帶寬值?？梢钥闯?，隨著第二塊網(wǎng)卡的帶寬逐漸增大，文件的下載時(shí)間前期是逐漸減少的，但隨著鏈路之間網(wǎng)絡(luò)性能差異越來(lái)越大，下載時(shí)間后面會(huì)小幅度的增加。本文中所提出SCTC算法在實(shí)驗(yàn)中表現(xiàn)良好，通過(guò)圖5可以看出該算法更適用于中等大小的文件，對(duì)于64K這樣足夠小文件和4M這樣的大文件傳輸調(diào)度算法對(duì)總的下載時(shí)間影響較小，總體來(lái)說(shuō)相比于linux-MPTCP默認(rèn)的MinRtt調(diào)度算法性能提升了約24%，與RR和OR比起來(lái)也有不少的提升。

接著測(cè)試傳輸調(diào)度算法在子流網(wǎng)絡(luò)環(huán)境差異較大的情況下加載網(wǎng)絡(luò)頁(yè)面的性能。客戶端設(shè)置了三個(gè)網(wǎng)卡，帶寬分別為1M、5M和10M。將故宮官網(wǎng)首頁(yè)部署服務(wù)器端，共包含53個(gè)網(wǎng)絡(luò)文件，客戶端瀏覽器加載網(wǎng)頁(yè)時(shí)，將一直保持與服務(wù)器的網(wǎng)絡(luò)連接，持續(xù)下載網(wǎng)絡(luò)文件。圖6左圖描述了從請(qǐng)求網(wǎng)頁(yè)到頁(yè)面完全加載的時(shí)間，SCTC較其他三種傳輸調(diào)度算法加載時(shí)間減少約25%；圖6右圖顯示了網(wǎng)頁(yè)內(nèi)全部網(wǎng)絡(luò)文件從瀏覽器請(qǐng)求到完成加載的時(shí)間CDF圖，SCTC傳輸調(diào)度算法較其他三種傳輸調(diào)度算法提前加載96.7%的網(wǎng)絡(luò)文件。結(jié)果顯示SCTC可以較好的應(yīng)對(duì)網(wǎng)頁(yè)加載的場(chǎng)景。

最后測(cè)試調(diào)度算法在網(wǎng)絡(luò)差異較大的環(huán)境下播放dash視頻時(shí)可以達(dá)到的碼率以及對(duì)應(yīng)的分辨率。實(shí)驗(yàn)環(huán)境中，客戶端配備了三個(gè)網(wǎng)卡，帶寬分別為1M、5M和10M，同時(shí)使用ffmpeg工具將測(cè)試視頻分別轉(zhuǎn)碼為360P、480P、720P、1080P和1080P（60幀）的視頻段，并使用開源的dash.js播放器進(jìn)行播放。實(shí)驗(yàn)結(jié)果如表3所示，SCTC傳輸調(diào)度算法相較與其他三種調(diào)度算法，在網(wǎng)絡(luò)差異較大的環(huán)境下可以將播放視頻的分辨率穩(wěn)定在720P，碼率為1310kbps，性能較minRtt調(diào)度算法性能提高了56%，測(cè)試結(jié)果表明SCTC傳輸調(diào)度算法可以有效的應(yīng)對(duì)視頻流這樣的突發(fā)流量。

表3 Dash視頻播放測(cè)試

6.總結(jié)

本文中提出了一種新的MPTCP傳輸調(diào)度算法，首先通過(guò)一些實(shí)驗(yàn)證實(shí)了各鏈路網(wǎng)絡(luò)的差異性與動(dòng)態(tài)性對(duì)傳輸性能的影響。之后通過(guò)公式推導(dǎo)，將SCTC傳輸調(diào)度算法分為兩個(gè)算法模塊：可以優(yōu)先選擇傳輸速率快的鏈路傳輸數(shù)據(jù)，以達(dá)到快速降低傳輸延遲的目的；在數(shù)據(jù)量較少時(shí)貪心的選擇最先完成的鏈路，可以避免尾延遲對(duì)傳輸性能的影響。最后通過(guò)進(jìn)行仿真實(shí)驗(yàn)測(cè)試該算法在文件下載、網(wǎng)頁(yè)加載和視頻播放等常見場(chǎng)景下的性能，并與現(xiàn)有的三種傳輸調(diào)度算法進(jìn)行了對(duì)比，結(jié)果表明SCTC傳輸調(diào)度算法性能較好，可以降低傳輸延遲。