TCP改進協議在高速長距離網絡中的性能研究

王國棟，任勇毛，李俊

(1.中國科學院 計算機網絡信息中心，北京 100190；2.中國科學院 研究生院，北京 100049)

1 引言

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

在高速網絡傳輸方面，高速網絡基礎設施已經出現，但是研究人員卻無法有效利用網絡帶寬，因為傳統的傳輸協議嚴重影響著高速網絡的傳輸性能。針對傳輸協議在高速網絡中的各種缺陷，研究人員提出了許多基于標準TCP的改進協議。這些改進協議針對現有協議的某些缺點做出了改進，使得部分性能有所提高，但是這些改進協議在高速長距離網絡環境中的性能如何，能否滿足e-Science等科研應用的需要，針對這些問題，迫切需要對現有的改進協議做出評價。

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

2 TCP改進協議分類描述

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

2.1 基于分組丟失反饋的改進協議

2.1.1 HSTCP

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

2.1.2 STCP（scalable TCP）

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

2.1.3 BIC

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

2.1.4 CUBIC

CUBIC[15]是BIC的一個改進版本，試圖在保留BIC優點的基礎上，簡化窗口控制并增強它的TCP友好性和RTT公平性。

表1 TCP改進協議分類描述

2.1.5 HTCP

HTCP[16]采用上次擁塞事件以來逝去的時間 Δ來檢測網絡擁塞程度。AIMD的調整因子為α(Δ)，α(Δ)隨著Δ的變化進行動態調整，從而調整AIMD的窗口變化速率。

2.1.6 Libra

Libra[17]是在New Reno[18]的基礎上改進而來的，其主要目的是為了提高New Reno的RTT公平性和可擴展性。

2.1.7 Hybla

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

2.2 基于時延反饋的改進協議

2.2.1 Fast TCP

Fast TCP[8,20]以隊列延時作為反饋因子，利用發送端檢測到的ACK時延變化來調整擁塞窗口。其擁塞窗口調整算法如下：

其中，baseRTT表示所觀測到的最小RTT，α表示一個非負的修正因子。

2.2.2 Vegas

Vegas[21]是基于時延反饋協議的代表。它通過觀測TCP連接中的RTT時延變化來調節擁塞窗口。如果發現RTT變大，則認為網絡發生擁塞，相應的減小擁塞窗口。如果發現RTT變小，則認為擁塞已經解除，并增加擁塞窗口。如果RTT保持不變，則不改變擁塞窗口的大小。

2.2.3 Hybrid Slow Start TCP

Hybrid Slow Start TCP[22]利用了網絡測量技術中的packet-pair[23]測量技術和packet-train[24]測量技術，通過“ACK train length”和“Delay increase”來決定TCP何時從慢啟動階段轉換到擁塞避免階段。

2.3 基于分組丟失和時延混合反饋的改進協議

2.3.1 CTCP

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

2.3.2 Africa

TCP Africa[26](adaptive and fair rapid increase congestion avoidance)將網絡狀態分為擁塞和無擁塞2個狀態，并且利用Vegas的RTT延時來判斷這2種狀態。當網絡無擁塞時，協議進入類似于HSTCP的快速增長模式；在網絡逼近擁塞時，TCP Africa進入類似于傳統TCP的慢速增長模式。

2.3.3 Illinois

Illinois[27]同樣考慮到LCA和DCA的局限性，提出了采用兩者相結合的算法。與CTCP和Africa類似，都是將網絡狀態分為擁塞和無擁塞2種狀態，但是在這2種狀態下對擁塞窗口的調整策略不同。對于Illinois而言，在擁塞避免階段，每個RTT: cwnd = cwnd+ α，而當檢測到分組丟失時，cwnd = cwnd – β · cwnd。

2.3.4 YeAH

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

2.4 基于可用帶寬測量的改進協議

2.4.1 Westwood

Westwood[29]和westwood+[30]是典型的基于網絡帶寬測量的TCP協議。Westwood通過計算最近過去(recent past)的帶寬來調整擁塞窗口的變化。網絡帶寬是通過記錄一段時間之內(以ACK為標準)所發送的數據來得到的。 Westwood+改進了網絡帶寬的測量機制，分別用“被確認了”的數據來代替發送的數據，用RTT來代替ACK來獲得傳輸時間，這一改進大大提高了網絡帶寬測量的準確性。

2.4.2 ARENO

ARENO[31](adaptive RENO)是一個基于帶寬測量的TCP改進協議，旨在改進TCP的效率和TCP的友好性。它具有2個窗口增加機制，Wbase和Wprobe。在Wbase階段，每個RTT增加一個CWND，在Wprobe階段，每個RTT增加的CWND根據所測量的網絡帶寬動態調整。ARENO的帶寬測量機制類似于Westwood。

2.4.3 Fusion

Fusion[32]與ARENO類似，結合westwood的帶寬測量和vegas的網絡緩存預測機制。Fusion定義了3個線性增長函數，根據不同的隊列延時，動態切換這3個增長函數。另外，當網絡分組丟失時，根據RTT的不同，將擁塞窗口減小到相應的程度。

2.5 基于顯式擁塞通告的改進協議

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

3 TCP傳輸協議評價標準及評價方法

對于傳輸協議的性能評價是個很大的研究課題，一直是比較熱門的研究領域。進行性能評價，需要考慮2個因素：一是評價標準，二是評價方法。

3.1 評價標準

評價標準是影響評價結果的一個重要因素。對于傳輸協議的評價標準，目前并無定論[38,39]。但是對于e-Science科研應用而言衡量傳輸協議優劣的一個重要指標是傳輸協議的效率;對于網絡自身的性能而言，RTT公平性和TCP友好性也是必要的考慮因素。綜合以上考慮，本文著重從協議的吞吐率、RTT公平性和協議之間的友好性進行評價。

3.2 評價方法

評價方法也是影響評價結果的重要因素。一般而言，對于傳輸協議性能評價的方法主要有以下幾種：一種是利用理論模型分析法[40]。一種是采用模擬的實驗方法，NS2是目前學術界廣泛使用的一種網絡模擬平臺，其實驗結果受到專業領域的普遍認可。另一種是通過搭建模擬網絡環境進行實驗[6,41]。還有一種是在實際網絡中進行測試[42]。

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

4 基于NS2的TCP傳輸協議評價

本節采用NS2仿真工具對目前流行的TCP改進協議進行評價。網絡拓撲為單瓶頸主干鏈路、多接入終端的啞鈴型拓撲。根據隊列大小理論[43]，隊列大小為100%BDP（bandwidth delay product），TCP連接的應用使用FTP，實驗網絡拓撲如圖1所示。

圖1 NS2仿真實驗拓撲

4.1 單流帶寬利用率

單流帶寬利用率是TCP傳輸協議傳輸效率的重要指標，在沒有背景流量干擾的情況下，通過改變影響TCP性能的參數，考察單個TCP流所能獲得的帶寬利用率，能反應TCP在數據傳輸中的效率。由于鏈路帶寬和RTT時延是影響TCP傳輸效率的2個主要因素，因此本小節主要從這兩方面進行考察。

4.1.1 鏈路瓶頸帶寬對帶寬利用率的影響

本實驗主要考察鏈路瓶頸帶寬對TCP協議帶寬利用率的影響。為了減小過大的鏈路時延對傳輸性能的影響，本實驗選取RTT時延為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)。實驗時間為1 200 s，通過帶寬利用率來刻畫單流TCP的傳輸效率。

圖2 瓶頸帶寬對帶寬利用率的影響

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

4.1.2 RTT對帶寬利用率的影響

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

圖3 RTT對帶寬利用率的影響

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

4.2 公平性

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

4.2.1 Intra-protocol fairness

本實驗選取路由器buffer為100%BDP，2個相同的TCP流競爭通過帶寬為622 Mbit/s的瓶頸鏈路，分別考察在不同RTT環境下協議之間的公平性，實驗時間為1 200 s。本文采用Jain[45,46]所提出的公平性指標來衡量TCP協議的公平性：

其中，F的值越接近于1，表明協議公平性越好。

從圖4所示的實驗結果可以看出，隨著RTT的增加，各協議的公平性總體上呈上升趨勢，這是因為隨著RTT的增加，處于競爭的TCP協議有充足的時間調整擁塞窗口，以占據競爭流所讓出的帶寬。

圖4 協議內部公平性

其中，HTCP的公平性最佳，即使在RTT較小的情況下依然具有較好的公平性。而Vegas的協議內部公平性較差，其原因在于僅依靠鏈路中RTT的變化來判斷網絡的擁塞程度存在一定的誤差。尤其是隨著RTT的增加，Vegas無法通過鏈路時延的變化準確估計網絡的擁塞程度，這也影響了其公平性。而當RTT為512 ms時，Vegas又表現出了一種“良好”的協議內部的公平性，其原因在于此時2個Vegas流的吞吐率均很小（如4.1.2節所示），其競爭瓶頸帶寬的能力減弱所致。值得一提的是基于Vegas改進之后的YeAH TCP的公平性得到了很大提高。

4.2.2 RTT fairness

本實驗中2個使用相同協議的TCP流在不同RTT的環境下競爭通過帶寬為622 Mbit/s的瓶頸鏈路。其中，一個TCP流的RTT固定為256 ms，另一個TCP流的RTT從16 ms到512 ms之間變化，分別考察相同協議在不同延時下的RTT公平性。本文采用Chiu所提出的公平性指標來刻畫RTT的公平性

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

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

圖5 RTT平性比較

隨著TCP流x1的RTT逐漸增加，各協議的RTT公平性也趨近于0，當2個流的RTT相同時(256 ms)，大多數的A值都匯聚與0，當x1的RTT再進一步增加，A值進一步減小并偏離0變為負值，這說明大多數TCP都存在RTT公平性問題，RTT小的流在瓶頸帶寬競爭中存在優勢。由圖5還可以看出，YeAH也具有不錯的RTT公平性，雖然和Hybla相比還有差距，但是YeAH的效率卻比Hybla具有優勢。

4.3 TCP友好性

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

圖6 TCP友好性比較

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

5 基于真實網絡的TCP傳輸協議評價

本節主要考察TCP協議在真實網絡中的傳輸效率。為了更好的反應TCP傳輸協議在不同網絡環境中的傳輸性能，本實驗采用兩段真實鏈路對TCP的性能進行評價。第一段鏈路是GLORIAD（global ring network for advanced application development）從香港到芝加哥的國際鏈路，鏈路帶寬為1 Gbit/s，往返時延為139 ms(±1 ms)；第二段鏈路是從北京到上海的國內鏈路，鏈路帶寬為1 Gbit/s，往返時延為20 ms(±1 ms)。具體的鏈路拓撲示意如圖7所示。

所采用的測試方法也分為2種：一種是通過網絡測量工具Iperf來測試，以最大限度的降低不同應用程序對TCP傳輸性能的影響；考慮到在海量數據傳輸時，FTP是一種常用的手段，因此第2種方法采用FTP來傳輸實際文件（大小為2 Gbyte）來進行測試。FTP服務器采用CentOS系統默認的VSFTP，由于不同的FTP客戶端對傳輸性能影響較大，為了真實反映TCP協議的傳輸性能，選用LFTP作為客戶端。因為LFTP未進行任何的加密處理，其傳輸效率受到加密等外界因素的影響最小，因此能更好地反映TCP傳輸協議的性能。

圖7 國際和國內鏈路示意

在實際網絡中進行海量數據傳輸時，傳輸效率是用戶最為關注的性能指標，因此本次的性能評價也主要以TCP的吞吐率作為考察指標。在真實網絡中對TCP進行測試，TCP的吞吐率不可避免地會受到背景流量的影響，同一協議的測試結果會有所變化，為了反映出TCP較為真實傳輸性能，以下測試均進行5次，去掉最大值和最小值，取其余3個有效值的平均值作為最終結果。

5.1 TCP協議在國際鏈路上的性能

圖8和圖9分別是采用Iperf和FTP對TCP在國際鏈路上進行數據傳輸的測試結果。從總體上看，采用Iperf所測量的TCP性能稍好于使用FTP進行實際文件傳輸的性能。這主要是由于FTP自身的開銷導致了TCP的吞吐的降低。但是考慮到目前在高速長距離網絡中進行海量數據傳輸時廣泛采用FTP來進行，因此，圖9所示的使用FTP對TCP進行的性能測試更有實際意義。

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

圖8 TCP在國際鏈路上的吞吐率（Iperf所測）

圖9 TCP在國際鏈路上的吞吐率（FTP所測）

5.2 TCP協議在國內鏈路上的性能

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

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

圖10 TCP在國內鏈路上的吞吐率（Iperf所測）

圖11 TCP在國內鏈路上的吞吐率（FTP所測）

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

6 結束語

科研活動的信息化水平日益提高對高速長距離網絡提出了新的需求，大量的高速長距離網絡相繼建立，與之相適應的高速TCP傳輸協議也被相繼提出。本文分類討論了目前流行的TCP改進協議，在此基礎上分別通過仿真軟件和真實網絡對目前流行的TCP傳輸協議進行了系統的評價，本文發現，目前TCP改進協議還存在以下幾個問題。

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

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

網絡帶寬測量技術與擁塞控制機制相結合的問題。目前流行的TCP改進協議的擁塞窗口調整策略所依據的反饋方式主要有分組丟失反饋、延時反饋和兩者相結合的混合反饋。網絡可用帶寬測量技術日益成熟，使得網絡帶寬測量技術與擁塞窗口調整策略相結合成為可能。文獻[21]使用了網絡帶寬測量技術，但是不管是在仿真環境中還是在實際網絡中其優勢并不明顯，因此在此領域還有大量工作可做。

本文對TCP改進協議進行的評價結果以及所發現的問題，將會是下一步研究工作的重點。

[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.