王穎為

摘 要：隨著網(wǎng)絡不斷發(fā)展，人類面臨的入網(wǎng)環(huán)境越來越復雜，衛(wèi)星接入上網(wǎng)的方案在很多情況下是個很好的選擇。但是衛(wèi)星鏈路本身與傳統(tǒng)鏈路有所不同，有自己獨特的特性，這樣就需要改進TCP方案，使其適應衛(wèi)星鏈路的環(huán)境，從而提高TCP的性能。本文初步探討了NewReno、TCP Cubic、Hybla三種典型TCP版本在衛(wèi)星鏈路上的性能表現(xiàn)，希望能夠找出一種令TCP性能在衛(wèi)星鏈路上表現(xiàn)得更加出色的方案。

關鍵詞：衛(wèi)星鏈路；TCP性能；擁塞算法

1 研究背景

隨著互聯(lián)網(wǎng)的不斷發(fā)展，越來越多的人們加入網(wǎng)絡，適應網(wǎng)絡，依賴網(wǎng)絡，期待著隨時隨地享受網(wǎng)絡的便捷服務。然而，受到自然環(huán)境等因素的影響，一些地域缺乏或難以架設地面網(wǎng)絡設施。另外，人們還想更加自由地接入網(wǎng)絡，不受線路的牽絆。因此，衛(wèi)星接入上網(wǎng)是一個不錯的方案，地球同步衛(wèi)星鏈路會為移動用戶提供一個方便快捷的接入網(wǎng)絡。

但是，由于接入技術的改變，硬件、軟件、現(xiàn)實條件都發(fā)生了變化，過去常見的舊的TCP版本不能適應新應用的要求，顯示出較差的性能?？偨Y其中原因，有如下幾點：

1.1 衛(wèi)星鏈路特性對TCP性能的影響

1.1.1 傳輸距離長，導致嚴重的傳輸延遲

地球同步衛(wèi)星的高度大約有36，000公里，信息在衛(wèi)星與地面接收站之間傳輸大約要250毫秒。

1.1.2 誤碼率高

相對于地面鏈路，衛(wèi)星鏈路的誤碼率較高，從而使數(shù)據(jù)包的錯誤率增高。

1.1.3 數(shù)據(jù)傳輸速率低

在衛(wèi)星鏈路上，只有最大10Mbps的上傳速率。

1.2 TCP機制和算法對TCP性能的影響

1.2.1 三次握手

首先，一個TCP連接是通過接收端和發(fā)送端之間的“三次握手”建立的。

第一次握手：建立連接時，客戶端發(fā)送syn包（syn=x）到服務器，并進入SYN_SENT狀態(tài)，等待服務器確認（SYN：同步序列編號）。

第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=x+1），同時自己也發(fā)送一個SYN包（syn=y），即SYN+ACK包，此時服務器進入SYN_RECV狀態(tài)。

第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發(fā)送確認包ACK（ack=y+1），此包發(fā)送完畢，客戶端和服務器進入ESTABLISHED狀態(tài)，完成三次握手。

在衛(wèi)星鏈路上，即使是很短的數(shù)據(jù)交換，都需要至少幾秒鐘才能完成，降低了TCP的性能。

1.2.2 接收窗口rwnd的值

使用TCP發(fā)送數(shù)據(jù)時，前一個目的端發(fā)送來的數(shù)據(jù)包，會明確地規(guī)定好應用程序被允許的發(fā)送字節(jié)量，被稱為“接收窗口”。這個值，通常被設置為8KB或16KB，這嚴重限制了TCP連接通過衛(wèi)星可以達到的速度。

1.2.3 默認慢啟動算法

TCP會以一個非常緩慢的速度開始發(fā)送，并緩慢增加，直到達到可用容量。這一過程需要幾個RTT，而衛(wèi)星鏈路本身有嚴重的傳播延遲，因此，會花費很長的時間才能達到可用容量。當發(fā)生擁塞或其他原因的數(shù)據(jù)包丟失時，TCP的擁塞窗口值cwnd迅速減小，這個慢啟動的過程又會重新開始。

1.2.4 包丟失導致乘法減小

TCP假定任何丟包都是由擁塞造成的。每當一個數(shù)據(jù)包丟失，TCP就減小擁塞窗口，從而減小傳輸速率。例如，每當檢測到丟包事件，TCP NewReno將其傳輸速率降低為原來的50%。但是，衛(wèi)星鏈路本身的誤碼率就很高，封包錯誤率就是在不發(fā)生擁塞的情況下觀察到的。此外，衛(wèi)星和地面鏈路容量之間的差異也會導致TCP性能較差，大量的包丟失可能會由于這種拓撲結構的改變而發(fā)生。

2 研究方案

從前面的研究來看，我們發(fā)現(xiàn)衛(wèi)星鏈路有著自己的特性，但TCP方案沒有很好地適應這些特性。有時候網(wǎng)絡并未發(fā)生擁塞，只是本身的傳輸時間長或者有丟包等事件發(fā)生，卻被誤認為是擁塞，導致發(fā)送端的擁塞窗口值cwnd驟減，信道沒有被充分利用，從而影響了TCP的性能。因而，想辦法避免擁塞，及其導致的cwnd值驟減。下面是一些TCP的新版本，用來解決這些問題。

2.1 NewReno

這一版本采用快速重傳技術和快速恢復技術。

超時重傳是TCP協(xié)議保證數(shù)據(jù)可靠性的一個重要機制，其原理是在發(fā)送一個數(shù)據(jù)以后就開啟一個計時器，在一定時間內(nèi)如果沒有得到發(fā)送數(shù)據(jù)報的ACK報文，那么就重新發(fā)送數(shù)據(jù)，直到發(fā)送成功為止。這是數(shù)據(jù)丟包的情況下給出的一種修補機制。一般來說，重傳發(fā)生在超時之后，但是如果發(fā)送端接收到3個以上的重復ACK，就應該意識到，數(shù)據(jù)丟了，需要重新傳遞。這個機制不需要等到重傳定時器溢出，所以叫做快速重傳，而快速重傳以后，因為走的不是慢啟動而是擁塞避免算法，所以這又叫做快速恢復算法。

快速重傳和快速恢復旨在快速恢復丟失的數(shù)據(jù)包。沒有快速重傳和快速恢復，TCP將會使用定時器來要求傳輸暫停。在暫停這段時間內(nèi)，沒有新的數(shù)據(jù)包被發(fā)送。

2.2 TCP Cubic

目前，Cubic是Linux中TCP協(xié)議的默認擁塞控制算法。它是TCP BIC的優(yōu)化版本。TCP BIC的主要思想是確保對于往返時間RTT不同的各個流，能夠公平地分享衛(wèi)星鏈路上提供的容量。Cubic在設計上簡化了BIC-TCP的窗口調(diào)整算法，在BIC-TCP的窗口調(diào)整中會出現(xiàn)一個有凹有凸的增長曲線（這里的凹和凸指的是數(shù)學意義上的凹和凸，即凹函數(shù)和凸函數(shù)），Cubic使用了一個三次函數(shù)（即一個立方函數(shù)），在三次函數(shù)曲線中同樣存在一個凹和凸的部分，該曲線形狀和BIC-TCP的曲線圖十分相似，于是該部分取代BIC-TCP的增長曲線。

在Cubic的三次函數(shù)中由凹和凸兩部分控制窗口的增長。第一部分是個凹函數(shù)，在這一階段窗口快速增長到上一次擁塞事件發(fā)生之前的大??；第二部分是個凸函數(shù)，在這一階段Cubic尋求更大的帶寬，先慢后快。Cubic的大量時間都處在凹凸函數(shù)增長區(qū)之間的一個穩(wěn)定狀態(tài)上，這使得網(wǎng)絡在開始尋求更大帶寬之前，能夠保持穩(wěn)定。

另外，Cubic與標準TCP協(xié)議最主要的區(qū)別，在于它的窗口增長函數(shù)僅僅取決于連續(xù)的兩次擁塞事件的時間間隔值，從而窗口增長完全獨立于網(wǎng)絡的時延RTT，Cubic的RTT獨立性質使得Cubic能夠在多條共享瓶頸鏈路的TCP連接之間保持良好的RTT公平性。

2.3 Hybla

可選擇使用PEPSal方案（在發(fā)送端修改過的端到端協(xié)議，使用TCP分離概念的衛(wèi)星中繼傳輸協(xié)議）。把由衛(wèi)星鏈路引發(fā)的長的RTT的影響降到最低；它加快了cwnd的增長速度，為不同RTT的連接提供相同傳輸速率。

TCP Hybla掃描窗口增量規(guī)則以確保RTT不同的流之間的公平性。當某個流的RTT的值比既定的參考RTT的值小時，Hybla的表現(xiàn)與NewReno一樣，否則，Hybla增加擁塞窗口的值，更加積極地補償由于RTT增加帶來的吞吐量下降。

Hybla主要解決不同RTT的公平性問題。它采用基于時延補償?shù)姆椒?。對于大時延網(wǎng)絡來說，采用這種算法可以提高傳輸效率。

3 研究結論

上面圍繞著防止發(fā)送端的擁塞窗口值cwnd驟減，充分利用信道的思路，研究了NewReno、TCP Cubic、Hybla三種典型TCP版本，我們發(fā)現(xiàn)它們有著各自的優(yōu)勢，和與之相適應的環(huán)境。

相對來說NewReno在算法上更易實現(xiàn)，它改進了Reno算法，考慮了一個發(fā)送窗口內(nèi)多個報文丟失的情況。Cubic主要針對可能發(fā)生高延遲的高速網(wǎng)絡，它的大量時間處在凹凸函數(shù)上一段較穩(wěn)定的狀態(tài)上，使網(wǎng)絡在尋求更大帶寬前能維持穩(wěn)定；另外，Cubic的窗口增長完全獨立于RTT，令RTT不同的流能公平地分享衛(wèi)星鏈路上提供的容量。Hybla主要應對于含地面或衛(wèi)星鏈路的異構網(wǎng)絡，把由衛(wèi)星鏈路引發(fā)的較長RTT的影響降到最低，為不同RTT的連接提供相同傳輸速率，確保RTT不同的流之間的公平性。

[參考文獻]

[1]Alain Pirovano & Fabien Garcia.A New Survey on Improving TCP Performances over Geostationary.Network and Communication Technologies，Vol.2，No.1.2013.

[2]劉志軍，陳繼光.一種改進的高速TCP擁塞控制機制.河南科技大學學報（自然科學版），2009，30（4）.

[3]高華峰.無線網(wǎng)絡中TCP擁塞控制機制的研究.南京郵電大學，2008.

[4]薛建生，王光興.一種基于網(wǎng)絡帶寬預測的TCP擁塞控制機制.小型微型計算機系統(tǒng)，2007，28（4）.