基于DASH流媒體的TCP擁塞控制算法優(yōu)化

吳 樺 王 凌 程 光

(東南大學(xué)網(wǎng)絡(luò)空間安全學(xué)院 南京 211189) (計(jì)算機(jī)網(wǎng)絡(luò)和信息集成教育部重點(diǎn)實(shí)驗(yàn)室(東南大學(xué)) 南京 211189)

根據(jù)2018年思科公司的全球互聯(lián)網(wǎng)流量研究報(bào)告[1]顯示，從2017—2022年，互聯(lián)網(wǎng)視頻流量將增長(zhǎng)4倍，預(yù)計(jì)到2022年，IP視頻流量占整個(gè)互聯(lián)網(wǎng)流量的比例將高達(dá)82%.YouTube是全球最大的視頻內(nèi)容提供商之一，擁有超過10億的用戶，觀看時(shí)長(zhǎng)每天可達(dá)數(shù)億小時(shí)，并產(chǎn)生數(shù)億的觀看次數(shù)，因此視頻服務(wù)提供商也致力于為用戶提供更好的觀影體驗(yàn)以贏得更多的效益.隨著用戶觀看視頻需求量的增大，流媒體傳輸技術(shù)也日新月異，從傳統(tǒng)的基于用戶數(shù)據(jù)報(bào)協(xié)議(user datagram protocol, UDP)的實(shí)時(shí)傳輸協(xié)議(real-time transport protocol, RTP)轉(zhuǎn)變?yōu)榛趥鬏斂刂茀f(xié)議(transmission control protocol, TCP)的超文本傳輸協(xié)議(hyper text transfer protocol, HTTP)傳輸模式，各大視頻服務(wù)提供商為獲取更多的用戶不斷提出新的流媒體傳輸技術(shù).碼流自適應(yīng)HAS(HTTP adaptive streaming)是當(dāng)前應(yīng)用比較廣泛的流媒體傳輸技術(shù)，全球主要的視頻服務(wù)提供商都采用了這個(gè)技術(shù)，而且有不同的實(shí)現(xiàn)方案，如Adobe公司基于Flash的HTTP動(dòng)態(tài)流媒體方案、微軟公司的平滑流媒體方案IIS(Internet information server) Smooth Streaming[2]、蘋果公司的HLS(HTTP live streaming)[3]方案、MPEG與3GPP聯(lián)合提出的基于HTTP的動(dòng)態(tài)自適應(yīng)流媒體傳輸技術(shù)DASH(dynamic adaptive streaming over HTTP)[4]協(xié)議.這些技術(shù)將視頻編碼為不同的分辨率，并切分為許多片段來進(jìn)行傳輸，這種傳輸技術(shù)可以在不同分辨率分片之間進(jìn)行無縫切換并提供高質(zhì)量的業(yè)務(wù)體驗(yàn).

除了HAS技術(shù)外，互聯(lián)網(wǎng)視頻服務(wù)提供商也采用了多種技術(shù)優(yōu)化視頻播放體驗(yàn)，如改善解碼技術(shù)、應(yīng)用層速率控制、網(wǎng)關(guān)流量整型、視頻流量傳輸協(xié)議優(yōu)化等，這些技術(shù)旨在提高網(wǎng)絡(luò)資源利用率、改善瓶頸鏈路帶寬競(jìng)爭(zhēng)等問題，從而使用戶獲得良好的視頻播放服務(wù)質(zhì)量和服務(wù)體驗(yàn).TCP作為HAS的傳輸層協(xié)議，是網(wǎng)絡(luò)中提供端到端擁塞控制的主要組成部分，其傳輸性能是影響視頻客戶端播放體驗(yàn)的重要因素之一.為了適應(yīng)不同的網(wǎng)絡(luò)環(huán)境，許多擁塞控制算法已經(jīng)被提了出來，例如NewReno[5]，CUBIC[6]，Westwood[7]，CTCP[8]，DCTCP[9]，TCP-Illinois[10]等，但這些算法大都適用于一般的文件傳輸，不能很好地適應(yīng)于自適應(yīng)流媒體的ON-OFF傳輸特點(diǎn).傳統(tǒng)的TCP擁塞控制算法會(huì)在DASH視頻傳輸空閑時(shí)間超時(shí)后重新進(jìn)入慢啟動(dòng)階段，造成網(wǎng)絡(luò)利用率低，而DASH視頻的突發(fā)也在一定程度上影響其他TCP流的傳輸，當(dāng)多個(gè)HAS客戶端在瓶頸鏈路產(chǎn)生帶寬競(jìng)爭(zhēng)時(shí)，ON-OFF傳輸模式也可能會(huì)使播放器錯(cuò)誤地估測(cè)帶寬，從而導(dǎo)致不公平的帶寬競(jìng)爭(zhēng)以及視頻分辨率頻繁切換，對(duì)客戶端的體驗(yàn)質(zhì)量(quality of experience, QoE)和網(wǎng)絡(luò)服務(wù)質(zhì)量(quality of service, QoS)產(chǎn)生影響，極大地降低了用戶的觀看體驗(yàn).文獻(xiàn)[11]根據(jù)流媒體的特點(diǎn)給出了在交換設(shè)備上的優(yōu)化傳輸方案，由于需要對(duì)交換設(shè)備定制，實(shí)際環(huán)境中部署起來較為困難.

為此，本文結(jié)合自適應(yīng)流媒體傳輸技術(shù)DASH，對(duì)TCP擁塞控制算法的優(yōu)化展開研究，主要貢獻(xiàn)有：基于TCP Vegas提出一種在服務(wù)器端實(shí)現(xiàn)的擁塞控制算法TCP-HAS.它在自適應(yīng)流媒體傳輸發(fā)生空閑后選擇最接近當(dāng)前流所占帶寬值的碼率，根據(jù)碼率計(jì)算出最小窗口值，同時(shí)將慢啟動(dòng)門限值設(shè)置為當(dāng)前窗口值，進(jìn)入擁塞避免階段.這種做法不但能夠防止傳統(tǒng)TCP擁塞控制算法在空閑超時(shí)后將擁塞窗口降為最低，也能夠防止慢啟動(dòng)快速增加擁塞窗口到帶寬時(shí)延積產(chǎn)生的突發(fā)，使得TCP擁塞窗口維持在一個(gè)相對(duì)穩(wěn)定的值，客戶端播放器會(huì)結(jié)合上一分片的吞吐量請(qǐng)求一個(gè)不高但相對(duì)穩(wěn)定的分辨率分片，從而降低視頻分辨率的頻繁波動(dòng).實(shí)驗(yàn)表明在進(jìn)行DASH視頻傳輸時(shí)，TCP-HAS能夠提升網(wǎng)絡(luò)QoS和用戶的QoE，并能在多個(gè)用戶共享鏈路帶寬時(shí)提升用戶觀影體驗(yàn).

1 DASH流媒體技術(shù)簡(jiǎn)介

本節(jié)將對(duì)基于HTTP的動(dòng)態(tài)自適應(yīng)流媒體傳輸技術(shù)DASH進(jìn)行詳細(xì)介紹，同時(shí)對(duì)其在傳輸過程中可能產(chǎn)生的問題進(jìn)行分析.

1.1 DASH流媒體技術(shù)

目前主流的HAS傳輸技術(shù)有DASH和HLS視頻傳輸技術(shù).DASH是獨(dú)立于視頻服務(wù)提供商的國際標(biāo)準(zhǔn)，于2012年發(fā)布，適用于安卓終端設(shè)備；而HLS主要應(yīng)用在蘋果公司開發(fā)的iOS系統(tǒng)，為iOS設(shè)備(如iPhone,iPad)提供音視頻直播和點(diǎn)播方案.

DASH架構(gòu)主要分為3個(gè)部分(如圖1所示)：視頻內(nèi)容生成模塊、流媒體服務(wù)器模塊和DASH客戶端播放器.內(nèi)容生成部分按照從低到高的碼率水平對(duì)視頻進(jìn)行編碼切片并生成媒體展示描述(media presentation description, MPD)文件，MPD文件記錄視頻分片的信息以及資源URL.流媒體服務(wù)器提供HTTP服務(wù)和視頻服務(wù)，負(fù)責(zé)內(nèi)容的存儲(chǔ)和分發(fā).DASH播放器主要是對(duì)MPD文件的解析以及對(duì)視頻片段的請(qǐng)求.用戶首先請(qǐng)求MPD文件，播放器對(duì)其解析，然后根據(jù)當(dāng)前的網(wǎng)絡(luò)狀況來請(qǐng)求特定的分片，通過分片的URL來建立HTTP連接，同時(shí)視頻播放過程中客戶端也會(huì)根據(jù)網(wǎng)絡(luò)狀況來選擇合適的分片，其傳輸過程如圖2所示.

Fig. 1 DASH transmission technology architecture圖1 DASH傳輸技術(shù)架構(gòu)

Fig. 2 DASH streaming media transmission process圖2 DASH流媒體傳輸過程

1.2 DASH播放器帶寬競(jìng)爭(zhēng)分析

由于DASH流媒體服務(wù)器端的分段存儲(chǔ)和客戶端播放器緩存的存在，當(dāng)兩者建立TCP連接后，客戶端會(huì)依次進(jìn)入如圖3所示的2個(gè)階段[12]：

1) 初始緩沖階段.這一階段播放器在請(qǐng)求分片時(shí)為了盡可能快地達(dá)到緩沖區(qū)的大小，只要前一個(gè)片段緩沖完畢，就會(huì)立即請(qǐng)求下一個(gè)片段，直到緩沖區(qū)滿，然后進(jìn)入下一階段.

2) 穩(wěn)態(tài)階段.這一階段播放器緩沖區(qū)被分片填滿的大小恒定不變.假設(shè)一個(gè)分片時(shí)長(zhǎng)為T(單位為s)，播放器每間隔時(shí)長(zhǎng)T從服務(wù)器端下載分片，網(wǎng)速較好的時(shí)候，一次分片傳輸結(jié)束到下一個(gè)分片傳輸開始間隔時(shí)長(zhǎng)t, 下載時(shí)長(zhǎng)為T-t，在某些情況下也有可能剛接收到前一個(gè)分片就請(qǐng)求下一個(gè).這種情況播放器的下載會(huì)形成一個(gè)ON-OFF模式，ON狀態(tài)下載分片(持續(xù)時(shí)長(zhǎng)為T-t)，OFF狀態(tài)處于空閑狀態(tài)(持續(xù)時(shí)長(zhǎng)為t).

Fig. 3 Client and server request-response process圖3 客戶服務(wù)器請(qǐng)求-響應(yīng)時(shí)間圖

DASH視頻的分片和ON-OFF傳輸模式會(huì)使服務(wù)器端應(yīng)用程序處于速率限制和空閑狀態(tài)，進(jìn)而影響TCP的傳輸性能.對(duì)于許多一直有數(shù)據(jù)要發(fā)送的TCP流來說，已經(jīng)發(fā)送但還沒有被確認(rèn)的數(shù)據(jù)量FlightSize會(huì)隨著擁塞窗口cwnd的增加而增加.但是對(duì)于自適應(yīng)流媒體這類應(yīng)用程序來說，由于其分片傳輸時(shí)表現(xiàn)出的ON-OFF特點(diǎn)，可能會(huì)存在信道空閑或無法以cwnd所允許的最大速率發(fā)送的狀態(tài)，在這種情況下，2個(gè)往返時(shí)間(round trip time,RTT)內(nèi)的FlightSize可能會(huì)從遠(yuǎn)小于cwnd的值變化到cwnd所允許的最大值，由此引發(fā)數(shù)據(jù)包突發(fā)而帶來的網(wǎng)絡(luò)擁塞狀況.同時(shí)由于空閑持續(xù)的時(shí)間超過重傳超時(shí)(retransmission timeout,RTO)[13]后，傳統(tǒng)的TCP協(xié)議棧會(huì)重新進(jìn)入慢啟動(dòng)，造成擁塞窗口變小，不能充分利用可用帶寬.與傳統(tǒng)的流媒體傳輸技術(shù)不同的是，當(dāng)2個(gè)或多個(gè)DASH播放器在請(qǐng)求分片時(shí)，由于多個(gè)播放器ON-OFF時(shí)間段的重疊，它們可能會(huì)不正確地估測(cè)所應(yīng)該獲得的帶寬值，這樣會(huì)帶來播放不穩(wěn)定、帶寬的不公平競(jìng)爭(zhēng)和利用不充分等問題.

Fig. 4 Three cases of two players about ON-OFF圖4 2個(gè)播放器ON-OFF的3種情況圖

假設(shè)2個(gè)DASH播放器共享瓶頸鏈路的總?cè)萘繛镃，它們接收端所獲得的吞吐量分別為f1和f2，并且每個(gè)播放器都已經(jīng)處于穩(wěn)態(tài)階段.忽略TCP協(xié)議棧的影響，在下載片段時(shí)，理論上2個(gè)播放器所獲得的吞吐量都應(yīng)該為f=C2，但是由于ON-OFF模式的存在，2個(gè)播放器所獲得的吞吐量可能為f1=f2>f，如圖4(a)所示，2個(gè)播放器的ON狀態(tài)沒有重疊部分，都高于它們的公平共享值，基于所估測(cè)的TCP吞吐量，2個(gè)播放器都將請(qǐng)求較高的碼率分片，此時(shí)可能發(fā)生網(wǎng)絡(luò)擁塞，導(dǎo)致吞吐量下降，反過來它們又會(huì)切換為較低的碼率，由于ON-OFF存在于整個(gè)播放期，這種情況將會(huì)反復(fù)發(fā)生，從而會(huì)造成視頻播放的不穩(wěn)定.圖4(b)中是另外一種情形，播放器2的ON時(shí)間段落在了播放器1的ON時(shí)間段內(nèi)，當(dāng)播放器1請(qǐng)求的分片碼率大于播放器2請(qǐng)求的分片碼率時(shí)，這種情況就有可能發(fā)生.此時(shí)播放器2所估測(cè)的吞吐量為f，而播放器1估測(cè)的大于f，兩者可能最終獲得一個(gè)穩(wěn)定但不公平的帶寬值，播放器會(huì)趨于請(qǐng)求較高碼率的分片.圖4(c)是2個(gè)播放器的ON時(shí)間段完全重合的情形，假設(shè)在服務(wù)器端1個(gè)視頻片段有2種碼率b1和b2，其中b1C2，這種情況下當(dāng)b1?b2且b1+b2≈C時(shí)，2個(gè)播放器都會(huì)趨于請(qǐng)求b1，使得帶寬利用不充分.

前面的例子說明了2個(gè)DASH播放器的一些競(jìng)爭(zhēng)場(chǎng)景.其他一些因素也有可能對(duì)視頻的播放產(chǎn)生不穩(wěn)定、競(jìng)爭(zhēng)不公平和帶寬利用率不充分等問題，例如播放器碼率自適應(yīng)算法、網(wǎng)絡(luò)帶寬波動(dòng)以及視頻編碼技術(shù)等.本文將在TCP層通過優(yōu)化擁塞控制算法來減弱空閑狀態(tài)對(duì)客戶端播放器碼率切換的影響和服務(wù)器端TCP流突發(fā)對(duì)其他流的影響.

2 TCP-HAS算法設(shè)計(jì)

本節(jié)將結(jié)合DASH的傳輸特點(diǎn)，基于TCP Vegas[14]擁塞控制算法給出TCP-HAS的設(shè)計(jì)思路.TCP-HAS主要分為4個(gè)功能模塊：1)初始擁塞窗口設(shè)置；2)帶寬估測(cè)；3)最佳碼率分片選擇；4)OFF階段重新設(shè)定擁塞窗口和慢啟動(dòng)門限值.具體的架構(gòu)如圖5所示:

Fig. 5 TCP-HAS architecture圖5 TCP-HAS 總體架構(gòu)

帶寬估測(cè)是在整個(gè)視頻傳輸過程中都在進(jìn)行的，視頻傳輸開始時(shí)根據(jù)服務(wù)器端視頻片段碼率來選擇初始擁塞窗口值，慢啟動(dòng)的窗口增長(zhǎng)方式是指數(shù)上升，進(jìn)入擁塞避免階段后采取基于時(shí)延的擁塞控制算法，同時(shí)在遇到網(wǎng)絡(luò)擁塞事件和空閑事件時(shí)，根據(jù)帶寬估測(cè)值重新調(diào)整擁塞窗口cwnd和慢啟動(dòng)門限ssthresh.

2.1 初始擁塞窗口設(shè)置

TCP-HAS在慢啟動(dòng)階段的cwnd呈指數(shù)增加.由于客戶端的初始緩沖時(shí)延對(duì)于用戶的體驗(yàn)有著非常重要的影響，因此TCP-HAS根據(jù)當(dāng)前服務(wù)器端的索引文件來獲取分片的最低碼率，根據(jù)碼率來設(shè)置初始擁塞窗口，如式(1)所示：

(1)

其中，min_bitrate為視頻分段的最小播放碼率；MSS為TCP最大報(bào)文長(zhǎng)度，以太網(wǎng)中MSS=1 460 B.TCP連接初始擁塞窗口TCP_INIT_CWND取cwnd和10中的較大值.

TCP_INIT_CWND=max(cwnd,10).

(2)

2.2 帶寬估計(jì)

TCP-HAS采用TIBET[15]來進(jìn)行帶寬估計(jì)，通過估測(cè)網(wǎng)絡(luò)中的數(shù)據(jù)包數(shù)來計(jì)算可用帶寬值.

(3)

2.3 最佳碼率選擇

DASH最佳碼率的選擇基于測(cè)得的帶寬Bwe，同時(shí)需要在服務(wù)器端來獲得本視頻的碼率取值范圍，視頻的碼率取值存在于視頻的索引文件中，需要從索引文件中獲取這些值并存儲(chǔ)到數(shù)組中，最佳分片碼率選擇的偽代碼如算法1所示：

算法1.最佳分片碼率選擇.

① fori=Max_EncodingRateto 0,i--

② ifBwe≥EncodingRate[i] then

③ break;

④ end if

⑤ end for

⑥QLevel←i.

算法1中Max_EncodingRate為最高的視頻碼率等級(jí)，依次從最高階向下進(jìn)行判斷，選擇小于帶寬估計(jì)值Bwe的最高碼率等級(jí)，同時(shí)需要考慮該模塊執(zhí)行的時(shí)間點(diǎn)，本方案中最佳分片碼率估計(jì)將會(huì)在網(wǎng)絡(luò)擁塞發(fā)生后和空閑后執(zhí)行.因?yàn)閾砣l(fā)生證明網(wǎng)絡(luò)狀況對(duì)當(dāng)前的視頻傳輸不是很理想，應(yīng)當(dāng)調(diào)整發(fā)送窗口，當(dāng)DASH傳輸出現(xiàn)空閑時(shí)間段時(shí)，意味著網(wǎng)絡(luò)狀況發(fā)生變化，因此為了適應(yīng)這種變化，在傳輸空閑后，該模塊也會(huì)被執(zhí)行.

2.4 OFF階段重新設(shè)定擁塞窗口和慢啟動(dòng)門限值

DASH視頻的傳輸并不是無間斷地傳輸數(shù)據(jù)，可能會(huì)存在不發(fā)送數(shù)據(jù)的空閑狀態(tài)，也可能存在應(yīng)用程序所發(fā)的數(shù)據(jù)量小于擁塞窗口的值，此時(shí)發(fā)送端的擁塞窗口會(huì)一直增長(zhǎng)，導(dǎo)致其不能很好地反映當(dāng)前網(wǎng)絡(luò)帶寬利用情況，當(dāng)一旦有大量數(shù)據(jù)要發(fā)送時(shí)會(huì)立即占滿整個(gè)窗口，造成一定程度的突發(fā)，CWV[16]機(jī)制就是為了防止應(yīng)用程序窗口增長(zhǎng)過大導(dǎo)致突發(fā)而提出的.

(4)

(5)

其中cwnd_used為程序?qū)嶋H使用的窗口大小.

雖然該機(jī)制在一定程度上能夠避免應(yīng)用程序的數(shù)據(jù)突發(fā)問題，但是對(duì)于時(shí)長(zhǎng)通常為幾秒的DASH視頻分片來說，其空閑時(shí)長(zhǎng)遠(yuǎn)超過RTO，導(dǎo)致其跟傳統(tǒng)TCP一樣擁塞窗口最終降為初始值，重新進(jìn)入慢啟動(dòng)階段，當(dāng)擁塞窗口重新爬升到網(wǎng)絡(luò)帶寬閾值時(shí)，通常需要幾百毫秒到幾秒，產(chǎn)生一定的時(shí)延.因此TCP-HAS定義了2種事件：流媒體傳輸空閑事件(idle event)和應(yīng)用程序限制事件(application-limited event)，在檢測(cè)到這2個(gè)事件時(shí)都進(jìn)入TCP_HAS進(jìn)行處理.

1) 流媒體傳輸空閑事件的檢測(cè).流媒體服務(wù)器在收到新的請(qǐng)求時(shí)，計(jì)算該時(shí)刻距上一次數(shù)據(jù)報(bào)文發(fā)送的時(shí)間差，并判斷是否發(fā)生超時(shí)，若發(fā)生超時(shí)，表明出現(xiàn)流媒體傳輸空閑事件.

2) 應(yīng)用程序限制事件的檢測(cè).流媒體服務(wù)器在用戶連接數(shù)目超出負(fù)荷能力時(shí)，對(duì)數(shù)據(jù)的讀取成為瓶頸，如果TCP連接中未確認(rèn)的數(shù)據(jù)報(bào)文數(shù)目小于擁塞窗口的一半，則發(fā)生了應(yīng)用程序限制事件.

檢測(cè)到流媒體傳輸空閑事件和應(yīng)用程序限制事件后，進(jìn)入TCP_HAS擁塞控制算法.TCP_HAS會(huì)結(jié)合當(dāng)前所估測(cè)的網(wǎng)絡(luò)帶寬和分片碼率，選擇小于帶寬估計(jì)值Bwe的最高碼率，并重置ssthresh和cwnd.TCP-HAS算法將ssthresh的值作調(diào)整：

ssthresh=EncodingRate[Qlevel]×RTT×λ,

(6)

其中EncodingRate[QLevel]是根據(jù)可用帶寬估計(jì)出的最優(yōu)碼率，設(shè)置系數(shù)λ(λ>1)是為了確保傳輸碼率大于需要的播放碼率，本文設(shè)置λ=1.2.設(shè)置cwnd=ssthresh，這樣做的好處是避免了在空閑時(shí)間段后將擁塞窗口減為初始值，以便減小傳輸下一個(gè)分片時(shí)所存在的時(shí)延，同時(shí)ssthresh能夠使得客戶端在長(zhǎng)時(shí)間的空閑后獲得一個(gè)合理的速率.慢啟動(dòng)門限值和擁塞窗口的調(diào)整是同步的.TCP-HAS算法的偽代碼如算法2所示：

算法2.TCP-HAS算法.

① if 流媒體傳輸空閑事件或者應(yīng)用程序限制事件被檢測(cè)到 then

② 估計(jì)可用帶寬Bwe;

③ 選擇最佳碼率QLevel;

④ssthresh←EncodingRate[QLevel]×

RTT×λ;

⑤cwnd←ssthresh;

⑥ end if

如果流媒體傳輸空閑事件和應(yīng)用程序限制事件都沒有被檢測(cè)到，則TCP-HAS算法退化為TCP Vegas算法.

3 實(shí)驗(yàn)與分析

本節(jié)將搭建實(shí)際的網(wǎng)絡(luò)環(huán)境來驗(yàn)證分析TCP-HAS的合理性.由于當(dāng)前Linux內(nèi)核默認(rèn)的擁塞控制算法為CUBIC，因此首先在無隨機(jī)丟包的網(wǎng)絡(luò)環(huán)境下，分別在單條和多條流傳輸時(shí)，從擁塞窗口、網(wǎng)絡(luò)QoS和客戶端QoE[17]對(duì)比分析TCP-HAS和CUBIC的傳輸性能.

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

本實(shí)驗(yàn)平臺(tái)采用服務(wù)器客戶端的模式，主要由2臺(tái)Linux主機(jī)和2臺(tái)路由器組成.其中1臺(tái)PC機(jī)作為客戶端，另外1臺(tái)作為服務(wù)器端，并在中間設(shè)置1個(gè)路由器來模擬端到端的往返時(shí)延和丟包率.Linux系統(tǒng)采用CentOS6.9，內(nèi)核源代碼版本使用4.10.此外本實(shí)驗(yàn)平臺(tái)客戶端播放器采用VLC[18]，視頻服務(wù)器采用Nginx.具體的網(wǎng)絡(luò)環(huán)境拓?fù)淙鐖D6所示.

實(shí)驗(yàn)采用路由器中的sch_netem模塊來模擬實(shí)際網(wǎng)絡(luò)環(huán)境，模塊中的tc命令可以根據(jù)實(shí)驗(yàn)需求來設(shè)置不同的時(shí)延，通過ethtool工具來設(shè)置網(wǎng)卡速率.

本實(shí)驗(yàn)采用ITEC的DASH Dataset[19]數(shù)據(jù)來進(jìn)行實(shí)驗(yàn)，視頻為大雄兔BigBuckBunny，它是由開源軟件Blender所制作的動(dòng)畫短片，時(shí)長(zhǎng)為10 min左右，包含320×240，480×360，854×480，1 280×720，1 920×1 080這5種分辨率，片段時(shí)長(zhǎng)有1 s，2 s，4 s，6 s，10 s，15 s共6種，時(shí)長(zhǎng)為4 s的碼率有46 Kbps，89 Kbps，…，4.2 Mbps，如圖7所示.

中西醫(yī)結(jié)合治療2型糖尿病的研究較多，絕大多數(shù)的研究顯示中西醫(yī)結(jié)合治療可以提升療效，主要表現(xiàn)為提高血糖控制率、調(diào)節(jié)血脂、控制體重等。一項(xiàng)基于8個(gè)研究的Meta分析了六味地黃丸治療2型糖尿病的系統(tǒng)評(píng)價(jià)顯示，總有效率達(dá)到80%～97%。觀察組對(duì)對(duì)象的總有效率也達(dá)到97.73%，優(yōu)于Meta分析[3]?？赡茉?yàn)椋孩僭摻M對(duì)象采用二甲雙胍血糖得到控制；②治療時(shí)間為8周，其它文獻(xiàn)多在4周；③該組對(duì)象的病情較輕，癥狀積分在14～15分，而其他文獻(xiàn)報(bào)道主要在16～22分；④相較于六味地黃丸，加味六味地黃丸的辯證效果更顯著，有助于控制兼證，采用煎劑有助于藥物有效成分的析出。

客戶端采用的播放器為VLC，可通過URL來訪問服務(wù)器進(jìn)行視頻的點(diǎn)播.為了獲得視頻播放過程中的窗口、時(shí)延等信息，本實(shí)驗(yàn)在視頻服務(wù)器端使用Linux的內(nèi)核模塊tcp_probe來監(jiān)聽特定TCP連接的各個(gè)參數(shù).

Fig. 6 Experimental topology圖6 實(shí)驗(yàn)拓?fù)鋱D

Fig. 7 Video slicing and transmission process圖7 視頻切片及傳輸過程

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

發(fā)送端擁塞窗口反映了能夠有多少數(shù)據(jù)發(fā)送到網(wǎng)絡(luò)中，過大的擁塞窗口會(huì)造成TCP流的突發(fā)，過小的擁塞窗口又限制了TCP流的發(fā)送速率，因此設(shè)置合適的擁塞窗口大小對(duì)TCP流的傳輸性能具有重要意義.同時(shí)網(wǎng)絡(luò)QoS和客戶端QoE也是衡量TCP傳輸性能的關(guān)鍵指標(biāo).因此本節(jié)在無隨機(jī)丟包的網(wǎng)絡(luò)環(huán)境下進(jìn)行實(shí)驗(yàn)，分別在單條和多條流的情況下，從cwnd的變化和網(wǎng)絡(luò)QoS參數(shù)對(duì)TCP-HAS和CUBIC進(jìn)行對(duì)比分析.最后通過客戶端QoE指標(biāo)、碼率切換頻率來對(duì)比分析TCP-HAS和CUBIC.

3.2.1 擁塞窗口變化分析

1) 10 Mbps，無隨機(jī)丟包率，單條流

圖8是TCP-HAS與CUBIC在帶寬為10 Mbps、隨機(jī)丟包率為0%條件下，單個(gè)用戶播放視頻時(shí)發(fā)送端的擁塞窗口變化圖.可以看出CUBIC比較激進(jìn)，前50 s階段cwnd上升到80，丟包發(fā)生后降為60，波動(dòng)幅度比較大，隨后在DASH流傳輸業(yè)務(wù)ON-OFF模式下出現(xiàn)了更為劇烈的窗口波動(dòng)，空閑后降為初始值重新進(jìn)入慢啟動(dòng)，并且間隔時(shí)間剛好為片段時(shí)長(zhǎng)4 s.而TCP-HAS前50 s階段cwnd始終在45附近，并且波動(dòng)幅度較小，50 s之后在ON-OFF的傳輸模式下窗口變化也比較平穩(wěn).

Fig. 8 cwnd variation of TCP-HAS and CUBIC圖8 TCP-HAS和CUBIC的cwnd變化圖

2) 10 Mbps，無隨機(jī)丟包率，兩條流

圖9和圖10分別是CUBIC和TCP-HAS在2條流共享帶寬時(shí)的cwnd變化值.兩者在DASH流發(fā)生空閑后cwnd都發(fā)生了劇烈的波動(dòng)，由于2條流發(fā)生空閑的時(shí)間段不同，因此cwnd交替增長(zhǎng).但是TCP-HAS比CUBIC的整體波動(dòng)幅度要小得多.

Fig. 9 cwnd variation of two competitive CUBIC flows圖9 2條CUBIC競(jìng)爭(zhēng)流的cwnd變化圖

Fig. 10 cwnd variation of two competitive TCP-HAS flows圖10 2條TCP-HAS競(jìng)爭(zhēng)流的cwnd變化圖

3.2.2 QoS指標(biāo)分析

1) 丟包率

圖11所示為單個(gè)用戶播放視頻時(shí)100 s內(nèi)CUBIC和TCP-HAS的丟包率變化圖，可以看出CUBIC在初始時(shí)刻的丟包率較高，隨后趨于穩(wěn)定，而TCP-HAS在整個(gè)傳輸過程中幾乎沒有丟包.主要是因?yàn)镃UBIC的競(jìng)爭(zhēng)性比較大，在初始時(shí)刻希望盡快占用可用帶寬，因此丟包率也高.

Fig. 11 Single stream packet loss rate of CUBIC and TCP-HAS圖11 CUBIC和TCP-HAS單條流丟包率變化圖

圖12和圖13分別是CUBIC和TCP-HAS在2個(gè)用戶共享帶寬時(shí)的丟包率變化圖.CUBIC和TCP-HAS的第2個(gè)用戶都是在30 s后開啟，并出現(xiàn)了短暫的高丟包，隨后CUBIC兩條流的丟包率逐漸趨于一致，而TCP-HAS第1條流丟包率始終為0.總體上CUBIC的丟包率更高.

Fig. 12 Packet loss rate of two CUBIC DASH flows圖12 2條CUBIC DASH流的丟包率變化圖

Fig. 13 Packet loss rate of two TCP-HAS DASH flows圖13 2條TCP-HAS DASH流的丟包率變化圖

根據(jù)圖11～13的實(shí)驗(yàn)結(jié)果，TCP-HAS在丟包率這一指標(biāo)上要優(yōu)于CUBIC.

2) 往返時(shí)延和抖動(dòng)

圖14是CUBIC和TCP-HAS在單個(gè)用戶播放視頻時(shí)的RTT概率累積分布圖.可以很明顯看出CUBIC的往返時(shí)延在80～100 ms區(qū)間所占的比例為60%左右，而TCP-HAS的往返時(shí)延幾乎全部落在55～65 ms之間，可見CUBIC的總體RTT值要遠(yuǎn)大于TCP-HAS的RTT值.

Fig. 14 RTT CDF of TCP-HAS and CUBIC圖14 TCP-HAS和CUBIC往返時(shí)延CDF圖

圖15和圖16分別是CUBIC和TCP-HAS在2個(gè)用戶共享帶寬時(shí)的RTT概率累積分布圖，結(jié)果與圖14類似，唯一不同之處是CUBIC第2條流的往返時(shí)延要小于第1條流，而TCP-HAS恰好相反.

Fig. 15 RTT CDF of two competing CUBIC DASH flows圖15 CUBIC的2條DASH競(jìng)爭(zhēng)流的往返時(shí)延CDF圖

Fig. 16 RTT CDF of two competing TCP-HAS DASH flows圖16 TCP-HAS的2條DASH競(jìng)爭(zhēng)流的往返時(shí)延CDF圖

圖17是CUBIC和TCP-HAS在單個(gè)用戶播放視頻時(shí)的RTT變化圖，可以看出CUBIC的時(shí)延抖動(dòng)范圍為60～120 ms，TCP-HAS的抖動(dòng)范圍為60～80 ms.

Fig. 17 RTT variation of TCP-HAS and CUBIC圖17 TCP-HAS和CUBIC往返時(shí)延變化圖

圖18和圖19分別是CUBIC和TCP-HAS在2個(gè)用戶播放視頻時(shí)的RTT變化圖，總體上CUBIC的抖動(dòng)頻率還是要比TCP-HAS大，但CUBIC在第2條流開啟后抖動(dòng)范圍幾乎不變，而TCP-HAS卻發(fā)生了劇烈的抖動(dòng).

Fig. 18 RTT variation of two competing CUBIC DASH flows圖18 CUBIC的2條DASH競(jìng)爭(zhēng)流的RTT變化圖

在時(shí)延和時(shí)延抖動(dòng)方面，TCP-HAS的整體性能要優(yōu)于CUBIC.

3.2.3 QoE指標(biāo)分析

對(duì)自適應(yīng)流媒體來說，影響QoE的主要因素有初始緩沖延遲、視頻卡頓、碼率或者分辨率切換次數(shù)、吞吐量等.初始緩沖時(shí)延是從客戶端發(fā)出HTTP請(qǐng)求到開始播放的時(shí)間長(zhǎng)度，一般來說實(shí)時(shí)流媒體或短視頻流對(duì)初始緩沖時(shí)延更為敏感.視頻碼率和分辨率的切換次數(shù)也是影響客戶端QoE的最重要因素，在網(wǎng)絡(luò)狀況發(fā)生改變時(shí)，視頻碼率和分辨率會(huì)進(jìn)行切換以避免緩沖區(qū)過載，以此來保證視頻的流暢播放，但如果切換得太頻繁，并不斷地從較高碼率切換到較低碼率的視頻片段，這種情況就會(huì)使用戶的觀影體驗(yàn)大大降低，因此視頻碼率也需要在適應(yīng)網(wǎng)絡(luò)變化的同時(shí)維持在一個(gè)合理的波動(dòng)范圍內(nèi).吞吐量也是衡量QoE大小的一個(gè)指標(biāo)，但需要結(jié)合其他因素來綜合評(píng)估，吞吐量越高也不能說明用戶的觀影體驗(yàn)越好.本文綜合各方面因素，選擇視頻碼率切換次數(shù)來作為衡量QoE的指標(biāo).

碼率信息存儲(chǔ)在HTTP GET請(qǐng)求中，因此可以通過分析pcap數(shù)據(jù)包的HTTP請(qǐng)求來統(tǒng)計(jì)碼率切換次數(shù).

1) 單個(gè)用戶

如圖20和圖21所示，當(dāng)客戶端為單個(gè)用戶時(shí)，由于視頻片段最大碼率為4 Mbps，小于帶寬10 Mbps，因此這種情況下TCP-HAS和CUBIC的碼率變化趨勢(shì)一樣，從最低碼率迅速切換為最大碼率并維持穩(wěn)定不變.

Fig. 20 Single user bitrate switching of CUBIC圖20 CUBIC單個(gè)用戶碼率切換圖

Fig. 21 Single user bitrate switching of TCP-HAS圖21 TCP-HAS單個(gè)用戶碼率切換圖

2) 2個(gè)用戶

Fig. 22 Two users bitrate switching of CUBIC圖22 CUBIC的2個(gè)用戶碼率切換圖

當(dāng)2個(gè)用戶同時(shí)播放時(shí)，采用CUBIC擁塞控制算法時(shí)，2個(gè)播放器的碼率變化此起彼伏，產(chǎn)生了一種交叉變化的現(xiàn)象，如圖22所示.這種現(xiàn)象正是由于分片傳輸?shù)腛N-OFF所模式造成的.當(dāng)用戶1處于OFF時(shí)間段時(shí)，用戶2估測(cè)到的帶寬值比較大，會(huì)請(qǐng)求較高碼率分片，而一旦用戶1要請(qǐng)求分片時(shí)，其估測(cè)到的網(wǎng)絡(luò)帶寬值比用戶2所估測(cè)到的要小，于是切換為較低的碼率，同時(shí)用戶2也受用戶1的影響頻繁切換碼率.如圖23所示，采用TCP-HAS擁塞控制算法時(shí)，由于在空閑和應(yīng)用程序限制2種狀態(tài)下對(duì)慢啟動(dòng)門限值重新設(shè)置，使得兩者的碼率波動(dòng)范圍變小.

Fig. 23 Two users bitrate switching of TCP-HAS圖23 TCP-HAS的2個(gè)用戶碼率切換圖

4 結(jié)束語

本文優(yōu)化了TCP擁塞控制算法來適應(yīng)DASH視頻傳輸，將帶寬與碼率相結(jié)合，基于TCP Vegas提出了TCP-HAS，并在Linux服務(wù)器端進(jìn)行修改，客戶端無需任何修改.TCP-HAS在DASH流媒體傳輸出現(xiàn)空閑后，通過估測(cè)的帶寬值來選擇最佳分片碼率，并根據(jù)碼率重新計(jì)算cwnd和ssthresh，能夠較好地適應(yīng)DASH流媒體ON-OFF的傳輸特點(diǎn).相比CUBIC來說，雖然TCP-HAS比較保守，但它具有較小的往返時(shí)延和丟包率，而且TCP流窗口波動(dòng)也比較小，能夠在多個(gè)用戶同時(shí)競(jìng)爭(zhēng)帶寬時(shí)獲得較好的QoS和QoE.由于實(shí)驗(yàn)環(huán)境的限制，本文無法針對(duì)大量客戶端進(jìn)行實(shí)驗(yàn)分析，這是本文的缺點(diǎn)之一.同時(shí)TCP-HAS流在與CUBIC流競(jìng)爭(zhēng)時(shí)仍處于劣勢(shì)，這也是基于時(shí)延擁塞控制算法的缺點(diǎn).本文后續(xù)的研究工作將基于上述2個(gè)問題展開.

當(dāng)前國內(nèi)外許多大型視頻服務(wù)提供商如YouTube、Netflix、騰訊、優(yōu)酷和搜狐等都將DASH作為主流的視頻傳輸技術(shù)，而YouTube所屬的Google公司針對(duì)視頻傳輸也對(duì)TCP協(xié)議作了許多創(chuàng)新性修改，并在YouTube服務(wù)器上部署應(yīng)用.針對(duì)自適應(yīng)流媒體的傳輸協(xié)議優(yōu)化是十分必要的，并且未來還有許多新的研究和改進(jìn)的空間.