一种适用于地球空间传感器网络的TCP Vegas模型

0 引 言

地球空间传感器网络[1-2]是将无线传感器网络(Wireless sensor network, WSN)与地理信息系统(Geographic information systems, GIS)，以及卫星遥感、全球卫星定位系统(Global positioning systems, GPS)等技术进行有效交叉与融合的网络，且在环境监测、灾害监测、远程医疗、智能交通、国防军事等许多领域都具有广阔的应用前景。然而空间网络相比于地面网络而言，其具有的往返时延长、误码率高和带宽不对称等特点，使得原本基于确认时钟的传输控制协议[3-4](Transmission Control Protocol Reno，TCP Reno)应用到空间网络时产生显著的性能下降。而在众多TCP协议的改进方案中，相比于TCP Reno具有更高且稳定的吞吐量以及更小分组丢失率[5]的TCP Vegas协议[6-7]已成为空间网络传输协议的研究热点。同时，TCP Vegas也因此被空间数据系统咨询委员会(Consultative Committee for Space Data Systems，CCSDS)所提出的空间通信协议规范传输协议[8-10](Space Communications Protocol Specification-Transport Protocol，SCPS-TP)指定为默认的拥塞控制算法。

TCP Vegas是一种基于时延进行带宽预测的传输协议。其拥塞控制的原理是，首先利用数据分组的发送时刻及其所对应确认分组(Acknowledgment，ACK)的到达时刻计算链路的往返时延(Round-trip time，RTT)，然后根据RTT和拥塞窗口(congestion window，cwnd)的大小计算链路的期望吞吐量和实际吞吐量，再根据期望吞吐量和实际吞吐量的差值来估计网络的实际状况，最后通过调整cwnd的大小来控制注入网络的数据分组数量，以避免出现传输链路中数据分组过多所导致的网络拥塞和数据分组过少所导致的网络吞吐量下降的现象，从而达到提升通信链路带宽利用率的目的。

文献[11]指出了在带宽不对称的链路中，反向链路会先于正向链路达到饱和而进入拥塞状态，导致确认分组延迟到达或丢失，进而误导依靠确认分组反馈信息的拥塞控制算法提前进入对数据分组的拥塞控制阶段，使得拥塞控制算法通过减少注入正向链路中数据分组的数量，间接地减少注入反向链路中确认分组的数目，从而达到缓解反向链路拥塞的目的。而在空间通信链路中，特别是具有正反向链路带宽高度不对称的卫星通信链路，当正向链路高速传递数据分组时，极易导致传输确认分组的反向链路发生拥塞。如果反向链路中还存在其他背景流量，这种由带宽不对称造成的拥塞现象会进一步加剧。由TCP Vegas原理可知，当反向链路发生拥塞时，确认分组会在反向瓶颈链路出现排队现象，进而导致反向链路传输时延增加，引起实测RTT的增大，误导TCP Vegas对正向链路实施拥塞控制，降低了协议的性能。文献[12]分析并指出了在长往返时延的空间通信链路中，正反向链路带宽的非对称性会进一步降低通过确认分组获取信道状态信息的协议的性能。

目前，针对TCP Vegas及基于时延进行拥塞控制的传输协议的改进方案[13-15]主要集中在提升时延测算精度和提高拥塞窗口调整效率的两个方面。较为典型的拥塞控制方案主要分为下述三类。

1)基于时延的拥塞控制改进方案

文献[16]针对卫星网络通信时延动态变化导致的拥塞控制问题，提出了一种基于链路长度的带宽估计算法。该算法通过卫星链路长度优化最小往返时延的计算，实现了慢启动阈值、拥塞窗口和超时重传定时器中相关参数增益因子的合理调整，有效地提升了卫星网络的吞吐量。文献[17-19]详细分析了TCP Vegas相对于TCP Reno在不对称链路中性能剧烈下降的原因，并基于时间戳计算数据分组在正向链路中的排队时延，再以此修正TCP Vegas算法中实际吞吐量的计算值，使其能够在一定程度上减少反向链路排队时延对TCP Vegas拥塞控制算法的影响。文献[20]提出了一种不修正原始TCP Vegas拥塞控制算法中关键参数的方法，而是依靠时间戳测算正向链路排队时延的变化量，并以此为正向链路发生拥塞的辅助判断条件，使其拥塞控制算法能够更加准确地控制正向链路的拥塞问题。

2)基于数据链路中间节点的拥塞控制改进方案

文献[21]在利用路由器进行正向链路和反向链路排队时延测量的基础上，提出了同时修正实际吞吐量和基础往返时延(baseRTT)的计算方法，进一步降低了反向链路的状态对拥塞控制算法的影响。文献[22-23]考虑反向链路确认分组数目对正向链路拥塞控制的影响，通过调整链路上中间转发节点的确认分组接收窗口大小来限制数据分组的发送速率，以达到提升拥塞控制效果的目的。文献[24]基于跨层反馈思想，提出了一种可以根据中间路由器的状态信息计算出丢包的可能性来提前预测拥塞的方法，从而提前避免拥塞的发生，保证了数据分组的传输速率，提高了网络的性能。

3)基于负载均衡的拥塞控制改进方案

文献[25]针对卫星链路，在详细分析了跳到跳确认方式与端到端确认方式不同的基础上，提出了一种结合负载因子的跳到跳确认机制的传输协议框架，有效消除了无线链路造成的传输错误的影响，提高了通信链路的利用率。文献[26]在TCP Vegas的基础上提出了一种基于分组排队时延的多路拥塞控制改进算法wVegas，该改进算法将单条通信链路的拥塞控制问题转换成多条通信链路的负载均衡问题，使得注入某条拥塞链路的数据分组可以分流到其他通信链路上，从而达到提升总体通信链路带宽利用率的目的。

综上，针对由链路带宽非对称性引起的反向链路拥塞问题的解决方案并不多，虽然上述改进方案在一定程度上考虑了反向链路状态对正向链路拥塞控制的影响，但依然没有针对反向链路中确认分组的拥塞控制问题进行直接而有效地控制，导致在反向链路发生拥塞时，只能依靠正向链路拥塞控制方法以降低数据分组吞吐量为代价的方式对反向链路实施间接的拥塞控制，进而限制了TCP Vegas协议的性能。

因此，本文从与TCP Vegas配合的确认机制入手，提出了一种具有主动反向链路拥塞控制能力的端到端TCP Vegas拥塞控制模型，从而解决了反向链路先于正向链路发生拥塞时正向链路吞吐量降低的问题，提升了TCP Vegas协议的整体性能。

1 TCP Vegas改进模型TCP Vegas-RCC

本文提出的TCP Vegas-RCC拥塞控制模型，采用基于反向链路排队时延的延迟确认机制主动控制注入反向链路中的确认分组数目，并辅以修正后的TCP Vegas拥塞控制算法间接地加强对反向链路拥塞的控制效果，进而解决反向链路先于正向链路发生拥塞时正向链路吞吐量下降的问题。

该改进模型的主要修改内容为在原始TCP Vegas协议的基础上，调整确认分组发送间隔时间来控制注入反向链路中确认分组的数目，使确认分组在反向链路中保持适当的排队，以维持一个较高确认频率，同时利用相邻确认分组的发送间隔时间修正原始TCP Vegas中baseRTT的计算值，降低确认分组提前和滞后发送对RTT测算的影响。

1.1 TCP Vegas-RCC模型结构

该模型由控制确认分组发送频率的延迟确认机制和完成正向链路拥塞控制的TCP Vegas修正算法组成，如图1所示。

图1 TCP Vegas-RCC模型图

Fig.1 Structure of TCP Vegas-RCC module

其中，延迟确认机制主要由位于数据发送端的确认延迟时间计算模块、位于数据接收端的延迟时钟设置模块和相邻确认分组实际发送间隔时间计算模块三个部分组成。

该模型在初始阶段，接收端的确认延迟时钟(最大的确认分组延迟发送的间隔时间)为两个相邻确认分组发送的间隔时间。其初始值为0 s，即接收端收到一个未被确认的数据分组后立即发送其对应的确认分组，等效于没有延迟。

其具体一轮的确认分组发送频率调整过程为：发送端向接收端发送数据分组。接收端从接收到数据分组的首部中提取其所携带的确认延迟间隔时间(初始值为0 s)，并以此设置确认延迟时钟；同时，根据所收到数据分组的状态决定是否采用此间隔时间发送其对应的确认分组；在发送确认分组时，将当前确认分组与其前一个确认分组发送时的实际间隔时间写入该确认分组的首部。发送端收到该确认分组后，在利用修正后的TCP Vegas拥塞控制算法进行间接的反向链路拥塞控制的同时，根据确认分组中所携带的实际发送间隔时间计算该确认分组在反向链路传输过程中的排队时延，并以此作为评估反向链路确认频率的依据，计算下一轮确认分组应该延迟发送的间隔时间；最后，将所计算的确认间隔时间写入到下一个待发送的数据分组首部。当此数据分组到达接收端后，即开启下一轮的调整过程。

1.2 延迟确认策略

本模型中采用的动态延迟确认机制在基于传统累积确认机制[27]的基础上，引入了基于确认间隔时间的确认分组延迟发送方法，以维持反向链路中的确认频率。文献[28]指出采用延迟确认的方法会由于发送端接收到确认分组比预期的要慢或少，导致基于确认时钟的传统TCP Reno协议将会出现下述三个问题。

1)突发性数据分组流量的问题

假设接收端发送的n个确认分组，由于反向链路拥塞而产生丢包或被延迟发送，最后只有1个确认分组按时到达发送端，而原来靠依次接收n个确认分组并逐渐将拥塞窗口增加n个数据分组大小的“缓慢”过程，变成了接收端只收到1个(唯一的)确认分组就将拥塞窗口一次性且大幅度地增长n个数据分组大小的“突发”过程，导致拥塞窗口突然增大，增加了数据分组丢失的风险。n值越大，数据分组丢失的概率越大，特别是在慢启动阶段，过快增长的拥塞窗口会导致短时间内向正向链路注入大量的数据分组，从而进一步加剧了正向链路中数据分组丢失的风险。

由于TCP Vegas协议不是基于确认时钟的协议，其拥塞控制依据的是吞吐量的变化情况而不是确认分组到达发送端的频率。即使TCP Vegas对确认分组到达发送端的频率的变化不敏感，但吞吐量的计算还是要依赖于确认分组的到达。因此，TCP Vegas在慢启动阶段采用延迟确认机制时依然会产生突发性数据分组流量的问题。而本文提出的TCP Vegas-RCC，判断处于慢启动阶段和拥塞避免阶段的方式虽然与原始TCP Vegas相同，但是其延迟确认机制开启条件与原始TCP Vegas进入拥塞避免阶段的条件(期望吞吐量与实际吞吐量的差值大于预先设定的阈值γ)相同，即延迟确认机制只在TCP Vegas-RCC进入拥塞避免阶段后启动，而在慢启动阶段并不开启，从而避免了在慢启动阶段中突发性数据分组流量问题的产生。

2)拥塞窗口增长缓慢的问题

由于传统的TCP Reno是依靠收到确认分组的个数而不是确认分组能够确认的数据总量来调整拥塞窗口的，因此确认分组成功到达发送端的数量减少必然会降低拥塞窗口增长的速度。

而本模型采用的延迟确认机制，不仅能解决问题1，还能解决问题2。这是因为在拥塞窗口增长缓慢时，延迟确认机制可以根据确认分组在反向链路排队时延的变小程度，缩短确认分组的发送间隔时间，提高确认频率，进而加快拥塞窗口增长。

3)快速重传机制失效的问题

传统的TCP Reno协议在收到3个重复的确认分组后就立即开始快速重传机制[29]。由于确认分组的延迟到达，在发送端计时器超时前可能接收不到足够数量(3个)的重复确认分组，进而导致发送端无法在数据分组丢失时进入快速重传阶段，因此对丢失的数据分组重传只能发生在重传计时器超时之后，这样一来就降低了协议的性能。

文献[6-7]指出TCP Vegas改进了TCP Reno的重传机制，即当TCP Vegas收到1个重复的确认分组时不用等到收到3个重复的确认分组，就可以利用其携带的时间戳计算传输的时间间隔，并与事先设定的快速重传超时门限值比较来判断是否进行快速重传。而在有多个数据分组丢失时，也能在第一个丢失的数据分组成功重传后，根据之后第一个或第二个到来的确认分组(非重复确认)携带的时间戳以同样的方式来决定是否进行快速重传。虽然原始TCP Vegas从提出之时就已解决了快速重传依赖于收到指定重复确认分组数目的问题，但如果拥塞窗口较小、或发送端由于超时而进入慢启动、或长达多余一个往返时延的时间内发送端没有数据分组发送的三种情况中任何一个出现时，则由于数据分组到达接收端的频率过低，同样也有可能导致发送端因没有收到足够数目的确认分组而无法进行快速重传，导致协议性能下降的现象产生。因此，在数据接收端须设置一个确认分组超时时钟，以保证确认分组在数据发送端超时前到达。本文将确认分组的超时时钟设为1.2倍的往返时延。

1.3 相邻确认分组发送间隔时间的计算

为了在反向链路中维持一个较高的确认频率，则须在反向链路中保持一定长度的确认分组队列。因此，相邻确认分组发送的间隔时间应该与确认分组的排队时延相关。如果以相对于前一个确认分组发送时的间隔时间T发送下一个确认分组，能够使得这个确认分组在反向链路中的排队时延T′减少(或增加)，即可达到维持反向链路中确认分组排队规模的目的。在正反向链路带宽高度不对称的空间通信环境中，当反向链路先于正向链路发生拥塞时，不考虑误码造成分组丢失的情况下，导致往返时延变化的主要因素是反向链路中确认分组排队时延的变化和确认分组发送间隔时间的变化(由于此时正向链路没有发生拥塞，因此正向链路数据分组排队时延忽略不计)，即往返时延的变化量满足

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

(1)

式中：TΔRTT为往返时延的变化量，ΔT为确认分组发送间隔时间的变化量，ΔT′为反向链路中确认分组排队时延的变化量，ΔT ″为正向链路中数据分组排队时延的变化量(反向链路拥塞时，该值趋近于0)。

若是在正向链路先于反向链路产生拥塞的网络环境中，ΔT′可以忽略不计，反而ΔT ″作为链路的主要时延。无论哪个方向的链路发生拥塞，TCP Vegas-RCC中针对正向链路拥塞控制的算法都会启动。但当反向链路发生拥塞时，延迟确认机制会降低确认频率，主动地减少向反向链路中注入确认分组的数量，从而缓解反向链路的拥塞问题；而当反向链路中排队的确认分组数目过少时，延迟确认机制又会主动地提高确认频率，促进拥塞窗口的快速增长，以提高正向链路的吞吐量。

由于测得最小往返时延TbaseRTT时，正向链路和反向链路均没有排队产生，即正向链路时延排队时延和反向链路排队时延都为0。因此由式(1)可得

(2)

式中：TRTTi为本轮测得的往返时延，Ti为本轮确认分组发送的间隔时间，T′i为本轮反向链路中确认分组排队时延(初值为0)。

本文假设在反向链路发生拥塞时，确认分组发送的间隔时间变化量与确认分组在反向链路中的排队时延变化量相当，即ΔT=ΔT′。因此，下一轮确认分组发送的间隔时间满足

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

(3)

式中：Ti+1为下一轮确认分组发送的间隔时间，T′i-1为上一轮反向链路中确认分组排队时延。

为了维持较高的确认频率，反向链路应该维持一定的确认分组的队列规模。因此，当反向链路的拥塞程度加剧时，须逐渐地减少注入反向链路的确认分组数量，即适当地增加确认分组发送的时间间隔；而当反向链路从拥塞状态恢复时，应该快速地提升反向链路的确认频率，即大幅度地减少确认分组发送的时间间隔。因此计算新一轮确认分组发送时间间隔算法如图2所示。

图2 计算确认分组发送时间间隔算法流程图

Fig.2 Flow chart of computing interval time between ACKs algorithm

1)确认分组发送的间隔时间下限的确定

为了避免反向链路中确认分组队列过长，确认分组发送的间隔时间应避免过短，须设置确认延迟的最小间隔时间(即为间隔时间的下限)应不小于TCP Reno协议以正常频率发送确认分组的间隔时间ΔT。

设Δt为实际两个相邻到达发送端的确认分组的间隔时间。

设A为所允许的正常两个相邻到达发送端的确认分组所确认数据量的差额(单位为字节)。为了达到与TCP Reno协议所采用的累积确认机制的相同效果，该值取2个最大分组长度，即每接收两个数据分组就对应发送一个确认分组。

设Δa为实际两个相邻到达发送端的确认分组所确认数据量的差额(单位为字节)。则当后一确认分组到达后，发送端发送的数据和拥塞窗口的调整幅度应该相当于收到Δa/A-1个确认分组时的效果，即Δa/Δt=A/ΔT。其中，·为向上取整函数，减1表示去掉1个已经到达的前一个确认分组。

则确认分组发送的最小间隔时间Tmin的计算式如下所示：

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

(4)

2)确认分组发送的间隔时间上限的确定

为了保证TCP Vegas-RCC调整拥塞窗口时有足够的反馈信息，则必须保证数据发送端在拥塞窗口调整周期(2个RTT)内成功接收到2个确认分组，因此确认分组发送的间隔时间不应超过1个RTT的时间TRTT，则确认分组发送的最大隔时间Tmax的计算式如下所示：

Tmax=TRTT

(5)

最终，新一轮确认分组发送的间隔时间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为发送端观测到的当前链路的最小往返时延；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模型在反向链路中采用延迟确认机制，确认分组的延迟发送影响了往返时延的测算，因此需要分别对原始协议中TRTT和TbaseRTT进行修正，设两者对应的修正量分别为T′RTT和T′baseRTT，对应修正后的拥塞窗口大小为C′t。

由于确认分组不是在收到对应的数据分组时立即发送，因此测算的链路最小往返时延时应该包含确认分组延迟发送的时间，该延迟时间近似等于相邻确认分组发送的间隔时间ΔT，即当前T′baseRTTi等于之前的T′baseRTTi-1与ΔTi的和：

(11)

由于在数据分组发送初期，反向链路没有确认分组的排队现象，因此TbaseRTT的初始测算值无需修正。

同时，由于测算TRTT时，已经包含了确认分组延迟发送的时间，因此不对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 仿真网络拓扑图

Fig.3 Illustration of simulation network topology

设置结点路由器A和路由器B之间的链路为瓶颈链路，其中正向瓶颈链路带宽设为1.5 Mbps，为了分析不同正反向链路带宽比和不同往返时延环境下的TCP Vegas-RCC性能，本试验将反向瓶颈链路带宽分别设为1.5 kbps、15 kbps、150 kbps、1.5 Mbps，数据发送端到数据接收端的往返时延分别设为600 ms、400 ms、200 ms、100 ms，数据分组大小为1000 Bytes，确认分组大小为50 Bytes，正向瓶颈链路缓存大小设置为6个数据分组的大小，仿真时长为20 min。

2.1 无误码环境下的仿真试验

本试验在误码率为0的环境下，分别以不同正反向链路带宽比和不同往返时延的条件，进行了16组仿真试验，得到TCP Reno、TCP Vegas和TCP Vegas-RCC三个协议的正向链路平均吞吐量数据如表1所示。

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

Table 1 Average throughput of forward link (bps)

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

Table 1 Average throughput of forward link (bps)(continued)

从表1可以得出以下结论：

1)正反向链路带宽比越大时，TCP Vegas-RCC相比于其他两个协议的性能越好。

2)当正反向链路带宽比相对较大时，TCP Vegas-RCC性能下降的程度受往返时延增大的影响较小；而当正反向链路带宽比相对较小时，随着链路时延的增加，TCP Vegas-RCC与其他两个协议都产生性能快速下降的现象。

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

4)在正反向链路带宽比和往返时延都较小时，TCP Reno性能最好，TCP Vegas性能最差。

5)在正反向链路带宽比相对较小且往返时延较大时，三种协议的性能接近。

从表1可以看出，在高带宽比和长时延的网络环境下，TCP Vegas-RCC协议的性能远远高于其他两个协议。下面以正向瓶颈链路带宽为1.5 Mbps，反向瓶颈链路带宽为1.5 kbps，往返时延长度为600 ms，链路误码率为0的网络环境下的仿真结果进行分析。

根据文献[7]定义的标准带宽比k，可知在当前的仿真环境下，其标准带宽比k=(正向链路带宽/反向链路带宽)/(数据分组大小/确认分组大小)=(1.5 Mbps/1.5 kbps)/(1000 Bytes/50 Bytes)=50，即在正向链路每发送k=50个数据分组，反向链路就有1个对应的确认分组发送时，正向链路和反向链路同时处于饱和状态。因此，在当前的仿真环境下，如果按传统累积确认机制，即接收端以每收到2个数据分组就对应产生1个确认分组的频率来发送确认分组，欲保证反向链路不先于正向链路发生拥塞，则正、反向链路带宽比不应超过40:1，很显然在当前仿真环境设置的正、反向链路带宽比为1000:1的链路上传输数据时，会导致在反向瓶颈链路中出现大量确认分组排队的现象，如果反向瓶颈链路缓存较小，则会导致确认分组的丢失。

为了更清楚地观察和分析反向链路排队时延对TCP Vegas-RCC性能的影响，将反向瓶颈链路的缓存设置一个较大的值(6个确认分组的大小)，用以缓存未及时转发的确认分组，只让反向链路产生确认分组的排队现象，以避免由于反向瓶颈链路缓存不足所引起的确认分组丢失情况对仿真结果的影响。

2.1.1 吞吐量情况

从图4可以看出，在正向链路中TCP Vegas-RCC、TCP Vegas和TCP Reno的平均吞吐量分别约为50 kbps、25 kbps、16 kbps。TCP Vegas-RCC的平均吞吐量是原始TCP Vegas的2倍，且传统的TCP Reno协议的平均吞吐量最低，仅为TCP Vegas-RCC平均吞吐量的三分之一左右。这说明在反向链路先于正向链路产生拥塞的情况下，相比只依赖于针对数据分组的拥塞控制机制的TCP Vegas和TCP Reno来说，具有延迟确认机制的TCP Vegas-RCC可以有效地缓解反向链路拥塞，进而避免了向正向链路中减少注入数据分组所导致的性能下降问题。

图4 正向链路吞吐量图

Fig.4 Illustration of forward link throughput

2.1.2 正向瓶颈链路队列情况

从图5和图6可以看出，数据分组在正向瓶颈链路的队列长度(排队时延)由大到小的协议依次是TCP Vegas-RCC、TCP Vegas和TCP Reno，且由于正向瓶颈链路缓冲区大小(6个数据分组大小)远远大于实际数据分组所形成的队列大小，因此在三个协议填满缓冲区前，吞吐量越大的协议必然会导致在正向瓶颈链路中形成的队列长度越长，进而印证了TCP Vegas-RCC、TCP Vegas和TCP Reno三个协议吞吐量由高到低的现象。

图5 正向瓶颈链路队列长度图

Fig.5 Illustration of forward bottleneck link queue size

图6 正向瓶颈链路排队时延图

Fig.6 Illustration of forward bottleneck link queuing delay

2.1.3 反向瓶颈链路队列情况

反向瓶颈链路队列长度变化如图7所示，TCP Vegas-RCC的平均队列长度主要在1～1.7个确认分组大小的区间波动，而TCP Vegas和TCP Reno协议的队列长度则都稳定在0.65个确认分组的大小。且由此导致三个协议的排队时延变化如图8所示，三者的平均排队时延分别为0.4 s、0.34 s和0.34 s。可以看出，TCP Vegas-RCC相对其他两个协议能够在反向链路中维持一个较大的确认分组队列，这就保证了其在反向链路发生拥塞时依然可以保持较高的确认频率。

由于反向链路发生拥塞，TCP Vegas与TCP Reno都启动了相应的拥塞控制机制，通过减少注入正向链路数据分组的数量来间接地降低所对应的反向链路中确认分组的数目，而两者又都采用的是无主动调整确认频率的累积确认机制，因此两者的确认频率在拥塞控制机制的作用下稳定在某个固定频率上，进而使得两者在反向瓶颈链路中确认分组队列长度稳定不变。

图7 反向瓶颈链路队列长度图

Fig.7 Illustration of reverse bottleneck link queue size

图8 反向瓶颈链路排队时延图

Fig.8 Illustration of reverse bottleneck link queuing delay

而导致TCP Vegas-RCC在反向瓶颈链路中确认分组的队列长度呈波动变化的原因是由于该模型中动态延迟确认机制的作用，即当反向链路中排队的确认分组增加时，会导致确认分组的排队时延增加，进而会促使TCP Vegas-RCC的确认分组发送的间隔时间也随之增加，导致单位时间内注入反向链路中的确认分组数目减小，从而减小确认分组的排队长度，而当确认分组队列长度减小后，又会引起排队时延的减少，反而促使TCP Vegas-RCC减少确认分组发送的时间间隔，最终使得反向链路确认分组队列长度呈波动变化。

2.1.4 确认分组发送时间间隔情况

从图9可以看出，TCP Vegas-RCC在反向链路中确认分组发送的间隔时间始终低于TCP Vegas和TCP Reno。虽然TCP Vegas-RCC和TCP Vegas一样在反向链路发生拥塞时，其拥塞控制机制的介入会导致注入反向链路的确认分组数目减少，但是由于TCP Vegas-RCC采用的动态延迟确认机制，可以通过减少确认分组发送的间隔时间，在反向瓶颈链路中维持一定数目的确认分组，保证了较高的确认反馈频率，进而加快了正向链路中数据分组吞吐量在拥塞控制机制作用下的提升速率。此外，导致图9中TCP Vegas和TCP Reno的确认分组间隔时间相近且都稳定的主要原因是，两者采用的确认机制都是没有主动控制确认分组发送频率的传统累积确认机制。而TCP Vegas-RCC的确认分组队列长度小幅度波动现象的主要原因是，该协议采用的动态延迟确认机制会根据队列时延的变化，动态地调整确认分组的发送频率，从而使得其确认分组的发送间隔时间呈波动变化，且由于此时反向瓶颈链路趋于饱和，因此确认分组的发送间隔的调整范围较小。

图9 确认分组发送时间间隔图

Fig.9 Illustration of interval time between ACKs

图10 TCP Vegas-RCC确认分组发送时间间隔图

Fig.10 Illustration of interval time between ACKs of TCP Vegas-RCC

从图10可以看出，TCP Vegas-RCC协议的确认分组发送间隔时间与反向瓶颈链路确认分组排队时延呈现一种同步且相同的变化趋势，这正是该协议的设计目的，即通过改变确认分组发送的时间间隔来控制反向瓶颈链路的拥塞程度。

结合图6和图8可以发现，TCP Vegas-RCC协议在反向瓶颈链路中确认分组的排队时延远大于在正向瓶颈链路中数据分组的排队时延，这证明了在高带宽比和长往返时延的地球空间传感器网络环境下，影响往返时延变化的主要因素是反向瓶颈链路中确认分组排队时延的变化。因此，在此种网络环境中，对依赖于往返时延实施拥塞控制的传输协议来说，解决好反向链路的拥塞问题对提升协议的性能有很大帮助。

2.2 误码环境下的仿真试验

本试验针对前述网络环境，考察在10-1～10-6六种不同误码率(Bit error ratio,BER)下的三个协议的性能情况。得到TCP Reno、TCP Vegas和TCP Vegas-RCC三个协议的正向链路平均吞吐量数据如表2所示。

表2 误码环境下的正向链路平均吞吐量(bps)

Table 2 Average of forward link throughput with BER (bps)

从表2可以得出以下结论：

1)随着误码率的增加，三个协议的吞吐量都产生下降。

2)TCP Vegas-RCC和TCP Vegas比TCP Reno更能适应误码率高的网络环境，且TCP Vegas-RCC适应性更强。

当由误码引起的丢包现象发生在反向链路时，确认分组到达数据发送端的频率必然降低，TCP Reno会因为确认频率的降低延缓拥塞控制窗口增长的速度，甚至是导致拥塞窗口的减小；而对于依赖往返时延变化的TCP Vegas只要能收集满足往返时延计算所需的确认分组，即可进行拥塞窗口的调整；TCP Vegas-RCC与TCP Vegas一样对确认分组的丢失不敏感，而其性能高于TCP Vegas的原因是由其较高的确认频率导致。

3 结 论

本文提出了一种基于反向链路时延变化的拥塞控制模型TCP Vegas-RCC，能够在正反向链路带宽不对称的地球空间传感器网络中，通过动态地调整确认分组发送的间隔时间，来维持一定的确认分组反馈频率，解决了在反向链路发生拥塞时，由TCP Vegas拥塞控制机制介入所导致的正向链路数据分组吞吐量下降的问题。并通过OPNET仿真校验了模型的有效性。