基于處理時延的衛星網絡TCP擁塞控制算法*

戴帥，肖楠，梁俊，袁天

(空軍工程大學 信息與導航學院，陜西 西安 710077)

0 引言

下一代衛星網絡是基于IP(internet protocol)的寬帶通信網絡。低軌(low earth orbit,LEO)衛星由于軌道高度低，具有傳輸時延和空間損耗小、通信距離遠、組網方式靈活、抗毀和抗干擾能力強以及能夠實現全球覆蓋等一系列優點。TCP(transmission control protocol)協議作為當前IP網絡主要使用的傳輸控制協議，其在LEO衛星網絡中的應用得到了廣泛的關注和研究。

目前，國內外有關衛星網絡TCP擁塞控制算法的研究成果大量涌現，如TCP Reno，TCP New Reno，TCP SACK，TCP Hybla以及TCP Vegas等[1]。其中，TCP Vegas算法能較好地預測網絡帶寬使用情況，有效應對衛星網絡的長時延、高帶寬等特點，在衛星網絡中有廣泛的應用前景。因此，如何在衛星網絡中更有效地使用TCP Vegas算法也是近年來研究的熱點。文獻[2]通過降低擁塞窗口增長速率提出了一種改進型的TCP Vegas 1算法，該算法通過犧牲系統吞吐量有效降低了網絡的擁塞概率；文獻[3]提出了一種Vegas-b算法，該算法通過加大擁塞窗口的增長速度克服了與TCP New Reno共存時的缺陷，并且能獲得比TCP New Reno更大的帶寬，提高了協議的公平性。文獻[4]中提出了一種改進的Vegas A算法，通過動態調整α和β值，改善擁塞控制機制，從而自動適應網絡狀況的變化，算法的改進主要表現于擁塞避免階段。

上述改進算法都是基于衛星鏈路的往返時延(round trip time，RTT)測量進行設計的，且大都是基于靜止軌道衛星網絡環境進行實驗仿真，并沒有考慮衛星節點間距離快速變化和高速移動的問題。在LEO衛星網絡中，由于衛星之間快速的相對移動、衛星網絡拓撲結構動態變化，使得衛星鏈路的往返時延不斷變化，導致TCP Vegas算法不能準確地計算網絡的期望吞吐量，從而造成網絡資源的浪費。同時，由于衛星間距離變化范圍的不同，傳統TCP Vegas算法存在帶寬分配的不公平性問題。

本文在分析LEO衛星網絡特性的基礎上，深入研究了衛星網絡TCP Vegas擁塞控制算法，針對Vegas算法在LEO衛星網絡環境中存在的問題，提出了一種基于處理時延的改進型擁塞控制算法——TCP Vegas_PD(TCP Vegas based on processing delay)。該算法針對網絡中衛星節點高速運動的特點，充分考慮LEO衛星網絡拓撲動態變化對RTT的影響以及帶寬分配的公平性，通過測量一次通信過程中各衛星節點的最大處理時延，屏蔽網絡拓撲結構變化對TCP Vegas算法性能的影響，從而更加精準地測量網絡狀態，提高了網絡吞吐效率，增加了網絡性能的穩定性，為衛星網絡TCP擁塞控制算法的改進提供了一個新思路。

1 衛星網絡特性對TCP協議性能的影響

TCP機制的有效運行依賴于下面3個假設[5]：①數據包的丟失一定是由網絡擁塞所引起的；②網絡的拓撲結構是穩定的；③通信路徑上的傳播時延也相對穩定，這些在LEO衛星網絡中并不適用。與地面有線網絡相比，LEO衛星網絡環境要復雜得多，存在許多影響TCP協議性能的因素，主要可以歸納為以下幾點：

(1) 往返時延動態變化

LEO衛星網絡具有高動態的連接特性，網絡拓撲結構頻繁變化會改變數據包傳輸時經歷的跳數和傳播距離，使RTT的測量值發生很大波動。由于TCP的超時重傳時間是基于RTT設置的，不準確的RTT測量值會導致TCP過早或過晚地重傳報文段，并縮小擁塞窗口，降低了吞吐量，同時造成網絡性能的不穩定。

(2) 傳播延遲長

在大多數LEO衛星通信系統中，單跳傳輸時延大約為20至25 ms。過長的RTT使得慢啟動(slow start)階段的TCP擁塞窗口增長速度變得十分緩慢。同時，長傳播延時在TCP檢測和恢復丟失數據操作上影響很大，降低了衛星網絡的吞吐效率。

(3) 信道誤碼率高[6]

通常在空間衛星通信環境下信道隨機誤碼率在10-4～10-7左右，同時衛星信道還受天氣影響。由于TCP協議默認信道出現丟包是網絡擁塞造成，因此當信道傳輸條件惡化，由鏈路誤碼造成數據丟失時，TCP協議會減少數據發送窗口值，錯誤地啟動擁塞控制策略，導致發送速率和吞吐量降低，不僅影響了TCP協議的傳輸效率，還浪費了衛星信道帶寬。

(4) 信道帶寬不對稱[7]

由于衛星通信系統地面發射設備昂貴、衛星轉發器資源有限、收發送功率和天線尺寸等條件的限制，衛星前向鏈路帶寬大于反向鏈路。帶寬不對稱性會造成確認速度慢、不必要的超時重傳和數據突發等問題，從而降低網絡的吞吐量。

(5) 通信鏈路易中斷

衛星通信具有高動態的連接特性，對于非靜止軌道衛星，連接可能會因為地面站切換、網絡拓撲結構改變、天氣情況以及軌道變化等多種原因而被周期性地中斷，這與TCP有效運行的穩定的有線鏈路環境有較大差異，阻礙了TCP協議在衛星網絡中性能的發揮。

綜上所述，LEO衛星通信環境與地面通信環境存在諸多差異，導致了傳統的TCP協議直接應用于在衛星環境中時傳輸效率低下，需要針對LEO衛星通信環境的特點對TCP協議作出適當的改進。

2 TCP Vegas算法簡介

TCP Vegas算法[8-9](以下簡稱Vegas算法)的基本原理是通過觀測RTT的變化來判斷網絡的擁塞狀況，并作出相應的調整。Vegas算法根據Expected_Rate(期望吞吐量)和Actual_Rate(實際吞吐量)的差值Δ來估計網絡中可用的帶寬。其核心算法如下：

Expected_Rate=cwnd(t)/Base_RTT，

(1)

Actual_Rate=cwnd(t)/RTT，

(2)

Δ=Expected_Rate-Actual_Rate，

(3)

式中：Base_RTT為所有觀察鏈路往返時延的最小值，一般為連接建立后的所發送第1個數據包的RTT，此后可隨每次測得的RTT值的情況進行不斷更新；cwnd(t)為當前擁塞窗口的大小，即可發送的數據包數；RTT為當前測得的鏈路往返時延。

若實際吞吐量和期望吞吐量數值很接近，Δ的值較小，可以認為網絡沒有發生擁塞；若實際吞吐量遠小于期望吞吐量，Δ的值較大，則網絡很有可能出現擁塞狀況。據此，Vegas算法可以更新擁塞窗口，以保證網絡傳輸的正常運行。調整擁塞窗口的算法可描述如下：

(4)

式中：δ=Δ·RTT；α和β為定義的2個門限值，且0<α<β，α觸發發送速率的提升，β觸發發送速率的降低，其經驗值分別為1和3[10]。

由于Vegas算法是根據實際網絡狀況來決定何時結束擁塞控制窗口的指數增長，而不是像TCP Reno等算法那樣根據丟包或預設的窗口上限來結束慢啟動，因此可以在避免發生擁塞的前提下，盡可能在慢啟動狀態使發送速率接近網絡可用帶寬，使TCP連接很快達到高吞吐量。在擁塞避免狀態，Vegas算法對擁塞控制窗口調節及時而平緩，能避免劇烈振蕩而穩定在最佳值附近。

3 LEO衛星網絡中TCP Vegas算法的改進

雖然現有地面網絡擁塞控制主要采用的是TCP Reno算法，但是衛星網絡的長時延使得Reno算法擁塞窗口增加緩慢且變化劇烈，導致網絡吞吐效率低下。Vegas算法由于采用了新的擁塞避免機制，能比較準確地測量網絡的擁塞狀況，所以Vegas算法比Reno算法更加適用于衛星網絡。但Vegas算法以RTT為主要參數來控制發送窗口的變化，而LEO衛星通信網的拓撲結構是實時高動態變化的，這會造成RTT的非擁塞原因增大。Vegas算法本身并沒有能力識別RTT的增大是由網絡擁塞造成的還是由路徑變化造成的。如果是路徑的改變導致RTT的增加Vegas算法也會減小發送窗口，浪費了網絡資源，降低了TCP協議的性能。

3.1 TCP Vegas在LEO衛星網絡中存在的問題

在LEO衛星網絡中，傳播時延隨著衛星之間距離以及傳輸路徑的變化而變化，通信距離每增加1 000 km，會帶來額外的13.3 ms的往返時延。以具有全球覆蓋能力的極軌道星座為例[11]，星座參數設置如表1所示。由于衛星之間高速的相對運動以及兩極地區星間鏈路的斷開與重建，其網絡拓撲結構變化頻率達平均3～4 min/次。此外，由于衛星星座覆蓋縫隙的存在(即反向運動衛星之間不建立星間鏈路)，使得網絡通信時延存在較大突變。

表1 LEO衛星網絡參數設置Table 1 LEO satellite network parameters configuration

通過STK場景仿真可知，該LEO衛星通信系統的空間拓撲結構如圖所1示。

圖1 LEO衛星系統空間分布示意圖Fig.1 LEO satellite system spatial distribution diagram

選取A地(34°N，109°S)與B地(47°N，88°S)為地面通信終端，對兩地之間通信往返時延RTT(未考慮衛星處理時延)進行仿真(仿真時間86 400 s)，結果如圖2所示。

由圖2可知，在不考慮衛星星上處理時延的情況下，A地至B地之間通信的RTT是實時變化的，其中最大RTT為328.6 ms(通信終端位于覆蓋縫隙兩側時)，最小RTT為33.6 ms，即由于通信路徑距離變化引起的往返時延差值高達295 ms。

一般情況下，Vegas算法認為當前測得的往返時延與最小往返時延的差值是排隊時延[12]。在LEO衛星網絡中，往返時延與最小往返時延的差值中， 很大一部分是由于傳播時延的變化引起的。巨大的傳播時延差值可能會隱藏掉排隊時延對往返時延的影響，成為決定往返時延的主要因素，致使Vegas算法不能準確預測網絡的擁塞狀況[13]。

此外，衛星間距離變化范圍的不同導致Vegas算法的性能也不同。衛星軌道高度越高，往返時延RTT的變化范圍越大，Vegas算法的性能也就越差。當衛星網絡拓撲結構改變使得端到端通信路徑長度變化范圍增大時，當前往返時延與最小往返時延的傳播時延差值增加，而這種增加與網絡的擁塞狀況無關，相反地，發送終端應該根據帶寬時延積的增大，相應地增大擁塞窗口。但是，在Vegas算法中，發送終端會誤認為往返時延增大是由于網絡狀況惡化引起的，進而減小擁塞窗口。可見，在LEO衛星網絡中，由于網絡拓撲結構動態變化使得往返時延變化較大，導致Vegas算法存在帶寬分配的不公平性。

3.2 Vegas_PD算法

針對以上問題，本文提出一種新的擁塞控制算法——Vegas_PD算法。該算法在保留原Vegas算法擁塞控制機制的基礎上修改了最小往返時延的計算方法，即將空間傳播時延與衛星星上處理時延分離開來。由于衛星空間傳播時延不能反映網絡的擁塞狀況，因此Vegas_PD算法只利用星上處理時延作為擁塞窗口調整的依據，從而更加精準地反映網絡狀態的變化情況。

圖2 A地-B地往返時延變化情況Fig.2 Position A-B round-trip delay changes

另一方面，考慮到一次通信過程中所歷經衛星的最大星上處理時延完全可以反映整個網絡的擁塞情況，Vegas_PD算法只需測量一次通信過程中的最大星上處理時延，然后根據每次測得的最大處理時延與基準處理時延的差值動態調整擁塞窗口的大小，從而有效屏蔽了由于衛星網絡拓撲結構改變帶來的時延變化的影響，提高網絡的吞吐效率。

TCP協議報文格式選項部分(長度可變)的時間戳選項(10字節)主要用來計算往返時延RTT和防止序號繞回。在傳統TCP協議中，時間戳選項主要包括時間戳字段(4字節)和時間戳回送回答字段(4字節)，發送終端在發送報文段時把當前時鐘的時間值放入時間戳字段，接收方在確認該報文段時把時間戳字段復制到時間戳回送回答字段，因此發送方在收到確認報文后可以精確地計算出RTT。

在Vegas_PD算法中，為了精確獲得每顆衛星的星上處理時間，需要對時間戳選項的功能做適當的修改，即時間戳不僅記錄報文段的發送和接收時間，還需記錄該報文段每一次經衛星轉發時入隊列時間(in_queue_time)和出隊列時間(out_queue_time)。同時，在選項部分增加4字節的處理時間記錄字段node_processing_time，記錄最大處理時間max_node_processing_time。當該報文段被轉發至另一顆衛星時，由當前衛星計算出上一顆衛星的星上處理時間并由處理時間記錄字段進行記錄。

node_processing_time=out_queue_time-in_queue_time.

(5)

與此同時，時間戳選項記錄下該衛星的入/出隊列時間，在報文段下一次轉發時再次計算星上處理時間，若該處理時間大于上一顆衛星的處理時間，則處理時間記錄字段更新為當前處理時間，否則保持不變。當報文段最終被轉發至目的終端時，由接收端計算出最后一顆衛星的處理時間并與處理時間記錄字段的記錄值進行比較。這樣就可以保證當數據報文段從發送端成功發送至接收段整個過程中處理時間記錄字段始終記錄的是最大星上處理時間，該處理時間隨接收端的返回ACK(acknoweldgement)發送至發送端，發送端依據網絡中衛星的max_node_processing_time判斷網絡當前擁塞狀況。

需要說明的是，在Vegas_PD算法中，由于cwnd(t)大小的調整不再依據往返時延RTT，原Vegas算法中利用期望吞吐量與實際吞吐量差值來計算Δ值的算法已不再成立。考慮衛星的星上處理時間主要是報文段的排隊時間，可以利用當前報文段當前測得的排隊時間與衛星最大排隊時間的比值作為Δ值。假設星上緩存大小為sat_buffer，衛星轉發速率為v_sat，則星上的最大排隊時延為

(6)

一個報文段從發送端傳輸至接收端的最大排隊時延為max_node_processing_time，則Δ為

(7)

一般認為，若當前隊列長度超過最大隊列長度的2/3時，認為網絡負載較重，發生擁塞概率較大；若當前隊列長度小于最大隊列長度的1/3時，則認為網絡負載較輕，發生擁塞概率較小；否則網絡處于正常工作狀態。因此，取門限值α=1/3，β=2/3，結合式(4)，Vegas_PD算法中擁塞窗口調整的核心算法如下：

(8)

式中：δ=Δ。

此外，由于衛星網絡拓撲結構改變造成的時延增大有可能超過發送端的超時重傳時間RTO(retransmission time-out)，從而引發發送端擁塞窗口減半重新進入擁塞避免階段，因此需要考慮每一次時延變化對RTO的影響。RFC 2988建議使用下式計算RTO：

RTO=RTTs+4RTTD,

(9)

式中：RTTs為加權平均往返時延；RTTD為RTT偏差的加權平均值。

每當第1次測量得到RTT樣本時，就取所測量得到的RTT樣本值，以后每次測量得到一個新的RTT樣本，RTTs按照下式進行更新：

RTTs(i+1)=(1-θ)RTTs(i)+θ·RTT(i+1)，

(10)

式中：0≤θ≤1，θ值越大表示新的RTTs值受新的RTT樣本的影響越大，RFC 2988推薦的θ值為0.125。

RTTD是與RTTs和RTT樣本之差有關。RFC 2988建議，當第1次測量時，RTTD值取為測量到的RTT樣本值的一半，在以后測量中，則使用下式更新：

RTTD(i+1)=(1-λ)RTTD(i)+λ|RTTs(i+1)-

RTT(i+1)|，

(11)

式中：0≤λ≤1，其推薦值是0.25。

Vegas_PD算法的具體實現流程如圖3所示。

圖3 Vegas_PD算法的基本流程Fig.3 Vegas_PD algorithm of the basic flow chart

4 算法性能仿真

為了驗證TCP Vegas_PD算法的性能，本文采用了以下2種仿真軟件：①衛星仿真軟件STK，主要用來仿真衛星網絡拓撲結構，版本為8.1.1；②網絡仿真軟件NS2，主要用來仿真算法性能，版本為2.28。仿真運行環境為Windows XP。

本文仿真實驗采用的網絡拓撲結構如圖4所示。

其中LEO衛星通信網采用3.1中的衛星網絡模型，具體參數設置如表1所示；選取A地作為地面固定發送端，B地作為固定地面接收端，對2個終端之間采用Vegas_PD算法和傳統Vegas算法通過LEO衛星網進行通信時的算法性能進行仿真分析，主要網絡仿真參數設置如表2所示。

圖4 實驗仿真拓撲結構圖Fig.4 Experimental simulation topological structure

表2 主要網絡仿真參數設置Table 2 Main network simulation parameters Settings

仿真參數衛星緩存/packets星上轉發速率/(Mbit·s-1)星間鏈路帶寬/MHz星地鏈路帶寬/MHz報文長度/bit初始窗口/packets取值5010251520030

使用上述LEO衛星網絡拓撲結構和仿真參數配置，分別對Vegas算法和Vegas_PD算法進行了仿真，仿真時間為0～36 000 s，得仿真結果如圖5，6所示。圖6給出了網絡吞吐率的比較(仿真時間3 600 s)，本文吞吐率定義單位時間內為衛星實際轉發的數據量與所能轉發的最大數據量的比值。

圖5 Vegas_PD算法與Vegas算法擁塞窗口變化比較Fig.5 Vegas_PD algorithm compared with Vegas algorithm congestion window changes

圖6 Vegas_PD算法與Vegas算法吞吐率變化比較Fig.6 Vegas_PD algorithm compared with Vegas algorithm throughput rate changes

通過仿真可知，由于Vegas_PD算法屏蔽了衛星網絡拓撲結構改變帶來的影響，僅僅利用星上排隊時延作為擁塞窗口調整的依據，使得擁塞窗口的變化更能精確反映出當前網絡態。傳統Vegas算法利用RTT作為窗口調整依據，衛星網絡拓撲結構的改變對算法性能造成了較大影響。圖5中，隨著RTT的不斷增大擁塞窗口持續減小，特別是當通信終端處于覆蓋縫隙兩側時，cwnd的值隨著RTT的急劇增大減小至0，但實際上此時RTT的變化只是由于網絡拓撲結構的變化造成的，網絡并未處于擁塞狀態。由于Vegas算法未能正確區分RTT增大的原因，導致cwnd錯誤地減小，浪費了大量衛星資源，同時由于后續通信過程中沒有足夠且持續減小的RTT，使得cwnd無法增至初始窗口(最大為17)。從圖中觀察還可發現，Vegas_PD算法擁塞窗口的變化范圍為27～45(Vegas算法擁塞窗口變化范圍為0～32)，提高了網絡的穩定性。

由圖6可知，Vegas_PD算法的平均吞吐率在0.587 8，而Vegas算法的平均吞吐率只有0.341 5，相比之下提高了61.15%，且Vegas_PD算法的吞吐量上下波動較小，而Vegas算法由于受擁塞窗口減半的影響上下波動較大，體現了Vegas_PD算法在系統穩定性上的優越性。

為了驗證Vegas_PD算法的公平性，在上述LEO衛星網絡拓撲結構中，使用軌道高度分別為780，1 000，1 450，2 000與2 500 km的衛星網絡對Vegas_PD算法及Vegas算法的吞吐率進行仿真，結果如表3所示。

表3 平均吞吐率比較 Table 3 Average throughput rate comparison

從表2中可以看出，隨著衛星間距離變化范圍的增大，Vegas算法在衛星網絡中的性能不斷下降，而在Vegas_PD算法中，衛星之間的距離變化對吞吐率影響很小，幾種情況下的吞吐率幾乎相同。由此可知，Vegas_PD算法可以改善Vegas算法中網絡資源分配的不公平性，使時延變化較長業務的吞吐率可以和其他業務的吞吐率達到同一水平。在Vegas算法下，當衛星軌道高度為2 000 km時，吞吐率比軌道高度為780 km時低67.14%，而在Vegas_PD算法下，吞吐率僅相差7.2%。

5 結束語

與傳統TCP Vegas算法相比，TCP Vegas_PD算法有效屏蔽了LEO網絡高動態變化的拓撲結構帶來的RTT的劇烈變化對Vegas算法性能的影響，利用星上處理時延作為擁塞窗口調整的依據更加精準地反映了當前網絡狀態變化情況，提高了衛星網絡資源的利用率。通過STK場景仿真與NS2網絡仿真，驗證了Vegas_PD算法的有效性，結果表明Vegas_PD算法在系統吞吐量上較傳統Vegas算法有較大提高，且表現出了較好的公平性。

參考文獻：

[1] 劉光華,王輝.LEO衛星網絡中TCP協議性能研究[J].計算機工程,2010,36(14): 96-98.

LIU Guang-hua, WANG Hui. Research of TCP Protocol Performance in LEO Satellite Network[J]. Computer Engineering, 2010,36(14): 96-98.

[2] 拱長青,趙志剛,王光興. LEO衛星網絡中TCP Vegas擁塞控制算法研究[J].小型微型計算機系統,2006,27(1): 54-57.

GONG Chang-qing, ZHAO Zhi-gang, WANG Guang-xing. Research of TCP Vegas Congestion Control Algorithm over LEO Satellite Networks[J]. Journal of Chinese Computer Systems，2006,27(1): 54-57.

[3] 王斌,陳元琰,馮偉,等.TCP Vegas-b：TCP Vegas改進算法[J].計算機工程與設計,2011,32(2): 438-441.

WANG Bin, CHEN Yuan-yan,FENG Wei,et al. TCP Vegas-b: Enhanced TCP Vegas Congestion Control Algorithm[J]. Computer Engineering and Design, 2011,32(2): 438-441.

[4] 王斌，陳元琰，胡愚. TCP Vegas擁塞避免機制的改進算法[J].計算機應用，2010，30(9)：2486-2500.

WANG Bin, CHEN Yuan-yan, HU Yu. TCP Vegas-W：Enhanced TCP Vegas Congestion Avoidance Mechanism[J]. Journal of Computer Applications，2010，30(9)：2486-2500.

[5] SRIJITH K N, Lillykutty Jacob, ANANDA A L. TCP Vegas-A: Improving the Performance of TCP Vegas [J]. Computer Communications, 2005, 28(4): 429-440.

[6] 王平,顧學邁.LEO衛星網絡中TCP協議性能及路由策略研究[J].南京理工大學學報,2007,31(1): 87-91.

WANG Ping, GU Xue-mai. Routing Strategy to Avoid Blind Retransmission of TCP in LEO Satellite Network. Journal of Nanjing University of Science and Technology, 2007,31(1): 87-91.

[7] XIAO Xing-quan，FU Zhong,LIU Ge. A Backup Data Network for Power System Automations Based on Satellite Communication[C]∥IEEE/International Conference on Power System Technology，Washington DC:AIA,2010:158-164.

[8] Lawrence S Brakmo, Sean W O’Malley, Larry L Peterson. TCP Vegas: New Techniques for Congestion Detection and Avoidance[C]∥Proceedings of ACM SIGCOMM’94，USA: ACM, 1994:24-35.

[9] Andrea De Vendictis,Andrea Baiocchi,Michela Bonacci. Analysis and Enhancement of TCP Vegas Congestion Control in a Mixed TCP Vegas and TCP Reno Network Scenario [J].Performance Evaluation (S0166-5316), 2003, 53(3): 225-253.

[10] BRAKMO L S, PETERSON L. TCP Vegas: End to End Congestion Avoidance on a Global Internet [J]. IEEE Journal of Selected Areas in Communication (S0733-8716), 13(8): 1465-1480, 1995.

[11] 萬鵬，王瑞軍，黃薇. 空間信息傳輸TCP擴展協議研究與性能分析[J].飛行器測控學報，2010，18(6)：11-16.

WAN Peng，WANG Rui-jun，HUANG Wei. Analysis of the Performance of TCP and Its Extension Protocol for Space Communication[J]. Journal of Spacecraft TT&C Technology，2010，18(6)：11-16.

[12] 顧明，張軍，蘇東林. 大帶寬時延積網絡TCP Vegas自適應慢啟動算法[J]. 電訊技術，2007，15(4)：27-30.

GU Ming, ZHANG Jun, SU Dong-lin. An Adaptive Slow Start Algorithm of TCP for Large BDP Networks Vegas[J]. Telecommunication Engineering，2007，15(4)：27-30.

[13] 官駿鳴,孫恩昌,方濟平,等.衛星鏈路上TCP協議問題透析[J].無線通信技術,2004，13(2): 47-50.

GUAN Jun-ming, SUN En-chang, FANG Ji-Ping，et al. Performance Analysis of TCP over Satellite Link[J].Wireless Communication Technology, 2004，13(2):47-50.