一種適用于地球空間傳感器網絡的TCP Vegas模型

姜月秋，關啟學，田 野，關世杰

(沈陽理工大學信息科學與工程學院，沈陽 110159)

0 引 言

地球空間傳感器網絡[1-2]是將無線傳感器網絡(Wireless sensor network, WSN)與地理信息系統(tǒng)(Geographic information systems, GIS)，以及衛(wèi)星遙感、全球衛(wèi)星定位系統(tǒng)(Global positioning systems, GPS)等技術進行有效交叉與融合的網絡，且在環(huán)境監(jiān)測、災害監(jiān)測、遠程醫(yī)療、智能交通、國防軍事等許多領域都具有廣闊的應用前景。然而空間網絡相比于地面網絡而言，其具有的往返時延長、誤碼率高和帶寬不對稱等特點，使得原本基于確認時鐘的傳輸控制協(xié)議[3-4](Transmission Control Protocol Reno，TCP Reno)應用到空間網絡時產生顯著的性能下降。而在眾多TCP協(xié)議的改進方案中，相比于TCP Reno具有更高且穩(wěn)定的吞吐量以及更小分組丟失率[5]的TCP Vegas協(xié)議[6-7]已成為空間網絡傳輸協(xié)議的研究熱點。同時，TCP Vegas也因此被空間數據系統(tǒng)咨詢委員會(Consultative Committee for Space Data Systems，CCSDS)所提出的空間通信協(xié)議規(guī)范傳輸協(xié)議[8-10](Space Communications Protocol Specification-Transport Protocol，SCPS-TP)指定為默認的擁塞控制算法。

TCP Vegas是一種基于時延進行帶寬預測的傳輸協(xié)議。其擁塞控制的原理是，首先利用數據分組的發(fā)送時刻及其所對應確認分組(Acknowledgment，ACK)的到達時刻計算鏈路的往返時延(Round-trip time，RTT)，然后根據RTT和擁塞窗口(congestion window，cwnd)的大小計算鏈路的期望吞吐量和實際吞吐量，再根據期望吞吐量和實際吞吐量的差值來估計網絡的實際狀況，最后通過調整cwnd的大小來控制注入網絡的數據分組數量，以避免出現(xiàn)傳輸鏈路中數據分組過多所導致的網絡擁塞和數據分組過少所導致的網絡吞吐量下降的現(xiàn)象，從而達到提升通信鏈路帶寬利用率的目的。

文獻[11]指出了在帶寬不對稱的鏈路中，反向鏈路會先于正向鏈路達到飽和而進入擁塞狀態(tài)，導致確認分組延遲到達或丟失，進而誤導依靠確認分組反饋信息的擁塞控制算法提前進入對數據分組的擁塞控制階段，使得擁塞控制算法通過減少注入正向鏈路中數據分組的數量，間接地減少注入反向鏈路中確認分組的數目，從而達到緩解反向鏈路擁塞的目的。而在空間通信鏈路中，特別是具有正反向鏈路帶寬高度不對稱的衛(wèi)星通信鏈路，當正向鏈路高速傳遞數據分組時，極易導致傳輸確認分組的反向鏈路發(fā)生擁塞。如果反向鏈路中還存在其他背景流量，這種由帶寬不對稱造成的擁塞現(xiàn)象會進一步加劇。由TCP Vegas原理可知，當反向鏈路發(fā)生擁塞時，確認分組會在反向瓶頸鏈路出現(xiàn)排隊現(xiàn)象，進而導致反向鏈路傳輸時延增加，引起實測RTT的增大，誤導TCP Vegas對正向鏈路實施擁塞控制，降低了協(xié)議的性能。文獻[12]分析并指出了在長往返時延的空間通信鏈路中，正反向鏈路帶寬的非對稱性會進一步降低通過確認分組獲取信道狀態(tài)信息的協(xié)議的性能。

目前，針對TCP Vegas及基于時延進行擁塞控制的傳輸協(xié)議的改進方案[13-15]主要集中在提升時延測算精度和提高擁塞窗口調整效率的兩個方面。較為典型的擁塞控制方案主要分為下述三類。

1)基于時延的擁塞控制改進方案

文獻[16]針對衛(wèi)星網絡通信時延動態(tài)變化導致的擁塞控制問題，提出了一種基于鏈路長度的帶寬估計算法。該算法通過衛(wèi)星鏈路長度優(yōu)化最小往返時延的計算，實現(xiàn)了慢啟動閾值、擁塞窗口和超時重傳定時器中相關參數增益因子的合理調整，有效地提升了衛(wèi)星網絡的吞吐量。文獻[17-19]詳細分析了TCP Vegas相對于TCP Reno在不對稱鏈路中性能劇烈下降的原因，并基于時間戳計算數據分組在正向鏈路中的排隊時延，再以此修正TCP Vegas算法中實際吞吐量的計算值，使其能夠在一定程度上減少反向鏈路排隊時延對TCP Vegas擁塞控制算法的影響。文獻[20]提出了一種不修正原始TCP Vegas擁塞控制算法中關鍵參數的方法，而是依靠時間戳測算正向鏈路排隊時延的變化量，并以此為正向鏈路發(fā)生擁塞的輔助判斷條件，使其擁塞控制算法能夠更加準確地控制正向鏈路的擁塞問題。

2)基于數據鏈路中間節(jié)點的擁塞控制改進方案

文獻[21]在利用路由器進行正向鏈路和反向鏈路排隊時延測量的基礎上，提出了同時修正實際吞吐量和基礎往返時延(baseRTT)的計算方法，進一步降低了反向鏈路的狀態(tài)對擁塞控制算法的影響。文獻[22-23]考慮反向鏈路確認分組數目對正向鏈路擁塞控制的影響，通過調整鏈路上中間轉發(fā)節(jié)點的確認分組接收窗口大小來限制數據分組的發(fā)送速率，以達到提升擁塞控制效果的目的。文獻[24]基于跨層反饋思想，提出了一種可以根據中間路由器的狀態(tài)信息計算出丟包的可能性來提前預測擁塞的方法，從而提前避免擁塞的發(fā)生，保證了數據分組的傳輸速率，提高了網絡的性能。

3)基于負載均衡的擁塞控制改進方案

文獻[25]針對衛(wèi)星鏈路，在詳細分析了跳到跳確認方式與端到端確認方式不同的基礎上，提出了一種結合負載因子的跳到跳確認機制的傳輸協(xié)議框架，有效消除了無線鏈路造成的傳輸錯誤的影響，提高了通信鏈路的利用率。文獻[26]在TCP Vegas的基礎上提出了一種基于分組排隊時延的多路擁塞控制改進算法wVegas，該改進算法將單條通信鏈路的擁塞控制問題轉換成多條通信鏈路的負載均衡問題，使得注入某條擁塞鏈路的數據分組可以分流到其他通信鏈路上，從而達到提升總體通信鏈路帶寬利用率的目的。

綜上，針對由鏈路帶寬非對稱性引起的反向鏈路擁塞問題的解決方案并不多，雖然上述改進方案在一定程度上考慮了反向鏈路狀態(tài)對正向鏈路擁塞控制的影響，但依然沒有針對反向鏈路中確認分組的擁塞控制問題進行直接而有效地控制，導致在反向鏈路發(fā)生擁塞時，只能依靠正向鏈路擁塞控制方法以降低數據分組吞吐量為代價的方式對反向鏈路實施間接的擁塞控制，進而限制了TCP Vegas協(xié)議的性能。

因此，本文從與TCP Vegas配合的確認機制入手，提出了一種具有主動反向鏈路擁塞控制能力的端到端TCP Vegas擁塞控制模型，從而解決了反向鏈路先于正向鏈路發(fā)生擁塞時正向鏈路吞吐量降低的問題，提升了TCP Vegas協(xié)議的整體性能。

1 TCP Vegas改進模型TCP Vegas-RCC

本文提出的TCP Vegas-RCC擁塞控制模型，采用基于反向鏈路排隊時延的延遲確認機制主動控制注入反向鏈路中的確認分組數目，并輔以修正后的TCP Vegas擁塞控制算法間接地加強對反向鏈路擁塞的控制效果，進而解決反向鏈路先于正向鏈路發(fā)生擁塞時正向鏈路吞吐量下降的問題。

該改進模型的主要修改內容為在原始TCP Vegas協(xié)議的基礎上，調整確認分組發(fā)送間隔時間來控制注入反向鏈路中確認分組的數目，使確認分組在反向鏈路中保持適當的排隊，以維持一個較高確認頻率，同時利用相鄰確認分組的發(fā)送間隔時間修正原始TCP Vegas中baseRTT的計算值，降低確認分組提前和滯后發(fā)送對RTT測算的影響。

1.1 TCP Vegas-RCC模型結構

該模型由控制確認分組發(fā)送頻率的延遲確認機制和完成正向鏈路擁塞控制的TCP Vegas修正算法組成，如圖1所示。

圖1 TCP Vegas-RCC模型圖

其中，延遲確認機制主要由位于數據發(fā)送端的確認延遲時間計算模塊、位于數據接收端的延遲時鐘設置模塊和相鄰確認分組實際發(fā)送間隔時間計算模塊三個部分組成。

該模型在初始階段，接收端的確認延遲時鐘(最大的確認分組延遲發(fā)送的間隔時間)為兩個相鄰確認分組發(fā)送的間隔時間。其初始值為0 s，即接收端收到一個未被確認的數據分組后立即發(fā)送其對應的確認分組，等效于沒有延遲。

其具體一輪的確認分組發(fā)送頻率調整過程為：發(fā)送端向接收端發(fā)送數據分組。接收端從接收到數據分組的首部中提取其所攜帶的確認延遲間隔時間(初始值為0 s)，并以此設置確認延遲時鐘；同時，根據所收到數據分組的狀態(tài)決定是否采用此間隔時間發(fā)送其對應的確認分組；在發(fā)送確認分組時，將當前確認分組與其前一個確認分組發(fā)送時的實際間隔時間寫入該確認分組的首部。發(fā)送端收到該確認分組后，在利用修正后的TCP Vegas擁塞控制算法進行間接的反向鏈路擁塞控制的同時，根據確認分組中所攜帶的實際發(fā)送間隔時間計算該確認分組在反向鏈路傳輸過程中的排隊時延，并以此作為評估反向鏈路確認頻率的依據，計算下一輪確認分組應該延遲發(fā)送的間隔時間；最后，將所計算的確認間隔時間寫入到下一個待發(fā)送的數據分組首部。當此數據分組到達接收端后，即開啟下一輪的調整過程。

1.2 延遲確認策略

本模型中采用的動態(tài)延遲確認機制在基于傳統(tǒng)累積確認機制[27]的基礎上，引入了基于確認間隔時間的確認分組延遲發(fā)送方法，以維持反向鏈路中的確認頻率。文獻[28]指出采用延遲確認的方法會由于發(fā)送端接收到確認分組比預期的要慢或少，導致基于確認時鐘的傳統(tǒng)TCP Reno協(xié)議將會出現(xiàn)下述三個問題。

1)突發(fā)性數據分組流量的問題

假設接收端發(fā)送的n個確認分組，由于反向鏈路擁塞而產生丟包或被延遲發(fā)送，最后只有1個確認分組按時到達發(fā)送端，而原來靠依次接收n個確認分組并逐漸將擁塞窗口增加n個數據分組大小的“緩慢”過程，變成了接收端只收到1個(唯一的)確認分組就將擁塞窗口一次性且大幅度地增長n個數據分組大小的“突發(fā)”過程，導致?lián)砣翱谕蝗辉龃?，增加了數據分組丟失的風險。n值越大，數據分組丟失的概率越大，特別是在慢啟動階段，過快增長的擁塞窗口會導致短時間內向正向鏈路注入大量的數據分組，從而進一步加劇了正向鏈路中數據分組丟失的風險。

由于TCP Vegas協(xié)議不是基于確認時鐘的協(xié)議，其擁塞控制依據的是吞吐量的變化情況而不是確認分組到達發(fā)送端的頻率。即使TCP Vegas對確認分組到達發(fā)送端的頻率的變化不敏感，但吞吐量的計算還是要依賴于確認分組的到達。因此，TCP Vegas在慢啟動階段采用延遲確認機制時依然會產生突發(fā)性數據分組流量的問題。而本文提出的TCP Vegas-RCC，判斷處于慢啟動階段和擁塞避免階段的方式雖然與原始TCP Vegas相同，但是其延遲確認機制開啟條件與原始TCP Vegas進入擁塞避免階段的條件(期望吞吐量與實際吞吐量的差值大于預先設定的閾值γ)相同，即延遲確認機制只在TCP Vegas-RCC進入擁塞避免階段后啟動，而在慢啟動階段并不開啟，從而避免了在慢啟動階段中突發(fā)性數據分組流量問題的產生。

2)擁塞窗口增長緩慢的問題

由于傳統(tǒng)的TCP Reno是依靠收到確認分組的個數而不是確認分組能夠確認的數據總量來調整擁塞窗口的，因此確認分組成功到達發(fā)送端的數量減少必然會降低擁塞窗口增長的速度。

而本模型采用的延遲確認機制，不僅能解決問題1，還能解決問題2。這是因為在擁塞窗口增長緩慢時，延遲確認機制可以根據確認分組在反向鏈路排隊時延的變小程度，縮短確認分組的發(fā)送間隔時間，提高確認頻率，進而加快擁塞窗口增長。

3)快速重傳機制失效的問題

傳統(tǒng)的TCP Reno協(xié)議在收到3個重復的確認分組后就立即開始快速重傳機制[29]。由于確認分組的延遲到達，在發(fā)送端計時器超時前可能接收不到足夠數量(3個)的重復確認分組，進而導致發(fā)送端無法在數據分組丟失時進入快速重傳階段，因此對丟失的數據分組重傳只能發(fā)生在重傳計時器超時之后，這樣一來就降低了協(xié)議的性能。

文獻[6-7]指出TCP Vegas改進了TCP Reno的重傳機制，即當TCP Vegas收到1個重復的確認分組時不用等到收到3個重復的確認分組，就可以利用其攜帶的時間戳計算傳輸的時間間隔，并與事先設定的快速重傳超時門限值比較來判斷是否進行快速重傳。而在有多個數據分組丟失時，也能在第一個丟失的數據分組成功重傳后，根據之后第一個或第二個到來的確認分組(非重復確認)攜帶的時間戳以同樣的方式來決定是否進行快速重傳。雖然原始TCP Vegas從提出之時就已解決了快速重傳依賴于收到指定重復確認分組數目的問題，但如果擁塞窗口較小、或發(fā)送端由于超時而進入慢啟動、或長達多余一個往返時延的時間內發(fā)送端沒有數據分組發(fā)送的三種情況中任何一個出現(xiàn)時，則由于數據分組到達接收端的頻率過低，同樣也有可能導致發(fā)送端因沒有收到足夠數目的確認分組而無法進行快速重傳，導致協(xié)議性能下降的現(xiàn)象產生。因此，在數據接收端須設置一個確認分組超時時鐘，以保證確認分組在數據發(fā)送端超時前到達。本文將確認分組的超時時鐘設為1.2倍的往返時延。

1.3 相鄰確認分組發(fā)送間隔時間的計算

為了在反向鏈路中維持一個較高的確認頻率，則須在反向鏈路中保持一定長度的確認分組隊列。因此，相鄰確認分組發(fā)送的間隔時間應該與確認分組的排隊時延相關。如果以相對于前一個確認分組發(fā)送時的間隔時間T發(fā)送下一個確認分組，能夠使得這個確認分組在反向鏈路中的排隊時延T′減少(或增加)，即可達到維持反向鏈路中確認分組排隊規(guī)模的目的。在正反向鏈路帶寬高度不對稱的空間通信環(huán)境中，當反向鏈路先于正向鏈路發(fā)生擁塞時，不考慮誤碼造成分組丟失的情況下，導致往返時延變化的主要因素是反向鏈路中確認分組排隊時延的變化和確認分組發(fā)送間隔時間的變化(由于此時正向鏈路沒有發(fā)生擁塞，因此正向鏈路數據分組排隊時延忽略不計)，即往返時延的變化量滿足

TΔRTT=ΔT+ΔT′+ΔT″

(1)

式中：TΔRTT為往返時延的變化量，ΔT為確認分組發(fā)送間隔時間的變化量，ΔT′為反向鏈路中確認分組排隊時延的變化量，ΔT″為正向鏈路中數據分組排隊時延的變化量(反向鏈路擁塞時，該值趨近于0)。

若是在正向鏈路先于反向鏈路產生擁塞的網絡環(huán)境中，ΔT′可以忽略不計，反而ΔT″作為鏈路的主要時延。無論哪個方向的鏈路發(fā)生擁塞，TCP Vegas-RCC中針對正向鏈路擁塞控制的算法都會啟動。但當反向鏈路發(fā)生擁塞時，延遲確認機制會降低確認頻率，主動地減少向反向鏈路中注入確認分組的數量，從而緩解反向鏈路的擁塞問題；而當反向鏈路中排隊的確認分組數目過少時，延遲確認機制又會主動地提高確認頻率，促進擁塞窗口的快速增長，以提高正向鏈路的吞吐量。

由于測得最小往返時延TbaseRTT時，正向鏈路和反向鏈路均沒有排隊產生，即正向鏈路時延排隊時延和反向鏈路排隊時延都為0。因此由式(1)可得

(2)

式中：TRTTi為本輪測得的往返時延，Ti為本輪確認分組發(fā)送的間隔時間，T′i為本輪反向鏈路中確認分組排隊時延(初值為0)。

本文假設在反向鏈路發(fā)生擁塞時，確認分組發(fā)送的間隔時間變化量與確認分組在反向鏈路中的排隊時延變化量相當，即ΔT=ΔT′。因此，下一輪確認分組發(fā)送的間隔時間滿足

Ti+1=Ti+T′i-T′i-1,i=1,2,…

(3)

式中：Ti+1為下一輪確認分組發(fā)送的間隔時間，T′i-1為上一輪反向鏈路中確認分組排隊時延。

為了維持較高的確認頻率，反向鏈路應該維持一定的確認分組的隊列規(guī)模。因此，當反向鏈路的擁塞程度加劇時，須逐漸地減少注入反向鏈路的確認分組數量，即適當地增加確認分組發(fā)送的時間間隔；而當反向鏈路從擁塞狀態(tài)恢復時，應該快速地提升反向鏈路的確認頻率，即大幅度地減少確認分組發(fā)送的時間間隔。因此計算新一輪確認分組發(fā)送時間間隔算法如圖2所示。

圖2 計算確認分組發(fā)送時間間隔算法流程圖

1)確認分組發(fā)送的間隔時間下限的確定

為了避免反向鏈路中確認分組隊列過長，確認分組發(fā)送的間隔時間應避免過短，須設置確認延遲的最小間隔時間(即為間隔時間的下限)應不小于TCP Reno協(xié)議以正常頻率發(fā)送確認分組的間隔時間ΔT。

設Δt為實際兩個相鄰到達發(fā)送端的確認分組的間隔時間。

設A為所允許的正常兩個相鄰到達發(fā)送端的確認分組所確認數據量的差額(單位為字節(jié))。為了達到與TCP Reno協(xié)議所采用的累積確認機制的相同效果，該值取2個最大分組長度，即每接收兩個數據分組就對應發(fā)送一個確認分組。

則確認分組發(fā)送的最小間隔時間Tmin的計算式如下所示：

Tmin=ΔT=(A/Δa)×Δt

(4)

2)確認分組發(fā)送的間隔時間上限的確定

為了保證TCP Vegas-RCC調整擁塞窗口時有足夠的反饋信息，則必須保證數據發(fā)送端在擁塞窗口調整周期(2個RTT)內成功接收到2個確認分組，因此確認分組發(fā)送的間隔時間不應超過1個RTT的時間TRTT，則確認分組發(fā)送的最大隔時間Tmax的計算式如下所示：

Tmax=TRTT

(5)

最終，新一輪確認分組發(fā)送的間隔時間Ti+1的計算式如下所示：

Ti+1=min{max{Ti+1,Tmin},Tmax},i=1,2,…

(6)

1.4 TCP Vegas的修正

原始TCP Vegas首先分別使用式(7)和式(8)來計算期望傳輸速率和實際傳輸速率，

Vexp=Ct/TbaseRTT

(7)

Vact=Ct/TRTT

(8)

式中：Vexp為期望傳輸速率，Vact為實際傳輸速率，Ct為t時刻的擁塞窗口大??；TbaseRTT為發(fā)送端觀測到的當前鏈路的最小往返時延；TRTT為t時刻當前鏈路實測的往返時延。

之后再利用式(9)計算出Δ，

Δ=(Vexp-Vact)×TbaseRTT=

(1-TbaseRTT/TRTT)×Ct

(9)

最后根據式(10)調整擁塞窗口的大小，以盡可能地使正向鏈路中數據分組的個數接近正向鏈路的容量。

(10)

由式(10)可知，擁塞窗口調整算法與Δ,α和β的取值有關，而由式(9)可知Δ的測算又與當時的Ct以及TRTT和TbaseRTT的比值有關。因此當α和β值分別固定取1和3時，原始TCP Vegas正向鏈路的擁塞控制效果取決于TRTT和TbaseRTT的比值。

而由于本文提出的TCP Vegas-RCC模型在反向鏈路中采用延遲確認機制，確認分組的延遲發(fā)送影響了往返時延的測算，因此需要分別對原始協(xié)議中TRTT和TbaseRTT進行修正，設兩者對應的修正量分別為T′RTT和T′baseRTT，對應修正后的擁塞窗口大小為C′t。

由于確認分組不是在收到對應的數據分組時立即發(fā)送，因此測算的鏈路最小往返時延時應該包含確認分組延遲發(fā)送的時間，該延遲時間近似等于相鄰確認分組發(fā)送的間隔時間ΔT，即當前T′baseRTTi等于之前的T′baseRTTi-1與ΔTi的和：

(11)

由于在數據分組發(fā)送初期，反向鏈路沒有確認分組的排隊現(xiàn)象，因此TbaseRTT的初始測算值無需修正。

同時，由于測算TRTT時，已經包含了確認分組延遲發(fā)送的時間，因此不對TRTT進行追加ΔT的修正處理，即

T′RTTi=TRTTi,i=1,2,…

(12)

則式(9)和式(10)分別修正為：

Δ′=(1-T′baseRTT/T′RTT)×C′t

(13)

(14)

由于修正后的T′baseRTT和T′RTT都同步增加TΔRTT，且通常T′baseRTT比T′RTT要小，由式(9)和式(13)可得在C′t=Ct時Δ′<Δ。再由式(10)和式(14)可知，Δ′比Δ更傾向于處在小于α的階段(擁塞窗口增長階段)，因此在維持確認分組反饋頻率的同時，通過修正TbaseRTT可進一步促進擁塞窗口的增長，進而可以達到提升正向鏈路吞吐量的目的。

2 仿真分析

為了分析和驗證TCP Vegas-RCC模型在正反向鏈路帶寬高度不對稱的地球空間傳感器網絡中的性能，采用OPNET作為仿真試驗軟件分別對TCP Reno、TCP Vegas和TCP Vegas-RCC進行仿真。網絡拓撲結構如圖3所示。

圖3 仿真網絡拓撲圖

設置結點路由器A和路由器B之間的鏈路為瓶頸鏈路，其中正向瓶頸鏈路帶寬設為1.5 Mbps，為了分析不同正反向鏈路帶寬比和不同往返時延環(huán)境下的TCP Vegas-RCC性能，本試驗將反向瓶頸鏈路帶寬分別設為1.5 kbps、15 kbps、150 kbps、1.5 Mbps，數據發(fā)送端到數據接收端的往返時延分別設為600 ms、400 ms、200 ms、100 ms，數據分組大小為1000 Bytes，確認分組大小為50 Bytes，正向瓶頸鏈路緩存大小設置為6個數據分組的大小，仿真時長為20 min。

2.1 無誤碼環(huán)境下的仿真試驗

本試驗在誤碼率為0的環(huán)境下，分別以不同正反向鏈路帶寬比和不同往返時延的條件，進行了16組仿真試驗，得到TCP Reno、TCP Vegas和TCP Vegas-RCC三個協(xié)議的正向鏈路平均吞吐量數據如表1所示。

表1 正向鏈路平均吞吐量(bps)

表1 正向鏈路平均吞吐量(bps)(續(xù))

從表1可以得出以下結論：

1)正反向鏈路帶寬比越大時，TCP Vegas-RCC相比于其他兩個協(xié)議的性能越好。

2)當正反向鏈路帶寬比相對較大時，TCP Vegas-RCC性能下降的程度受往返時延增大的影響較??；而當正反向鏈路帶寬比相對較小時，隨著鏈路時延的增加，TCP Vegas-RCC與其他兩個協(xié)議都產生性能快速下降的現(xiàn)象。

3)在不同條件下，TCP Vegas-RCC的吞吐量均高于TCP Vegas。

4)在正反向鏈路帶寬比和往返時延都較小時，TCP Reno性能最好，TCP Vegas性能最差。

5)在正反向鏈路帶寬比相對較小且往返時延較大時，三種協(xié)議的性能接近。

從表1可以看出，在高帶寬比和長時延的網絡環(huán)境下，TCP Vegas-RCC協(xié)議的性能遠遠高于其他兩個協(xié)議。下面以正向瓶頸鏈路帶寬為1.5 Mbps，反向瓶頸鏈路帶寬為1.5 kbps，往返時延長度為600 ms，鏈路誤碼率為0的網絡環(huán)境下的仿真結果進行分析。

根據文獻[7]定義的標準帶寬比k，可知在當前的仿真環(huán)境下，其標準帶寬比k=(正向鏈路帶寬/反向鏈路帶寬)/(數據分組大小/確認分組大小)=(1.5 Mbps/1.5 kbps)/(1000 Bytes/50 Bytes)=50，即在正向鏈路每發(fā)送k=50個數據分組，反向鏈路就有1個對應的確認分組發(fā)送時，正向鏈路和反向鏈路同時處于飽和狀態(tài)。因此，在當前的仿真環(huán)境下，如果按傳統(tǒng)累積確認機制，即接收端以每收到2個數據分組就對應產生1個確認分組的頻率來發(fā)送確認分組，欲保證反向鏈路不先于正向鏈路發(fā)生擁塞，則正、反向鏈路帶寬比不應超過40:1，很顯然在當前仿真環(huán)境設置的正、反向鏈路帶寬比為1000:1的鏈路上傳輸數據時，會導致在反向瓶頸鏈路中出現(xiàn)大量確認分組排隊的現(xiàn)象，如果反向瓶頸鏈路緩存較小，則會導致確認分組的丟失。

為了更清楚地觀察和分析反向鏈路排隊時延對TCP Vegas-RCC性能的影響，將反向瓶頸鏈路的緩存設置一個較大的值(6個確認分組的大小)，用以緩存未及時轉發(fā)的確認分組，只讓反向鏈路產生確認分組的排隊現(xiàn)象，以避免由于反向瓶頸鏈路緩存不足所引起的確認分組丟失情況對仿真結果的影響。

2.1.1吞吐量情況

從圖4可以看出，在正向鏈路中TCP Vegas-RCC、TCP Vegas和TCP Reno的平均吞吐量分別約為50 kbps、25 kbps、16 kbps。TCP Vegas-RCC的平均吞吐量是原始TCP Vegas的2倍，且傳統(tǒng)的TCP Reno協(xié)議的平均吞吐量最低，僅為TCP Vegas-RCC平均吞吐量的三分之一左右。這說明在反向鏈路先于正向鏈路產生擁塞的情況下，相比只依賴于針對數據分組的擁塞控制機制的TCP Vegas和TCP Reno來說，具有延遲確認機制的TCP Vegas-RCC可以有效地緩解反向鏈路擁塞，進而避免了向正向鏈路中減少注入數據分組所導致的性能下降問題。

圖4 正向鏈路吞吐量圖

2.1.2正向瓶頸鏈路隊列情況

從圖5和圖6可以看出，數據分組在正向瓶頸鏈路的隊列長度(排隊時延)由大到小的協(xié)議依次是TCP Vegas-RCC、TCP Vegas和TCP Reno，且由于正向瓶頸鏈路緩沖區(qū)大小(6個數據分組大小)遠遠大于實際數據分組所形成的隊列大小，因此在三個協(xié)議填滿緩沖區(qū)前，吞吐量越大的協(xié)議必然會導致在正向瓶頸鏈路中形成的隊列長度越長，進而印證了TCP Vegas-RCC、TCP Vegas和TCP Reno三個協(xié)議吞吐量由高到低的現(xiàn)象。

圖5 正向瓶頸鏈路隊列長度圖

圖6 正向瓶頸鏈路排隊時延圖

2.1.3反向瓶頸鏈路隊列情況

反向瓶頸鏈路隊列長度變化如圖7所示，TCP Vegas-RCC的平均隊列長度主要在1～1.7個確認分組大小的區(qū)間波動，而TCP Vegas和TCP Reno協(xié)議的隊列長度則都穩(wěn)定在0.65個確認分組的大小。且由此導致三個協(xié)議的排隊時延變化如圖8所示，三者的平均排隊時延分別為0.4 s、0.34 s和0.34 s。可以看出，TCP Vegas-RCC相對其他兩個協(xié)議能夠在反向鏈路中維持一個較大的確認分組隊列，這就保證了其在反向鏈路發(fā)生擁塞時依然可以保持較高的確認頻率。

由于反向鏈路發(fā)生擁塞，TCP Vegas與TCP Reno都啟動了相應的擁塞控制機制，通過減少注入正向鏈路數據分組的數量來間接地降低所對應的反向鏈路中確認分組的數目，而兩者又都采用的是無主動調整確認頻率的累積確認機制，因此兩者的確認頻率在擁塞控制機制的作用下穩(wěn)定在某個固定頻率上，進而使得兩者在反向瓶頸鏈路中確認分組隊列長度穩(wěn)定不變。

圖7 反向瓶頸鏈路隊列長度圖

圖8 反向瓶頸鏈路排隊時延圖

而導致TCP Vegas-RCC在反向瓶頸鏈路中確認分組的隊列長度呈波動變化的原因是由于該模型中動態(tài)延遲確認機制的作用，即當反向鏈路中排隊的確認分組增加時，會導致確認分組的排隊時延增加，進而會促使TCP Vegas-RCC的確認分組發(fā)送的間隔時間也隨之增加，導致單位時間內注入反向鏈路中的確認分組數目減小，從而減小確認分組的排隊長度，而當確認分組隊列長度減小后，又會引起排隊時延的減少，反而促使TCP Vegas-RCC減少確認分組發(fā)送的時間間隔，最終使得反向鏈路確認分組隊列長度呈波動變化。

2.1.4確認分組發(fā)送時間間隔情況

從圖9可以看出，TCP Vegas-RCC在反向鏈路中確認分組發(fā)送的間隔時間始終低于TCP Vegas和TCP Reno。雖然TCP Vegas-RCC和TCP Vegas一樣在反向鏈路發(fā)生擁塞時，其擁塞控制機制的介入會導致注入反向鏈路的確認分組數目減少，但是由于TCP Vegas-RCC采用的動態(tài)延遲確認機制，可以通過減少確認分組發(fā)送的間隔時間，在反向瓶頸鏈路中維持一定數目的確認分組，保證了較高的確認反饋頻率，進而加快了正向鏈路中數據分組吞吐量在擁塞控制機制作用下的提升速率。此外，導致圖9中TCP Vegas和TCP Reno的確認分組間隔時間相近且都穩(wěn)定的主要原因是，兩者采用的確認機制都是沒有主動控制確認分組發(fā)送頻率的傳統(tǒng)累積確認機制。而TCP Vegas-RCC的確認分組隊列長度小幅度波動現(xiàn)象的主要原因是，該協(xié)議采用的動態(tài)延遲確認機制會根據隊列時延的變化，動態(tài)地調整確認分組的發(fā)送頻率，從而使得其確認分組的發(fā)送間隔時間呈波動變化，且由于此時反向瓶頸鏈路趨于飽和，因此確認分組的發(fā)送間隔的調整范圍較小。

圖9 確認分組發(fā)送時間間隔圖

圖10 TCP Vegas-RCC確認分組發(fā)送時間間隔圖

從圖10可以看出，TCP Vegas-RCC協(xié)議的確認分組發(fā)送間隔時間與反向瓶頸鏈路確認分組排隊時延呈現(xiàn)一種同步且相同的變化趨勢，這正是該協(xié)議的設計目的，即通過改變確認分組發(fā)送的時間間隔來控制反向瓶頸鏈路的擁塞程度。

結合圖6和圖8可以發(fā)現(xiàn)，TCP Vegas-RCC協(xié)議在反向瓶頸鏈路中確認分組的排隊時延遠大于在正向瓶頸鏈路中數據分組的排隊時延，這證明了在高帶寬比和長往返時延的地球空間傳感器網絡環(huán)境下，影響往返時延變化的主要因素是反向瓶頸鏈路中確認分組排隊時延的變化。因此，在此種網絡環(huán)境中，對依賴于往返時延實施擁塞控制的傳輸協(xié)議來說，解決好反向鏈路的擁塞問題對提升協(xié)議的性能有很大幫助。

2.2 誤碼環(huán)境下的仿真試驗

本試驗針對前述網絡環(huán)境，考察在10-1～10-6六種不同誤碼率(Bit error ratio,BER)下的三個協(xié)議的性能情況。得到TCP Reno、TCP Vegas和TCP Vegas-RCC三個協(xié)議的正向鏈路平均吞吐量數據如表2所示。

表2 誤碼環(huán)境下的正向鏈路平均吞吐量(bps)

從表2可以得出以下結論：

1)隨著誤碼率的增加，三個協(xié)議的吞吐量都產生下降。

2)TCP Vegas-RCC和TCP Vegas比TCP Reno更能適應誤碼率高的網絡環(huán)境，且TCP Vegas-RCC適應性更強。

當由誤碼引起的丟包現(xiàn)象發(fā)生在反向鏈路時，確認分組到達數據發(fā)送端的頻率必然降低，TCP Reno會因為確認頻率的降低延緩擁塞控制窗口增長的速度，甚至是導致?lián)砣翱诘臏p小；而對于依賴往返時延變化的TCP Vegas只要能收集滿足往返時延計算所需的確認分組，即可進行擁塞窗口的調整；TCP Vegas-RCC與TCP Vegas一樣對確認分組的丟失不敏感，而其性能高于TCP Vegas的原因是由其較高的確認頻率導致。

3 結 論

本文提出了一種基于反向鏈路時延變化的擁塞控制模型TCP Vegas-RCC，能夠在正反向鏈路帶寬不對稱的地球空間傳感器網絡中，通過動態(tài)地調整確認分組發(fā)送的間隔時間，來維持一定的確認分組反饋頻率，解決了在反向鏈路發(fā)生擁塞時，由TCP Vegas擁塞控制機制介入所導致的正向鏈路數據分組吞吐量下降的問題。并通過OPNET仿真校驗了模型的有效性。