TCP拥塞控制算法仿真实验设计

滕艳平， 杜 鹃， 谷文成， 廉佐政， 孙晓滨

(1. 齐齐哈尔大学 计算机与控制工程学院， 黑龙江 齐齐哈尔 161006；2. 齐齐哈尔大学 网络信息中心， 黑龙江 齐齐哈尔 161006)

计算机网络是一门理论与应用结合紧密的课程，涉及很多协议和算法。传输控制协议(Transmission Control Protocol，TCP)又是网络体系结构中一个非常重要的协议，它能提供可靠的端到端通信服务。研究表明，目前Internet中有95%数据包使用TCP协议进行传输[1]，并且TCP协议又能进行流量控制和拥塞控制。TCP拥塞控制算法对于确保网络的鲁棒性、稳定性和动态性具有十分重要的作用[2-3]。验证拥塞控制算法的有效性和进行相关性能的测试，目前常用的网络仿真工具有OPNET和NS2等。本文给出在NS2仿真环境下，针对各种版本的TCP设计一组仿真实验项目，并对其性能进行对比分析。在计算机网络的实验教学中，利用NS2仿真可以让学生更直观理解网络协议的工作原理，对影响网络性能因素进行分析和验证，增强学生实践动手能力，提高网络实验课程的教学质量。

1 NS2技术简介

NS2(network Simulator version 2)是一种面向对象、离散事件驱动的网络模拟器，并能运行在多种操作系统的环境中。NS2存在一套内建的类库，可以方便搭建网络实验模型，构建网络实验教学环境，实现多种协议的仿真。

利用NS2进行网络仿真可分为两个过程，一个是利用自带的网络元素，编写Otcl仿真脚本，无需对NS进行扩展；二是需要扩展网络元素，添加新的类和编写新的脚本[4]。NS2仿真过程见图1所示。

图1 NS2仿真过程示意图

NS2仿真过程可分为模型创建、模拟实现和仿真结果分析[5]。第一步构造一个虚拟的网络测试环境，包括各节点间建立的连接、节点之上各级代理以及各条线路传输的参数设置等；第二步根据实际要求对路由协议进行初始化、节点代理和记录运行情况，编写Otcl脚本；第三步进行结果的追踪。当NS2仿真结束后，对产生的一个或多个跟踪文件，可以通过调用相应的观察器，例如Nam、Gnuplot对文件进行分析及处理。其中Nam是可视化工具，将整个仿真过程以动画的方式展现出来，而Gnuplo是绘图工具，可将拥塞窗口变化情况和端到端吞吐量等性能参数以图形的方式展现出来。

2 TCP拥塞控制算法研究

2.1 TCP拥塞控制的基本方法

目前在Internet上，为了避免突发性的网络数据所导致的网络拥塞和报文丢失，TCP中设置了拥塞窗口(cwnd)机制，其拥塞控制的基本方法有慢启动(Slow Start)、拥塞避免(Congestion Avoidance)、快重传(Fast Retransmit)和快恢复(Fast Recovery)。

慢启动算法用于探测网络的可用带宽，其拥塞窗口以指数方式增加。拥塞避免算法试图避免网络拥塞的发生，并尽可能探测可用带宽，使用AIMD(additive increase multiplicative decrease)机制来改变拥塞窗口的大小。快重传和快恢复算法就是在发送端收到3个重复确认(Duplication ACK)时，就判定数据包已丢失，并重传缓存中的数据包，同时将拥塞窗口的门限(ssthresh)设置为当前cwnd的1/2，而不必等到重传计时器(RTO)超时。

下面是TCP拥塞控制的算法几个主要步骤：

/Initialization/

win=min(cwnd, rwnd); /发送端窗口上限取接收窗口和拥塞窗口最小值

cwnd=1;

ssthresh=65535(bytes); /当新确认包ACK到达时

if(cwnd

/Slow Start /

cwnd=cwnd+ 1; /拥塞窗口按指数方式增加

else

/Congestion Avoidance /

cwnd=cwnd+ 1 /cwnd ; /拥塞窗口按线性方式增加

对于慢启动和拥塞避免两个阶段，当重传计时器超时，则分别执行下列算法：

if(timeout)

{ssthresh=cwnd /2;

cwnd=1;}

同样，在慢启动和拥塞避免两个阶段，如果发送端收到3个重复的确认ACK，则分别执行下列的快重传和快恢复算法：

/Fastretransmit and Fast recovery /

if(three duplication ACK)

{ssthresh=cwnd /2;

cwnd=ssthresh;}

2.2 各种版本的TCP拥塞控制算法概述

2.2.1 TCP Tahoe

TCP最早的版本称之为Tahoe，Tahoe具备TCP的基本结构，包括慢启动、拥塞避免和快重传3种基本方法。假定发送端收到3个重复确认(Duplicate ACK)，即不等重传计算器超时(RTO)，发送端就立即重传缓存中已发送的数据包，并将ssthresh的值设为cwnd的1/2，之后将cwnd的值重置为1。

2.2.2 TCP Reno

TCP Reno是目前最广泛使用的TCP版本[6]，对Tahoe算法进行了修改，并加入快恢复功能。在使用快重传后，重发丢失的数据包，会将ssthresh和cwnd的值都设为检测到数据包丢失时拥塞窗口的1/2，并进入快恢复阶段。当发送端收到重传数据包ACK就会直接进入拥塞避免阶段。Tahoe针对一个数据包丢失情况，其性能较佳，但对多个数据包的丢失，会引起窗口的振荡，进而引发较大延时。

2.2.3 TCP New Reno

TCP New Reno是Reno的修改版，在一个发送窗口丢失多个数据包的情况下，对Reno中的快重传和快恢复方法进行了改进，使得快恢复阶段利用部分应答(Partical ACK)来触发重传，只有当全部的丢包都被重传确认后才退出快恢复阶段。New Reno大约每一个RTT时间可重传一个丢失的数据包，如若允许，在快恢复阶段，发送端还可继续发送新的数据包，以增加链路的使用效率。

2.2.4 TCP Sack

Sack是TCP Reno的另一个衍生版本，在此版本中，加入一个Sack选项，对来自数据窗口中的多个数据包，TCP一般采用累计确认的机制。当接收端缓存队列中出现序号不连续的数据时，允许接收端在返回的重复确认中，将已收到的数据区段返回给发送端，这样，发送端就会有选择地重传丢失数据包，并在一个RTT时间内重传一个以上的数据包，提高了TCP性能。

2.2.5 TCP Vegas

TCP Vegas是利用RTT来测量网络状况的拥塞控制算法[7-8]，通过观察RTT值的变化情况来决定是否增加或减少cwnd的值。如果RTT变大，Vegas就认为网络发生了拥塞，开始减小cwnd；如果RTT变少，Vegas就认为网络拥塞已经解除，再次增加cwnd。这样，在理想情况下cwnd就会稳定在一个合适值上。该算法的最大好处在于拥塞控制机制的触发只与RTT的改变有关。

3 TCP拥塞控制算法的仿真与实现

3.1 影响TCP性能因素及仿真效果

3.1.1 往返时间(RTT)对TCP性能的影响

本实验采用NS2.35进行仿真[9]，网络拓扑结构如图2所示。

图2 RTT仿真拓扑结构图

根据图2拓扑，建立两条TCP连接，第一条存在于S0到D0之间(FTP0)，第二条存在于S1到D1之间(FTP1)，由于FTP0的往返时间较短，仿真时间设定为40 s。

Reno版本FTP0和FTP1的cwnd变化情况如图3所示。

图3 Reno版本FTP0和FTP1的cwnd变化情况

从图中可以看出，FTP0的往返时间较短，所以在慢启动期间，FTP0以较快的速度增加cwnd的窗口值。由于确认包的往返时间也较短，在带宽满载之前，FTP0有较多的时间利用慢启动增加其窗口大小。同样，在重新进入拥塞避免后，FTP0仍然以较快的速度发送数据，这是因为FTP0的慢启动门限值比FTP1大，使得FTP0的速度明显比FTP1快并且总是有较好的执行效果。

图4为不同版本算法的FTP0和FTP1的cwnd变化情况。左上为Tahoe算法，右上为New Reno算法，左下为Sack算法，右下为Vegas算法。

表1和图5反映了5种算法的吞吐量变化情况。

FTP0的平均吞吐量明显高于FTP1，这由于FTP0的RTT较短。因此，在有线的因特网中，当发生拥塞时，距拥塞处较近的发送端能得到快速反应，并及时进行拥塞控制，表现出良好性能。但对RTT的设置不能太短，这样就可以避免在同一时间所有TCP将cwnd减半的情况发生，使缓存队列长度能稳定在较高值上。

图4 不同版本算法FTP0和FTP1的cwnd变化情况

表1 不同TCP版本的FTP0和FTP1的吞吐量比

3.1.2 重传计时器超时(RTO)对TCP性能的影响

本实验使用NS2.35进行仿真，网络拓扑结构图如图6所示。

图5 不同TCP算法的吞吐量运行情况

图6 RTO仿真拓扑结构图

在该实验中，分成2个小组进行，其中一组的FTP0和FTP1的tcptick的值(RTO)都设为0.5 s，另一组则分别设为0.5 s(FTP0)以及0.1 s(FTP1)。表2为吞吐量对比分析,图7为不同算法的仿真实验结果。

表2 各种TCP版本的吞吐量比较(计时器长度不同)

图7 各种TCP算法在不同计时器长度下的运行情况

在该实验中，在慢启动时由于TCP的连接都是以指数方式增加，网络的缓冲区很快就会被用完，这将导致大量数据包的丢失。从表2中可以看到，超时对Reno的影响很大，将超时计时器的值设置小些(观察case2的第二行，设为0.1 s)，由于FTP1恢复的时间较短，所以Reno的平均吞吐量明显变好(由原来657.2 kbit/s变为697.8 kbit/s)。虽然类似的情形也发生在TCP New Reno中，但由于New Reno在超时发生之前利用快恢复机制重新发送数据包，所以差异并不明显。Tahoe只要收到重复确认，就开始慢启动并重传数据包，故吞吐量没有变化(观察case1的第二行和case2的第二行)；Vegas 和Sack则是因为没有发生超时，而在本实验中都得到相同的运行结果。

3.2 4种典型版本的TCP拥塞控制算法实验设计

采用NS2.35进行实验，仿真网络拓扑图如图8所示。

图8 网络仿真实验拓扑图

其中FTP源节点到路由器R0的带宽为10 Mbit/s，延迟为1 ms。路由器R0到R1的带宽为1 Mbit/s，延迟为4 ms。路由器R1到FTP Sink的带宽为10 Mbit/s，延迟为1 ms。路由器队列管理使用DropTail[10-12]。假设有大量数据通过R0经过R1发送到固定节点FTP sink。其仿真时间设定为10 s。

将不同版本的TCP的拥塞窗口和吞吐量进行对比分析。通过对追踪文件分析来观察拥塞窗口的变化，得到不同TCP版本的执行效果，并使用gnuplot来实现可视化过程。4种拥塞控制算法的cwnd变化情况如图9所示。从图9中可以看出，Tahoe的拥塞窗口变化情况，即在拥塞窗口为20时启动了拥塞避免机制，线性增加窗口大小，当Tahoe发现了网络数据包丢失时，就立刻将cwnd的大小调整为初始值1，重新进入慢启动阶段。

图9 不同版本TCP算法的cwnd变化情况对比

与Tahoe算法相比，Reno算法检测到数据包丢失时，会将cwnd的大小设定为发生拥塞时的窗口的一半(本实验所得cwnd值为10)，然后运行拥塞避免算法。由于不需要再次进行慢启动，所以得到的平均吞吐量要比Tahoe算法好，见表3。

为了进一步比较Reno和New Reno的运行效果，将图8中R0与R1之间的缓存设得小一些(例如15个数据包)，在仿真实验中，若发送20个以上的数据包就会产生丢包现象。针对上述情况，Reno在收到Partical ACK(比如，序号为33的确认)，就会离开Fast Recovery阶段。由于Reno没有足够的重复确认来触发快重传，因此当超时(timeout)后就进入慢启动阶段。但New Reno在收到Partical ACK(比如，ack=33,35,37等)，仍维持在Fast Recovery阶段，直到所有丢失的数据包都被重传为止。由于在重传时不需要等待RTO超时，因此New Reno的吞吐量明显比Reno高。但New Reno也有瞬间快发新的数据包情况，可通过Maxburst参数设置来改进。

在Sack算法中，发送端可明确知道哪些数据包已经被接收端收到，并能针对丢失的数据包尽快重传(例如，本实验中的32号数据包)，缩短重传时间，减少触发timeout的机会，提高了网络的吞吐量，见表3。

表3 不同TCP版本平均吞吐量的对比

通过在NS2脚本中添加吞吐量的计算公式，计算代码如下：

puts[format″average throughput:%.1f Kbps″ [expr [$tcp set ack_]*([$tcp set packetSize_])*8/1000.0/10]]

$ns flush-trace

吞吐量的结果如图10所示。

图10 4种版本TCP算法的吞吐量运行情况

不同版本的TCP拥塞控制算法吞吐量对比见表3所示。

由表3和图10可以看出：TCP Tahoe因为没有快恢复机制而性能最差；TCP New Reno和TCP Sack是基于TCP Reno的改进方案，在丢包率较高的情况下，它们的吞吐量具有一定改善，明显高于TCP Reno；而TCP Sack又优于TCP New Reno，因为TCP Sack的发送端有较好的快恢复特性，增加网络的稳定性和鲁棒性。

4 结语

本文对影响TCP性能参数RTT和RTO设置问题进行了探讨，给出各种拥塞控制算法的仿真实验对比。结果表明，RTT设置较短，其cwnd就越大，平均端到端吞吐量就越高，并能及时进行拥塞控制。当RTO设置相对较小时，即由原来的0.5 s变为0.1 s ，TCP Reno算法表现出良好的性能，由于该算法的快恢复的时间较短，因此它的吞吐量明显增大，而其他算法的吞吐量不变或增加不够明显。对典型的4种TCP拥塞控制算法运行效果进行仿真分析，TCP Tahoe和TCP Reno是基于窗口机制，存在一定的局限性，只能解决一个数据包丢失的恢复问题。但在丢包率较高的情况下，TCP New Reno和TCP Sack的吞吐量明显高于TCP Reno。而TCP Sack又优于TCP New Reno，具有较好的网络特性。