王國(guó)棟，任勇毛，李俊

(1.中國(guó)科學(xué)院 計(jì)算機(jī)網(wǎng)絡(luò)信息中心，北京 100190；2.中國(guó)科學(xué)院 研究生院，北京 100049)

1 引言

隨著信息技術(shù)的快速發(fā)展和科研活動(dòng)信息化水平的日益提高，互聯(lián)網(wǎng)逐漸成為科研工作者進(jìn)行科學(xué)研究的工具。例如在高能物理方面，歐洲粒子物理研究中心(CERN)的大型粒子對(duì)撞機(jī)每年產(chǎn)生幾十PB的數(shù)據(jù)[1]，這些數(shù)據(jù)需要通過高速網(wǎng)絡(luò)傳送到全球各個(gè)研究中心進(jìn)行處理和分析。在天文學(xué)領(lǐng)域，天文學(xué)家采用甚長(zhǎng)基線干涉測(cè)量法（VLBI,very long baseline interferometry）由分布于全球的儀器采集數(shù)據(jù)并通過高速網(wǎng)絡(luò)進(jìn)行匯聚，從而獲得詳細(xì)的天文圖像[2]。在生物信息領(lǐng)域，全球各大測(cè)序中心每年都產(chǎn)生大量的基因序列數(shù)據(jù)，這些數(shù)據(jù)通過高速網(wǎng)絡(luò)供全球用戶獲取[3]。這些科研應(yīng)用的發(fā)展，也對(duì)高速網(wǎng)絡(luò)的傳輸性能提出了越來越高的要求。

在高速網(wǎng)絡(luò)傳輸方面，高速網(wǎng)絡(luò)基礎(chǔ)設(shè)施已經(jīng)出現(xiàn)，但是研究人員卻無(wú)法有效利用網(wǎng)絡(luò)帶寬，因?yàn)閭鹘y(tǒng)的傳輸協(xié)議嚴(yán)重影響著高速網(wǎng)絡(luò)的傳輸性能。針對(duì)傳輸協(xié)議在高速網(wǎng)絡(luò)中的各種缺陷，研究人員提出了許多基于標(biāo)準(zhǔn)TCP的改進(jìn)協(xié)議。這些改進(jìn)協(xié)議針對(duì)現(xiàn)有協(xié)議的某些缺點(diǎn)做出了改進(jìn)，使得部分性能有所提高，但是這些改進(jìn)協(xié)議在高速長(zhǎng)距離網(wǎng)絡(luò)環(huán)境中的性能如何，能否滿足e-Science等科研應(yīng)用的需要，針對(duì)這些問題，迫切需要對(duì)現(xiàn)有的改進(jìn)協(xié)議做出評(píng)價(jià)。

對(duì)TCP傳輸協(xié)議的評(píng)價(jià)，研究人員已經(jīng)做了一部分工作，其中，文獻(xiàn)[4]對(duì)CUBIC協(xié)議進(jìn)行了評(píng)價(jià)并與標(biāo)準(zhǔn)TCP的性能進(jìn)行了比較。文獻(xiàn)[5]通過NS2仿真軟件對(duì)TCP傳輸協(xié)議進(jìn)行了簡(jiǎn)單的分析，但是其僅僅評(píng)價(jià)了TCP的效率和穩(wěn)定性2個(gè)方面。文獻(xiàn)[6]對(duì) Illinois和CTCP的性能進(jìn)行了評(píng)價(jià)。文獻(xiàn)[7]在無(wú)線局域網(wǎng)絡(luò)環(huán)境下對(duì)Vegas、Fast TCP、CTCP和ARENO的性能進(jìn)行了評(píng)價(jià)。文獻(xiàn)[9]和文獻(xiàn)[10]在實(shí)驗(yàn)室環(huán)境下對(duì)快速啟動(dòng)TCP協(xié)議進(jìn)行了評(píng)價(jià)。文獻(xiàn)[11]評(píng)價(jià)了3種不同TCP協(xié)議在進(jìn)行H.264 SVC（H.264可分級(jí)編碼）流傳輸時(shí)的性能。綜上所述，目前對(duì)TCP傳輸協(xié)議的性能評(píng)價(jià)主要存在以下不足。首先是評(píng)價(jià)的范圍不夠廣，沒有對(duì)目前存在的協(xié)議進(jìn)行全面系統(tǒng)的分析，而往往是針對(duì)某一個(gè)或幾個(gè)協(xié)議進(jìn)行比較。其次是評(píng)價(jià)的手段不夠全面，由于真實(shí)的高速長(zhǎng)距離網(wǎng)絡(luò)資源的稀缺，大部分評(píng)價(jià)工作采用仿真軟件進(jìn)行仿真或者在實(shí)驗(yàn)室環(huán)境下進(jìn)行模擬，而對(duì)TCP傳輸協(xié)議在真實(shí)網(wǎng)絡(luò)環(huán)境中的性能的評(píng)價(jià)還不多見。針對(duì)以上問題，本文首先利用仿真軟件對(duì)目前典型的TCP傳輸協(xié)議進(jìn)行了全面的、系統(tǒng)的評(píng)價(jià)分析。在此基礎(chǔ)之上，充分利用中國(guó)科技網(wǎng)的網(wǎng)絡(luò)資源優(yōu)勢(shì)在實(shí)際網(wǎng)絡(luò)中對(duì)目前典型的TCP傳輸協(xié)議的性能進(jìn)行了研究。

2 TCP改進(jìn)協(xié)議分類描述

標(biāo)準(zhǔn)TCP協(xié)議在高速網(wǎng)絡(luò)中存在的主要問題是其加性增、乘性減(AIMD，additive increase multiplicative decrease)的窗口調(diào)整策略。Floyd[12]指出，在高速網(wǎng)絡(luò)中，如果要充分利用帶寬，這個(gè)約束條件會(huì)導(dǎo)致不現(xiàn)實(shí)的分組丟失率(2×10-10)。擁塞減半后加性增加擁塞窗口需要大量時(shí)間(1.16 h)才能恢復(fù)到10 Gbit/s的吞吐率。因此對(duì)標(biāo)準(zhǔn)TCP協(xié)議的改進(jìn)，主要集中在擁塞控制窗口(congestion control window)的管理機(jī)制上。根據(jù)擁塞檢測(cè)機(jī)制的不同，改進(jìn)協(xié)議可以分為以下幾類：基于分組丟失反饋的改進(jìn)協(xié)議(LCA，loss-based congestion algorithm)，基于時(shí)延反饋的改進(jìn)協(xié)議(DCA，delay-based congestion algorithm)，基于LCA和DCA的混合反饋改進(jìn)協(xié)議(CCA，compound congestion algorithm)，基于可用帶寬測(cè)量的改進(jìn)協(xié)議及基于路由器顯式反饋(explicit notification)的改進(jìn)協(xié)議。表1對(duì)各類協(xié)議進(jìn)行了分類總結(jié)。

2.1 基于分組丟失反饋的改進(jìn)協(xié)議

2.1.1 HSTCP

HSTCP[12]采用高/低速模式切換的工作方式，通過α(ω)和β(ω)調(diào)整窗口變化速率。當(dāng)擁塞窗口較小時(shí)，HSTCP采用類似于傳統(tǒng)TCP協(xié)議的窗口增長(zhǎng)和分組丟失遞減方式，當(dāng)擁塞窗口較大時(shí)，采用更加積極的窗口增長(zhǎng)和更加緩和的窗口減少算法。

2.1.2 STCP（scalable TCP）

STCP[13]采用MIMD(multiplicative increase multiplicative decrease)代替AIMD來調(diào)整擁塞窗口。對(duì)于每個(gè)RTT，在擁塞避免階段，cwnd=cwnd +α×cwnd(α=0.01)，在快速恢復(fù)階段，cwnd=cwnd -β×cwnd(β=0.125)。

2.1.3 BIC

BIC[14]的主要特點(diǎn)是它獨(dú)特的窗口增長(zhǎng)函數(shù)，它由二進(jìn)制搜索增長(zhǎng)和線性增長(zhǎng)兩部分組成。二進(jìn)制搜索類似于經(jīng)典的折半查找算法，首先假設(shè)擁塞窗口的最大值max和最小值min，并取其中值TW(target window = (max +min)/2)作為目標(biāo)窗口增長(zhǎng)cwnd。如果沒有發(fā)生分組丟失，則取當(dāng)前窗口作為min繼續(xù)進(jìn)行二進(jìn)制搜索增長(zhǎng)cwnd；如果發(fā)生分組丟失，則更改當(dāng)前窗口為max，并重新進(jìn)行二進(jìn)制搜索增長(zhǎng)cwnd。如果當(dāng)前窗口距離TW過大，則采用線性增長(zhǎng)輔助增加cwnd。

2.1.4 CUBIC

CUBIC[15]是BIC的一個(gè)改進(jìn)版本，試圖在保留BIC優(yōu)點(diǎn)的基礎(chǔ)上，簡(jiǎn)化窗口控制并增強(qiáng)它的TCP友好性和RTT公平性。

表1 TCP改進(jìn)協(xié)議分類描述

2.1.5 HTCP

HTCP[16]采用上次擁塞事件以來逝去的時(shí)間 Δ來檢測(cè)網(wǎng)絡(luò)擁塞程度。AIMD的調(diào)整因子為α(Δ)，α(Δ)隨著Δ的變化進(jìn)行動(dòng)態(tài)調(diào)整，從而調(diào)整AIMD的窗口變化速率。

2.1.6 Libra

Libra[17]是在New Reno[18]的基礎(chǔ)上改進(jìn)而來的，其主要目的是為了提高New Reno的RTT公平性和可擴(kuò)展性。

2.1.7 Hybla

與Libra類似，Hybla[19]的主要目的也是為了解決New Reno的RTT公平性問題。Hybla通過引入RTT的參考值RTTref(默認(rèn)為25 ms)，并取 ρ=RTT/RTTref來調(diào)節(jié)不同RTT的擁塞窗口增長(zhǎng)速率。

2.2 基于時(shí)延反饋的改進(jìn)協(xié)議

2.2.1 Fast TCP

Fast TCP[8,20]以隊(duì)列延時(shí)作為反饋因子，利用發(fā)送端檢測(cè)到的ACK時(shí)延變化來調(diào)整擁塞窗口。其擁塞窗口調(diào)整算法如下：

其中，baseRTT表示所觀測(cè)到的最小RTT，α表示一個(gè)非負(fù)的修正因子。

2.2.2 Vegas

Vegas[21]是基于時(shí)延反饋協(xié)議的代表。它通過觀測(cè)TCP連接中的RTT時(shí)延變化來調(diào)節(jié)擁塞窗口。如果發(fā)現(xiàn)RTT變大，則認(rèn)為網(wǎng)絡(luò)發(fā)生擁塞，相應(yīng)的減小擁塞窗口。如果發(fā)現(xiàn)RTT變小，則認(rèn)為擁塞已經(jīng)解除，并增加擁塞窗口。如果RTT保持不變，則不改變擁塞窗口的大小。

2.2.3 Hybrid Slow Start TCP

Hybrid Slow Start TCP[22]利用了網(wǎng)絡(luò)測(cè)量技術(shù)中的packet-pair[23]測(cè)量技術(shù)和packet-train[24]測(cè)量技術(shù)，通過“ACK train length”和“Delay increase”來決定TCP何時(shí)從慢啟動(dòng)階段轉(zhuǎn)換到擁塞避免階段。

2.3 基于分組丟失和時(shí)延混合反饋的改進(jìn)協(xié)議

2.3.1 CTCP

CTCP[25](compound TCP)將基于分組丟失的CAA(congestion avoidance algorithm)和基于時(shí)延的CAA相結(jié)合，在保證了較高的帶寬利用率的情況下，又獲得了較好的公平性。基于時(shí)延的CAA是通過引入dwnd(delay window)來實(shí)現(xiàn)的，協(xié)議中的發(fā)送窗口為win=min(cwnd+dwnd，awnd)，其中，awnd是來自接收端的廣播窗口。相應(yīng)的在擁塞避免階段，每收到一個(gè)ACK，窗口大小調(diào)整為cwnd=cwnd+1/win，而在慢啟動(dòng)階段，CTCP保留了Reno TCP的慢啟動(dòng)策略。

2.3.2 Africa

TCP Africa[26](adaptive and fair rapid increase congestion avoidance)將網(wǎng)絡(luò)狀態(tài)分為擁塞和無(wú)擁塞2個(gè)狀態(tài)，并且利用Vegas的RTT延時(shí)來判斷這2種狀態(tài)。當(dāng)網(wǎng)絡(luò)無(wú)擁塞時(shí)，協(xié)議進(jìn)入類似于HSTCP的快速增長(zhǎng)模式；在網(wǎng)絡(luò)逼近擁塞時(shí)，TCP Africa進(jìn)入類似于傳統(tǒng)TCP的慢速增長(zhǎng)模式。

2.3.3 Illinois

Illinois[27]同樣考慮到LCA和DCA的局限性，提出了采用兩者相結(jié)合的算法。與CTCP和Africa類似，都是將網(wǎng)絡(luò)狀態(tài)分為擁塞和無(wú)擁塞2種狀態(tài)，但是在這2種狀態(tài)下對(duì)擁塞窗口的調(diào)整策略不同。對(duì)于Illinois而言，在擁塞避免階段，每個(gè)RTT: cwnd = cwnd+ α，而當(dāng)檢測(cè)到分組丟失時(shí)，cwnd = cwnd – β · cwnd。

2.3.4 YeAH

YeAH[28](yet another high-speed TCP)將網(wǎng)絡(luò)劃分為“Fast”和“slow”2個(gè)狀態(tài)。在“Fast”狀態(tài)下，擁塞窗口使用更加迅速的方式增加(STCP)，在“slow”狀態(tài)下，擁塞窗口使用較溫和的方式增加(Reno TCP)，以避免網(wǎng)絡(luò)擁塞的產(chǎn)生。在此基礎(chǔ)上，當(dāng)網(wǎng)絡(luò)擁塞超過閾值時(shí)，將路由器緩存中的分組取出，來進(jìn)一步緩解擁塞。

2.4 基于可用帶寬測(cè)量的改進(jìn)協(xié)議

2.4.1 Westwood

Westwood[29]和westwood+[30]是典型的基于網(wǎng)絡(luò)帶寬測(cè)量的TCP協(xié)議。Westwood通過計(jì)算最近過去(recent past)的帶寬來調(diào)整擁塞窗口的變化。網(wǎng)絡(luò)帶寬是通過記錄一段時(shí)間之內(nèi)(以ACK為標(biāo)準(zhǔn))所發(fā)送的數(shù)據(jù)來得到的。 Westwood+改進(jìn)了網(wǎng)絡(luò)帶寬的測(cè)量機(jī)制，分別用“被確認(rèn)了”的數(shù)據(jù)來代替發(fā)送的數(shù)據(jù)，用RTT來代替ACK來獲得傳輸時(shí)間，這一改進(jìn)大大提高了網(wǎng)絡(luò)帶寬測(cè)量的準(zhǔn)確性。

2.4.2 ARENO

ARENO[31](adaptive RENO)是一個(gè)基于帶寬測(cè)量的TCP改進(jìn)協(xié)議，旨在改進(jìn)TCP的效率和TCP的友好性。它具有2個(gè)窗口增加機(jī)制，Wbase和Wprobe。在Wbase階段，每個(gè)RTT增加一個(gè)CWND，在Wprobe階段，每個(gè)RTT增加的CWND根據(jù)所測(cè)量的網(wǎng)絡(luò)帶寬動(dòng)態(tài)調(diào)整。ARENO的帶寬測(cè)量機(jī)制類似于Westwood。

2.4.3 Fusion

Fusion[32]與ARENO類似，結(jié)合westwood的帶寬測(cè)量和vegas的網(wǎng)絡(luò)緩存預(yù)測(cè)機(jī)制。Fusion定義了3個(gè)線性增長(zhǎng)函數(shù)，根據(jù)不同的隊(duì)列延時(shí)，動(dòng)態(tài)切換這3個(gè)增長(zhǎng)函數(shù)。另外，當(dāng)網(wǎng)絡(luò)分組丟失時(shí)，根據(jù)RTT的不同，將擁塞窗口減小到相應(yīng)的程度。

2.5 基于顯式擁塞通告的改進(jìn)協(xié)議

基于顯式擁塞通告的改進(jìn)協(xié)議的代表主要有XCP[33]和VCP[34]。XCP為數(shù)據(jù)分組增加了擁塞報(bào)頭，由發(fā)送端寫入當(dāng)前的窗口大小和RTT估計(jì)值，為路由器計(jì)算可用帶寬提供信息。VCP采用IP報(bào)頭的冗余位作為負(fù)載因子向發(fā)送端傳遞網(wǎng)絡(luò)擁塞狀況?；陲@示反饋的TCP協(xié)議還有JetMax[35]、EVLFTCP[36]、CLTCP[37]，這類協(xié)議的最大問題就是可擴(kuò)展性差。由于這類協(xié)議需要路由器支持，實(shí)際部署會(huì)比較困難，因此本文不再詳述和評(píng)價(jià)此類協(xié)議。

3 TCP傳輸協(xié)議評(píng)價(jià)標(biāo)準(zhǔn)及評(píng)價(jià)方法

對(duì)于傳輸協(xié)議的性能評(píng)價(jià)是個(gè)很大的研究課題，一直是比較熱門的研究領(lǐng)域。進(jìn)行性能評(píng)價(jià)，需要考慮2個(gè)因素：一是評(píng)價(jià)標(biāo)準(zhǔn)，二是評(píng)價(jià)方法。

3.1 評(píng)價(jià)標(biāo)準(zhǔn)

評(píng)價(jià)標(biāo)準(zhǔn)是影響評(píng)價(jià)結(jié)果的一個(gè)重要因素。對(duì)于傳輸協(xié)議的評(píng)價(jià)標(biāo)準(zhǔn)，目前并無(wú)定論[38,39]。但是對(duì)于e-Science科研應(yīng)用而言衡量傳輸協(xié)議優(yōu)劣的一個(gè)重要指標(biāo)是傳輸協(xié)議的效率;對(duì)于網(wǎng)絡(luò)自身的性能而言，RTT公平性和TCP友好性也是必要的考慮因素。綜合以上考慮，本文著重從協(xié)議的吞吐率、RTT公平性和協(xié)議之間的友好性進(jìn)行評(píng)價(jià)。

3.2 評(píng)價(jià)方法

評(píng)價(jià)方法也是影響評(píng)價(jià)結(jié)果的重要因素。一般而言，對(duì)于傳輸協(xié)議性能評(píng)價(jià)的方法主要有以下幾種：一種是利用理論模型分析法[40]。一種是采用模擬的實(shí)驗(yàn)方法，NS2是目前學(xué)術(shù)界廣泛使用的一種網(wǎng)絡(luò)模擬平臺(tái)，其實(shí)驗(yàn)結(jié)果受到專業(yè)領(lǐng)域的普遍認(rèn)可。另一種是通過搭建模擬網(wǎng)絡(luò)環(huán)境進(jìn)行實(shí)驗(yàn)[6,41]。還有一種是在實(shí)際網(wǎng)絡(luò)中進(jìn)行測(cè)試[42]。

理論模型分析方法需要建立傳輸模型，這種方法比較復(fù)雜，而且難以保證模型的有效性；采用軟件仿真雖然比較容易控制網(wǎng)絡(luò)的各種參數(shù)，但是其性能依賴所使用的仿真環(huán)境；采用實(shí)驗(yàn)床的方法也僅僅模擬了網(wǎng)絡(luò)的環(huán)境，與實(shí)際網(wǎng)絡(luò)還有差距。在真實(shí)網(wǎng)絡(luò)中進(jìn)行測(cè)試最大的問題是網(wǎng)絡(luò)資源有限，另外背景流量也會(huì)對(duì)實(shí)驗(yàn)結(jié)果產(chǎn)生較大影響。綜合以上分析，為了全面、客觀地反應(yīng)TCP改進(jìn)協(xié)議的性能，本文分別采用仿真和在真實(shí)網(wǎng)絡(luò)中對(duì)TCP傳輸協(xié)議進(jìn)行評(píng)價(jià)。

4 基于NS2的TCP傳輸協(xié)議評(píng)價(jià)

本節(jié)采用NS2仿真工具對(duì)目前流行的TCP改進(jìn)協(xié)議進(jìn)行評(píng)價(jià)。網(wǎng)絡(luò)拓?fù)錇閱纹款i主干鏈路、多接入終端的啞鈴型拓?fù)?。根?jù)隊(duì)列大小理論[43]，隊(duì)列大小為100%BDP（bandwidth delay product），TCP連接的應(yīng)用使用FTP，實(shí)驗(yàn)網(wǎng)絡(luò)拓?fù)淙鐖D1所示。

圖1 NS2仿真實(shí)驗(yàn)拓?fù)?/p>

4.1 單流帶寬利用率

單流帶寬利用率是TCP傳輸協(xié)議傳輸效率的重要指標(biāo)，在沒有背景流量干擾的情況下，通過改變影響TCP性能的參數(shù)，考察單個(gè)TCP流所能獲得的帶寬利用率，能反應(yīng)TCP在數(shù)據(jù)傳輸中的效率。由于鏈路帶寬和RTT時(shí)延是影響TCP傳輸效率的2個(gè)主要因素，因此本小節(jié)主要從這兩方面進(jìn)行考察。

4.1.1 鏈路瓶頸帶寬對(duì)帶寬利用率的影響

本實(shí)驗(yàn)主要考察鏈路瓶頸帶寬對(duì)TCP協(xié)議帶寬利用率的影響。為了減小過大的鏈路時(shí)延對(duì)傳輸性能的影響，本實(shí)驗(yàn)選取RTT時(shí)延為64 ms，瓶頸帶寬分別選取為10 Mbit/s (Ethernet)，100 Mbit/s (FE)，155 Mbit/s (OC-3 Wan)，622 Mbit/s (OC-12)，1 Gbit/s(GE)。實(shí)驗(yàn)時(shí)間為1 200 s，通過帶寬利用率來刻畫單流TCP的傳輸效率。

圖2 瓶頸帶寬對(duì)帶寬利用率的影響

從圖2所示的實(shí)驗(yàn)結(jié)果可以看出，在低帶寬(帶寬小于155 Mbit/s)的環(huán)境下，各類協(xié)議都具有非常好的帶寬利用率(帶寬利用率超過0.9)。但是隨著鏈路瓶頸帶寬的增加，尤其在帶寬大于155 Mbit/s之后，各種協(xié)議的帶寬利用率都呈下降趨勢(shì)。其中Hybla下降的最為明顯，在622 Mbit/s的瓶頸帶寬中，Hybla僅僅得到了0.15的帶寬利用率，而在1 Gbit/s的瓶頸帶寬中，Hybla的帶寬利用率只有0.1。這在一定程度上反映了Hybla通過降低RTT較小的流的擁塞窗口增長(zhǎng)速率的方法，影響了其在較小網(wǎng)絡(luò)時(shí)延環(huán)境中的傳輸效率[44]。其次是CTCP和Vegas，在622 Mbit/s的瓶頸帶寬中，它們的帶寬利用率均低于0.4，而在1 Gbit/s的帶寬中，它們的帶寬利用率僅僅為0.2。專門為高速長(zhǎng)距離網(wǎng)絡(luò)設(shè)計(jì)的BIC，HTCP和HSTCP均獲得了不錯(cuò)的帶寬利用率，在1 Gbit/s的鏈路中，它們的帶寬利用率均超過了0.8。

4.1.2 RTT對(duì)帶寬利用率的影響

本實(shí)驗(yàn)選取瓶頸帶寬為622 Mbit/s，RTT時(shí)延從2 ms到512 ms遞增，實(shí)驗(yàn)時(shí)間為1 200 s，通過吞吐率來刻畫RTT對(duì)單流TCP傳輸效率的影響。

圖3 RTT對(duì)帶寬利用率的影響

從圖3所示的結(jié)果可以看出，隨著RTT的增加，除了Hybla之外，其余各類TCP協(xié)議的帶寬利用率均呈下降趨勢(shì)。Hybla之所以出現(xiàn)帶寬利用率先下降再上升的情況，是和其采用的算法分不開的。Hybla引入了參數(shù)RTTref(默認(rèn)為25 ms)，并取ρ=RTT/RTTref來調(diào)節(jié)不同RTT環(huán)境下?lián)砣翱诘脑鲩L(zhǎng)速率，其自身建立的模型雖然保證了RTT的公平性(見4.2)，但是無(wú)法保證在所有RTT環(huán)境下都能達(dá)到很好的帶寬利用率[44]。圖2中Hybla的性能欠佳也反映了相同的問題。需要強(qiáng)調(diào)的是，隨著RTT的增加，Vegas的吞吐率下降明顯，這表明在高延時(shí)環(huán)境中，依靠RTT的變化來判斷網(wǎng)絡(luò)擁塞的準(zhǔn)確率下降，因此其性能受到了影響。HTCP在RTT為512 ms，瓶頸帶寬為622 Mbit/s的網(wǎng)絡(luò)環(huán)境下依然獲得了不錯(cuò)的帶寬利用率(0.85)。其次CUBIC和STCP也獲得了不錯(cuò)的帶寬利用率。

4.2 公平性

TCP協(xié)議的公平性主要有2種；一種是協(xié)議內(nèi)部的公平性(intra-protocol fairness)，即2個(gè)完全相同的TCP流在競(jìng)爭(zhēng)通過瓶頸路徑時(shí)，是否能公平的分享瓶頸帶寬；另一種是RTT的公平性(RTT fairness)，即相同的TCP協(xié)議在不同的RTT時(shí)延下競(jìng)爭(zhēng)通過瓶頸路徑時(shí)的帶寬分配情況。

4.2.1 Intra-protocol fairness

本實(shí)驗(yàn)選取路由器buffer為100%BDP，2個(gè)相同的TCP流競(jìng)爭(zhēng)通過帶寬為622 Mbit/s的瓶頸鏈路，分別考察在不同RTT環(huán)境下協(xié)議之間的公平性，實(shí)驗(yàn)時(shí)間為1 200 s。本文采用Jain[45,46]所提出的公平性指標(biāo)來衡量TCP協(xié)議的公平性：

其中，F(xiàn)的值越接近于1，表明協(xié)議公平性越好。

從圖4所示的實(shí)驗(yàn)結(jié)果可以看出，隨著RTT的增加，各協(xié)議的公平性總體上呈上升趨勢(shì)，這是因?yàn)殡S著RTT的增加，處于競(jìng)爭(zhēng)的TCP協(xié)議有充足的時(shí)間調(diào)整擁塞窗口，以占據(jù)競(jìng)爭(zhēng)流所讓出的帶寬。

圖4 協(xié)議內(nèi)部公平性

其中，HTCP的公平性最佳，即使在RTT較小的情況下依然具有較好的公平性。而Vegas的協(xié)議內(nèi)部公平性較差，其原因在于僅依靠鏈路中RTT的變化來判斷網(wǎng)絡(luò)的擁塞程度存在一定的誤差。尤其是隨著RTT的增加，Vegas無(wú)法通過鏈路時(shí)延的變化準(zhǔn)確估計(jì)網(wǎng)絡(luò)的擁塞程度，這也影響了其公平性。而當(dāng)RTT為512 ms時(shí)，Vegas又表現(xiàn)出了一種“良好”的協(xié)議內(nèi)部的公平性，其原因在于此時(shí)2個(gè)Vegas流的吞吐率均很?。ㄈ?.1.2節(jié)所示），其競(jìng)爭(zhēng)瓶頸帶寬的能力減弱所致。值得一提的是基于Vegas改進(jìn)之后的YeAH TCP的公平性得到了很大提高。

4.2.2 RTT fairness

本實(shí)驗(yàn)中2個(gè)使用相同協(xié)議的TCP流在不同RTT的環(huán)境下競(jìng)爭(zhēng)通過帶寬為622 Mbit/s的瓶頸鏈路。其中，一個(gè)TCP流的RTT固定為256 ms，另一個(gè)TCP流的RTT從16 ms到512 ms之間變化，分別考察相同協(xié)議在不同延時(shí)下的RTT公平性。本文采用Chiu所提出的公平性指標(biāo)來刻畫RTT的公平性

其中，x1為RTT變化的TCP流，x2為RTT固定為256 ms的TCP流，A值越接近0表明RTT公平性越好。

由圖5所示的實(shí)驗(yàn)結(jié)果可知，除了Hybla的A值始終接近0之外，其余各種協(xié)議的RTT公平性均不理想。Hybla的設(shè)計(jì)目的就是為了提高TCP的RTT公平性，此實(shí)驗(yàn)進(jìn)一步驗(yàn)證了Hybla在提高TCP的RTT公平性方面的有效性，但是從4.1節(jié)實(shí)驗(yàn)結(jié)果可知Hybla存在嚴(yán)重的效率問題。

圖5 RTT平性比較

隨著TCP流x1的RTT逐漸增加，各協(xié)議的RTT公平性也趨近于0，當(dāng)2個(gè)流的RTT相同時(shí)(256 ms)，大多數(shù)的A值都匯聚與0，當(dāng)x1的RTT再進(jìn)一步增加，A值進(jìn)一步減小并偏離0變?yōu)樨?fù)值，這說明大多數(shù)TCP都存在RTT公平性問題，RTT小的流在瓶頸帶寬競(jìng)爭(zhēng)中存在優(yōu)勢(shì)。由圖5還可以看出，YeAH也具有不錯(cuò)的RTT公平性，雖然和Hybla相比還有差距，但是YeAH的效率卻比Hybla具有優(yōu)勢(shì)。

4.3 TCP友好性

本實(shí)驗(yàn)中2個(gè)使用不同協(xié)議的TCP流在相同的RTT時(shí)延下競(jìng)爭(zhēng)通過帶寬為622 Mbit/s的瓶頸鏈路。其中，一個(gè)TCP固定為傳統(tǒng)的Reno，另一個(gè)TCP流為待測(cè)試的TCP協(xié)議。選取RTT從16 ms到512 ms之間變化，分別考察各協(xié)議在不同RTT時(shí)延下的友好性問題。本文采用式(1)刻畫TCP的友好性。其中，x1為待測(cè)試協(xié)議的TCP流，x2為Reno。A值越趨于0表明其友好性越好，A值為0表明所測(cè)試的協(xié)議與Reno具有相同的友好性。

圖6 TCP友好性比較

從圖6所示的實(shí)驗(yàn)結(jié)果可知，隨著RTT的增加，所測(cè)試協(xié)議的友好性逐漸提高。具體來講，所測(cè)試的TCP協(xié)議可以分為2類：一類是A為負(fù)值的協(xié)議，這類協(xié)議比Reno具有更好的TCP友好性；另一類是A為正值的協(xié)議，這類協(xié)議的TCP友好性較差，比較典型的是STCP，其使用MIMD的擁塞窗口調(diào)整策略，并且擁塞后減小0.125倍當(dāng)前窗口的方式，雖然獲得了不錯(cuò)的效率，但是其TCP友好性極差。Vegas采用基于時(shí)延的反饋算法，具有較好的TCP友好性，但是其傳輸效率較差。TCP的友好性和效率是一對(duì)矛盾體，在提高效率的同時(shí)很難保證協(xié)議的友好性，反之，在提高友好性的時(shí)候，傳輸效率也往往會(huì)受到影響。

5 基于真實(shí)網(wǎng)絡(luò)的TCP傳輸協(xié)議評(píng)價(jià)

本節(jié)主要考察TCP協(xié)議在真實(shí)網(wǎng)絡(luò)中的傳輸效率。為了更好的反應(yīng)TCP傳輸協(xié)議在不同網(wǎng)絡(luò)環(huán)境中的傳輸性能，本實(shí)驗(yàn)采用兩段真實(shí)鏈路對(duì)TCP的性能進(jìn)行評(píng)價(jià)。第一段鏈路是GLORIAD（global ring network for advanced application development）從香港到芝加哥的國(guó)際鏈路，鏈路帶寬為1 Gbit/s，往返時(shí)延為139 ms(±1 ms)；第二段鏈路是從北京到上海的國(guó)內(nèi)鏈路，鏈路帶寬為1 Gbit/s，往返時(shí)延為20 ms(±1 ms)。具體的鏈路拓?fù)涫疽馊鐖D7所示。

所采用的測(cè)試方法也分為2種：一種是通過網(wǎng)絡(luò)測(cè)量工具Iperf來測(cè)試，以最大限度的降低不同應(yīng)用程序?qū)CP傳輸性能的影響；考慮到在海量數(shù)據(jù)傳輸時(shí)，F(xiàn)TP是一種常用的手段，因此第2種方法采用FTP來傳輸實(shí)際文件（大小為2 Gbyte）來進(jìn)行測(cè)試。FTP服務(wù)器采用CentOS系統(tǒng)默認(rèn)的VSFTP，由于不同的FTP客戶端對(duì)傳輸性能影響較大，為了真實(shí)反映TCP協(xié)議的傳輸性能，選用LFTP作為客戶端。因?yàn)長(zhǎng)FTP未進(jìn)行任何的加密處理，其傳輸效率受到加密等外界因素的影響最小，因此能更好地反映TCP傳輸協(xié)議的性能。

圖7 國(guó)際和國(guó)內(nèi)鏈路示意

在實(shí)際網(wǎng)絡(luò)中進(jìn)行海量數(shù)據(jù)傳輸時(shí)，傳輸效率是用戶最為關(guān)注的性能指標(biāo)，因此本次的性能評(píng)價(jià)也主要以TCP的吞吐率作為考察指標(biāo)。在真實(shí)網(wǎng)絡(luò)中對(duì)TCP進(jìn)行測(cè)試，TCP的吞吐率不可避免地會(huì)受到背景流量的影響，同一協(xié)議的測(cè)試結(jié)果會(huì)有所變化，為了反映出TCP較為真實(shí)傳輸性能，以下測(cè)試均進(jìn)行5次，去掉最大值和最小值，取其余3個(gè)有效值的平均值作為最終結(jié)果。

5.1 TCP協(xié)議在國(guó)際鏈路上的性能

圖8和圖9分別是采用Iperf和FTP對(duì)TCP在國(guó)際鏈路上進(jìn)行數(shù)據(jù)傳輸?shù)臏y(cè)試結(jié)果。從總體上看，采用Iperf所測(cè)量的TCP性能稍好于使用FTP進(jìn)行實(shí)際文件傳輸?shù)男阅?。這主要是由于FTP自身的開銷導(dǎo)致了TCP的吞吐的降低。但是考慮到目前在高速長(zhǎng)距離網(wǎng)絡(luò)中進(jìn)行海量數(shù)據(jù)傳輸時(shí)廣泛采用FTP來進(jìn)行，因此，圖9所示的使用FTP對(duì)TCP進(jìn)行的性能測(cè)試更有實(shí)際意義。

由圖8和圖9可知，在網(wǎng)絡(luò)時(shí)延為139 ms(±1 ms)，鏈路可用帶寬約為900 Mbit/s（均通過Iperf的UDP傳輸協(xié)議測(cè)量所得，在傳輸900 Mbit/s的UDP數(shù)據(jù)時(shí)鏈路無(wú)分組丟失）的國(guó)際網(wǎng)絡(luò)鏈路上，TCP改進(jìn)協(xié)議的性能還有很大的提升空間。雖然在使用Iperf進(jìn)行測(cè)量時(shí)CUBIC、HSTCP、HTCP、Hybla和STCP的性能相對(duì)突出，但是在實(shí)際傳輸2 Gbyte的文件時(shí)，STCP的性能并沒有優(yōu)勢(shì)，其原因在于STCP在擁塞避免階段過于劇烈的窗口調(diào)整策略，極易導(dǎo)致網(wǎng)絡(luò)處于擁塞的狀態(tài)[44]。相反，HTCP和Hybla的性能相對(duì)較好。其中，Hybla為了提高TCP的RTT公平性，在鏈路中RTT較大時(shí)，Hybla會(huì)加速擁塞窗口的調(diào)整，以提高其在大延時(shí)的鏈路中的性能[44]。值得注意的是，在傳輸2 Gbyte的文件時(shí)，Reno也獲得了不錯(cuò)的性能，這一方面反應(yīng)了經(jīng)過改進(jìn)快速恢復(fù)階段之后的Reno，相較于傳統(tǒng)的標(biāo)準(zhǔn)TCP在性能上有所改善；另一方面反應(yīng)了在網(wǎng)絡(luò)狀態(tài)較好（無(wú)分組丟失且可用帶寬較大）的情況下，Reno也可以獲得一定的吞吐率。

圖8 TCP在國(guó)際鏈路上的吞吐率（Iperf所測(cè)）

圖9 TCP在國(guó)際鏈路上的吞吐率（FTP所測(cè)）

5.2 TCP協(xié)議在國(guó)內(nèi)鏈路上的性能

圖10和圖11是在國(guó)內(nèi)鏈路上分別采用Iperf和FTP所獲得的TCP的傳輸性能。與5.1節(jié)所示的性能類似，采用Iperf所獲得的傳輸性能也稍好于使用FTP所獲得的性能。

由圖10和圖11可知，在網(wǎng)絡(luò)時(shí)延為20 ms，可用帶寬約為900 Mbit/s（均通過與5.1所示方法測(cè)量）的國(guó)內(nèi)鏈路上，相較于國(guó)際鏈路，TCP的性能有了明顯的提高。這反應(yīng)了TCP受到網(wǎng)絡(luò)鏈路時(shí)延的影響這一事實(shí)：隨著網(wǎng)絡(luò)延時(shí)的降低，TCP的傳輸效率會(huì)相應(yīng)的提高。圖10使用Iperf所測(cè)試的TCP吞吐率中，BIC、CUBIC、HSTCP和STCP均獲得了不錯(cuò)的吞吐率，尤其是HSTCP，其吞吐率已經(jīng)接近900 Mbit/s。STCP的吞吐率也超過了800 Mbit/s。與在國(guó)際鏈路上測(cè)試的結(jié)果類似，圖11所示的是采用FTP傳輸2 Gbyte文件時(shí)，TCP的性能有所下降，其中，STCP的吞吐率仍然不夠理想，其原因與在國(guó)際鏈路上STCP的吞吐率不夠理想類似。相反，BIC和HSTCP均獲得了不錯(cuò)的性能，其吞吐率均超過了700 Mbit/s，這反映了在中長(zhǎng)距離網(wǎng)絡(luò)中BIC和HSTCP均具有明顯的傳輸優(yōu)勢(shì)，這也是BIC之所以能作為CentOS的默認(rèn)TCP傳輸協(xié)議的原因所在。還需要指出的是Hybla傳輸協(xié)議的特點(diǎn)也得到了體現(xiàn)，對(duì)照5.1節(jié)中Hybla在國(guó)際鏈路上的性能，發(fā)現(xiàn)其吞吐率基本上保持不變，或者說還有所減小，其原因在于Hybla降低了在低延時(shí)鏈路上的擁塞窗口增長(zhǎng)速率，以達(dá)到較好的RTT公平性[44]。這一結(jié)果與第4節(jié)采用NS2進(jìn)行仿真的情況相吻合。

圖10 TCP在國(guó)內(nèi)鏈路上的吞吐率（Iperf所測(cè)）

圖11 TCP在國(guó)內(nèi)鏈路上的吞吐率（FTP所測(cè)）

值得注意的是，在本次實(shí)驗(yàn)中，發(fā)現(xiàn)不同的FTP客戶端對(duì)傳輸效率的影響非常大，以SFTP客戶端為例，從香港到芝加哥，HTCP協(xié)議最大僅獲得了103 Mbit/s的吞吐率，這與使用LFTP獲得的接近400 Mbit/s的吞吐率相差甚遠(yuǎn)。究其原因是由于其自身采用了加密機(jī)制所產(chǎn)生的額外開銷導(dǎo)致的。因此，除了傳輸協(xié)議之外，應(yīng)用程序的選取在高速長(zhǎng)距離網(wǎng)絡(luò)中進(jìn)行海量數(shù)據(jù)傳輸時(shí)也應(yīng)該得到充分重視。

6 結(jié)束語(yǔ)

科研活動(dòng)的信息化水平日益提高對(duì)高速長(zhǎng)距離網(wǎng)絡(luò)提出了新的需求，大量的高速長(zhǎng)距離網(wǎng)絡(luò)相繼建立，與之相適應(yīng)的高速TCP傳輸協(xié)議也被相繼提出。本文分類討論了目前流行的TCP改進(jìn)協(xié)議，在此基礎(chǔ)上分別通過仿真軟件和真實(shí)網(wǎng)絡(luò)對(duì)目前流行的TCP傳輸協(xié)議進(jìn)行了系統(tǒng)的評(píng)價(jià)，本文發(fā)現(xiàn)，目前TCP改進(jìn)協(xié)議還存在以下幾個(gè)問題。

傳輸效率與友好性問題。高速網(wǎng)絡(luò)首先體現(xiàn)在傳輸效率方面，如何將大量的科研數(shù)據(jù)進(jìn)行高速有效的傳輸是用戶首先考慮的問題。目前大量的改進(jìn)協(xié)議主要集中在此，TCP在高速長(zhǎng)距離網(wǎng)絡(luò)中的性能也得到了明顯的提升。然而在提高傳輸效率的同時(shí)如何減小對(duì)與之競(jìng)爭(zhēng)的數(shù)據(jù)流的影響，即提高TCP友好性，是一個(gè)亟待解決的問題。

RTT的公平性問題。隨著數(shù)據(jù)中心的興起和以網(wǎng)絡(luò)為工具的科研工作的深入，大量的數(shù)據(jù)需要被用戶共享。分散在世界各地的用戶由于距離數(shù)據(jù)源的距離不等，因此RTT也各不相同，這就存在RTT的不公平問題。距離數(shù)據(jù)源較近的用戶往往比距離數(shù)據(jù)源較遠(yuǎn)的用戶更容易搶占帶寬資源，使得距離數(shù)據(jù)源較遠(yuǎn)的用戶無(wú)法獲得理想的傳輸效率[47]。目前的傳輸協(xié)議對(duì)此關(guān)注較少，即使一些研究人員提出了改進(jìn)措施[21]，但是在提高RTT公平性的同時(shí)，其自身的傳輸效率受到了影響。

網(wǎng)絡(luò)帶寬測(cè)量技術(shù)與擁塞控制機(jī)制相結(jié)合的問題。目前流行的TCP改進(jìn)協(xié)議的擁塞窗口調(diào)整策略所依據(jù)的反饋方式主要有分組丟失反饋、延時(shí)反饋和兩者相結(jié)合的混合反饋。網(wǎng)絡(luò)可用帶寬測(cè)量技術(shù)日益成熟，使得網(wǎng)絡(luò)帶寬測(cè)量技術(shù)與擁塞窗口調(diào)整策略相結(jié)合成為可能。文獻(xiàn)[21]使用了網(wǎng)絡(luò)帶寬測(cè)量技術(shù)，但是不管是在仿真環(huán)境中還是在實(shí)際網(wǎng)絡(luò)中其優(yōu)勢(shì)并不明顯，因此在此領(lǐng)域還有大量工作可做。

本文對(duì)TCP改進(jìn)協(xié)議進(jìn)行的評(píng)價(jià)結(jié)果以及所發(fā)現(xiàn)的問題，將會(huì)是下一步研究工作的重點(diǎn)。

[1] CERN[EB/OL]. http://home.web.cern.ch.

[2] eVLBI[EB/OL]. http://www.evlbi.org.

[3] Bio-mirror[EB/OL]. www.bio-mirror.net.

[4] LEITH D J, SHORTEN N, MCCULLAGH G . Experimental evaluation of cubic-TCP[A]. Protocols for Fast Long Distance Networks[C].Los Angeles, USA, 2007.

[5] SANSA J, SZOMORU A, DER HULST J M V. An evaluation study of data transport protocols for e-vlbi[J]. International Journal of Computing and ICT Research, 2007,(5):68-75.

[6] LEITH D, ANDREW L, QUETCHENBACH T,etal. Experimental evaluation of delay/loss-based TCP congestion control algorithms[A].PFLDnet 2008[C]. Tokyo, Japan, 2008.

[7] HASHIMOTO M, HASEGAWA G, MURATA M, etal. Performance evaluation and improvement of hybrid TCP congestion control mechanisms in wireless LAN environment[A]. IEEE Telecommunication Networks and Applications Conference[C]. Australasian, 2008.367-372 .

[8] CHENG J, WEI D, LOW S H, etal. FAST TCP: from theory to experiments[J]. IEEE Network, 2005,19(1):4-11.

[9] SCHARF M, STROTBEK H. Performance evaluation of Quick-Start TCP with a Linux kernel implementation[A]. Proc IFIP Networking 2008[C]. Springer LNCS 4982. Singapore, 2008. 703-714.

[10] SCHARF M. Performance evaluation of fast startup congestion control schemes[J]. NETWORKING, 2009,(5):716-727.

[11] KUSCHNIG R, KOFLER I, HELLWAGNER H. An evaluation of TCP-based rate-control algorithms for adaptive Internet streaming of H.264/SVC[A]. Proceedings of the First Annual ACM SIGMM Conference on Multimedia Systems[C]. New York, 2010.

[12] FLOYD S, GURTOV A. RFC3649-HighSpeed TCP for Large Congestion Windows[S]. 2003.

[13] KELLY T. Scalable TCP: improving performance in highspeed wide area networks[J]. Computer Communications Review, 2003, 33(2):83-91.

[14] XU L, RHEE I. Binary increase congestion control for fast long-distance networks[A]. IEEE INFOCOM 2004[C]. Hongkong,2004. 2514-2524.

[15] HA S, RHEE I, XU L. CUBIC: a new TCP-friendly high-speed TCP variant[J]. SIGOPS Operating Systems Review, 2008, 42(5):64-74.

[16] LEITH D, SHORTEN R. H-TCP: TCP for high-speed and long distance networks[A]. PFLDnet 2004[C]. Illinois, USA, 2004.

[17] MARFIA G, PAU G, GERLA M, etal. TCP Libra: exploring rtt-fairness for UCLA Computer Science Department, Tech Rep[R].2005.

[18] RFC2582-the NewReno Modif i cation to TCP's Fast Recovery Algorithm[S]. 1999.

[19] CAINI C, FIRRINCIELI R. TCP Hybla: a TCP enhancement for heterogeneous networks[J]. International Journal of Satellite Communications and Networking, 2004, 22: 547-566.

[20] WEI D X, LOW S H, HEGDE S. FAST TCP: motivation, architecture,algorithms, performance[J]. IEEE/ACM Trans Netw, 2006, 14(6):1246-1259.

[21] PETERSON L B. TCP Vegas: end to end congestion avoidance on a global Internet[J]. IEEE J Sel Areas Commun, 1995, 13(8):1465-1480.

[22] RHEE S. Hybrid slow start for high-bandwidth and long-distance networks[A]. PFLDnet 2008[C]. Tokyo, Japan, 2008.

[23] KESHAV S. Packet-pair flow control[EB/OL]. http://www.cs.cornell.edu/skeshar/doc/9412-17.ps, 1995.

[24] DOVROLIS C, RAMANATHAN P, MOORE D. Packet-dispersion techniques and a capacity-estimation methodology[J]. IEEE/ACM Transactions on Networking, 2004,12(6): 963-977.

[25] TAN K, ZHANG Q, SRIDHARAN M. Compound TCP: a scalable and TCP-friendly congestion control for high-speed networks[A].PFLDnet 2006[C]. Nara, Japan, 2006.

[26] KING R, RIEDI R. TCP-Africa: an adaptive and fair rapid increase rule for scalable TCP[A]. IEEE INFOCOM 2005[C]. Miami, 2005.1838-1848.

[27] LIU S, SRIKANT R. TCP-Illinois: a loss and delay-based congestion control algorithm for high-speed networks[A]. First International Conference on Performance Evaluation Methodologies and Tools[C].Pisa, Italy, 2006. 417-440.

[28] BAJOCCHI A, VACIRCA F. YeAH-TCP: yet another highspeed TCP[A]. PFLDnet 2007[C]. Marina DelRey, California, 2007.37-42.

[29] CASETTI C, GERLA M, MASCOLO S, etal. TCP westwood: bandwidth estimation for enhanced transport over wireless links[A]. ACM MOBICOM 2001[C]. Rome, Italy, 2001. 287-297.

[30] GRIECO L A, MASCOLO A,etal. Performance evaluation and comparison of Westwood+, New Reno, and Vegas TCP congestion control[A]. The Seventh International Symposium on Computers and Communications[C]. Alexandria, 2004. 25-38.

[31] HIDEYUKI S, TUTOMU M. Improving eff i ciency-friendliness tradeoffs of TCP congestion control algorithm[A]. IEEE Globecom 2005[C]. St Louis, Missouri, 2005.

[32] KANEKO K, SU Z, KATTO J. TCP-Fusion: a hybrid congestion control algorithm for high-speed networks[A]. PFLDnet 2007[C]. Marina Del Rey, California, 2007.

[33] DINA K, MARK H, CHARLTE R. Congestion control for high bandwidth delay product networks[A]. ACM SIGCOMM 2002[C]. Pittsburgh, USA, 2002.

[34] XIA Y, KALYANARAMAN L. One more bit is enough[J]. ACM Sigcomm Computer Communication REVIEW, 2005, 34: 37-48.

[35] ZHANG Y, LOGUINOV L D D. JetMax: scalable max-min congestion control for high-speed heterogeneous networks[A]. IEEE INFORCOM 2006[C]. Barcelona, Spain, 2006. 1193-1219.

[36] HUANG X, LIN C, REN F. A novel high speed transport protocol based on explicit virtual load feedback[J]. Computer Networks, 2007,51:1800-1814.

[37] HUANG X, LIN C, REN F Y, etal. Improving the convergence and stability of congestion control algorithm[A]. The 15th IEEE Internet Conference on Network Protocols (ICNP 2007)[C]. Beijing, China,2007. 206-215.

[38] FLOYD E. RFC 5166 Metrics for the Evaluation of Congestion Control Mechanisms[S]. RFC, 2008.

[39] LARRY L P, BRUCE S D. Computer Networks: A System Approach fourth edition[M]. San Francisco: Elsevier, 2007.

[40] STALLINGS W. High-Speed Networks and Internets: Performance and Quality of Service, Second Edition[M]. USA: Prentice Hall, 2002.

[41] LEITH D J, SHORTEN R N, MCCULLAGH G. Experimental evaluation of Cubic-TCP[A]. PFLDnet 2007[C]. Marina DelRey, California,2007.

[42] COTTRELL R L, ANSARI S, KHANDPUR P,etal. Characterization and evaluation of TCP and udp-based transport on real networks[A].PFLDnet2005[C]. France, 2005.

[43] VILLAMIZAR C, SONG C. High performance TCP in ANSNET[J].ACM Sigcomm Computer Communication REVIEW, 1994, 24: 45-60.

[44] AFANASYEV A, TILLEY N, REIHER P, etal. Host-to-host congestion control for TCP[J]. Communications Surveys & Tutorials, IEEE, 2010,12: 304-342.

[45] CHIU D M, JAIN R. Analysis of the increase and decrease algorithms for congestion avoidance in computer networks[J]. Computer Networks and ISDN systems, 1989, 17:1-14.

[46] BULLOT H, COTTRELL R L, HUGHES J R. Evaluation of advanced TCP stacks on fast long-distance production networks[J]. Journal of Grid Computing, 2003, (1): 345-359.

[47] PAPADIMITRIOU D, WELZL M, SCHARF M, etal. Open Research Issues in Internet Congestion Control[S]. RFC6077, 2011.