实验目的
学习TCP的拥塞控制机制，并了解TCP Tahoe 和 TCP Reno的运行方式。
基础知识回顾
TCP/IP （Transmission Control Protocol/Internet Protocol）是目前使用最广泛的一组通信协议。TCP所负责的功能包括：将自应用程序收到的信息分成许多较小的数据区段、提供连接导向的服务、提供可靠性服务、提供应用程序与应用和式之间的流量控制，并依据网络的状况提供拥塞控制。
当应用程序有数据要传送到网上去时，为了希望能和网络上其他的TCP联机公平地共享频宽等资源并避免造成网络拥塞，TCP通过拥塞控制机制来控制允许传送到网络上的数据量。也就是说，TCP的拥塞控制机制直接影响到TCP的传输效率。按照拥塞控制方法的不同，现行使用的TCP分为几个版本：Tahoe，Reno，NewReno，Vegas，SACK 等。在开始试验之前，我们先简单说明拥塞控制的基本方法，接着介绍各种TCP的版本，并比较之间的异同。
【TCP 拥塞控制简介】
TCP（Transmission Control Protocol）是目前Internet上使用最普遍的第四层通信协议。随着网络的盛行，TCP的作用也日益凸显。然而，TCP仍然有很多问题尚未解决，因此许多有关TCP的研究也陆续提出，以增进TCP的效果。
TCP早期的版本定义在RFC 393 中，它提供可靠性传输服务，并具有流量控制和拥塞控制机制。TCP使用拥塞控制窗口（Congestion Window，简称cwnd）来控制允许被传送到网络上的数据报数量。TCP拥塞控制方法在RFC 2001及RFC 2581中已经标准化。在开始数据传送之前，TCP会先在传送端与接收端间建立一条网络联机，将要传送的信息分割成数个数据报，并按照封包编号通过网络层所提供的功能依次传送出去。当收到一个数据报时，TCP的接收端会返回一个ACK（Ackonwledgment，ACK）给传送端，以表示这个数据报已被收到。在整个传送过程中，TCP进行拥塞控制，以避免因为传送过快而造成网络拥塞。
【TCP拥塞控制的基本方法（Congestion Control Mechanisms of TCP）】
一般而言，TCP拥塞控制机制方法主要分为如下5个阶段：Slow-start，Congestion Avoidance、Fast Retransmission、Fast Recovery ，Timeout Retransmission。
TCP利用Ack检测网络状况并提供可靠性服务，在调整传送端的传送速度时，则以Slow-start threshold（简称ssthresh）与cwnd 的值来区分Slow-start或Congestion-avoidance。如下式所示：
Slow-start/Congestion Avoidance
如上式所示：当cwnd的值小于ssthresh时，TCP处于slow-start阶段。在这个阶段，每收到一个ACK，window的值便会加1，因此每经过一个RTT时间，window的值便会变成上个RTT时window值的2倍。也就是说，在这个阶段，cwnd的值会以指数（2的倍数）的方式增加。当cwnd的值大于ssthresh，TCP进入拥塞避免（Congestion Avoidance）阶段。在这个阶段，cwnd的值以线性方式增长。大约每经过一个RTT，cwnd的值就会增加一个segment，以避免cwnd的值增加太快而发生数据报遗失。如果检测到封包遗失或超时（timeout），则TCP的传送端会将ssthresh值设为发生拥塞时的window值的一半，重设cwnd的值，接着使用Slow-start重传（重新传送）遗失的数据报。
Acknowledgment机制
TCP的传送端利用ACK来确认数据报是否被接收端收到。当一个封包达到接收端时，接收端会根据收到的数据报号返回一个ACK（Acknowledge），表示这个数据报已经收到，并触发传送端再送出新的数据报，这个机制称为“self-clocking”。若收到非连续的数据报时，则返回号码相同的ACK，称为重复的ACK（duplicate ACK）。TCP使用ACK及重传的方法提供可靠性的传输服务。
【TCP Tahoe】
TCP最早的版本称之为Tahoe。TCP Tahoe 主要有三个机制去控制数据流和拥塞窗口: slow start (SS), congestion avoidance (CA), and fast retransmit(FS)。SS机制:当connection 建立时，把congestion window 的大小初始化，并设为一个MSS(maximum segment size)，同时把ssthresh (slow start threshold)设为 64 KB。CA 机制: 为了在发生拥塞的情形下控制流量TCP Tahoe 使用Additive Increase Multiplicative Decrease (AIMD)机制。AIMD:只要有一个packet loss就认为网络发生拥塞，Tahoe会把ssthrsh 设为目前的congestion window 的一半。并且回到SS的状态，之后congestion window 继续以指数成长；当到达ssthresh 时congestion window 会以线性成长来避免拥塞。FS 机制:当收到三个重复的ack 时，不必等到Retransmit Timeout(RTO)，会认为包丢失，并且马上重传。
【TCP Reno】
TCP Reno 是目前使用最广泛的TCP版本。 除了包含了Tahoe的三个机制(SS,CA,FS)，Reno 多了另外一个机制: 快速恢复Fast Recovery(FR)；FR机制:当收到三个重复的ack 或是超过了RTO 且尚未收到某个数据报的ack，Reno 会认为有数据报遗失了，并且认定网络发生拥塞。Reno 会把ssthresh 设为目前congestion window的一半，但并不会回到SS的状态，而是设定congestion window 为ssthresh，之后congestion window 则维持线性成长。以图1为说明，在round 8 的时候发生了封包遗失，因此Reno 把ssthresh 设为目前congestion window 的一半亦即是6，Reno 的congestion window 并且从6 开始线性成长(图1 黑线部分)。
图1 TCP Tahoe 与 TCP Reno 机制
实验步骤
【实验1：观察TCP Tahoe Congestion Window 的变化】
1. 仿真实验的网络结构图（图2）
图2 仿真实验的网络结构图
如图2所示，这是一个由两个路由器组成的简单结构图，其中n0和n1表示结点，r0和r1表示网络上的路由器。FTP Source 通过r0 连接网络，并且假设有大量数据连续地传送给FTP Sink。路由器的队列管理机制使用DropTail，频宽为1Mbps，传递延迟时间为4ms。在这个例子中，我们只建立1条TCP数据流。因为cwnd的值直接反应TCP的传输效果，所以我们选择以cwnd作为观察测量的参数。
2. TCL程序代码（假设我将此代码保存于/home/ns下的tcpversion.tcl中）
if { $argc !=1 } {
puts "Usage:ns tcpversion.tcl tcpversion"
exit
}
set par1 [lindex $argv 0]
set ns [new Simulator]
#打开一个trace文件，用来记录数据报传送的过程
set nd [open $par1.tr w]
$ns trace-all $nd
#打开一个文件用来记录cwnd变化情况
set f0 [open cwnd-$par1.tr w]
#定义一个结束的程序
proc finish {} {
global ns nd f0 tcp
puts [format "average throughput:%.1f Kbps" \ [expr [$tcp set ack_]*([$tcp set packetSize_])*8/1000/10]]
$ns flush-trace
close $nd
close $f0
exit 0
}
#定义一个记录的程序
proc record {} {
global ns tcp f0
set now [$ns now]
puts $f0 "$now [$tcp set cwnd_]"
$ns at [expr $now+0.01] "record"
}
#产生传送结点，路由器r1和r2和接收结点
set n0 [$ns node]
set r0 [$ns node]
set r1 [$ns node]
set n1 [$ns node]
#建立链路
$ns duplex-link $n0 $r0 20Mb 1ms DropTail
$ns duplex-link $r0 $r1 1Mb 4ms DropTail
$ns duplex-link $r1 $n1 20Mb 1ms DropTail
#设置队列长度为18个封包大小
set queue 18
$ns queue-limit $r0 $r1 $queue
#根据用户的设置，指定TCP版本，并建立相应的Agent
if { $par1 == "Tahoe" } {
set tcp [new Agent/TCP]
set tcpsink [new Agent/TCPSink]
} elseif { $par1 == "Reno" } {
set tcp [new Agent/TCP/Reno]
set tcpsink [new Agent/TCPSink]
}
$ns attach-agent $n0 $tcp
$ns attach-agent $n1 $tcpsink
$ns connect $tcp $tcpsink
#建立FTP应用程序
set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ns at 0.0 "$ftp start"
$ns at 10.0 "$ftp stop"
#在0.0s时调用record来记录TCP的cwnd 变化情况
$ns at 0.0 "record"
$ns at 10.0 "finish"
$ns run
3. 执行方法
4. 结果分析
average throughput:948.0 Kbps
我们得到了平均吞吐率为：948.0Kbps
使用gnuplot观察cwnd的变化值。如图3所示。（gnuplot>是在gnuplot状态下的提示符）
[root@localhost ns]# gnuplot
gnuplot> set title "Tahoe"
gnuplot> set xlabel "time"
gnuplot> set ylabel "cwnd"
gnuplot> plot "cwnd-Tahoe.tr" with linespoints 1
可得到图3：
图3 Tahoe的cwnd变化图
从图3可以看到，TCP的Congestion Window 值会呈现周期性重复变化。TCP Tahoe 开始执行时，先由slow-start（SS）开始，cwnd超过ssthresh时进入拥塞避免（CA）阶段。由于传送到网络上的丢包不断增加，当超出允许能传送到网络上的个数时，路由器开始使用DropTail算法将数据报丢掉。当数据报遗失时，TCP Tahoe会将ssthresh设为发现数据报遗失时的一半，接着将Window的值设为1。Tahoe重新进入slow-start阶段。
【实验2：观察TCP Reno congestion window 的变化】
1. 执行方法
[root@localhost ns]# ns tcpversion.tcl Reno
2. 结果分析
average throughput:949.0 Kbps
我们发现TCP Reno的平均吞吐量比TCP Tahoe 的平均吞吐量大一些。同样，用gnuplot观察cwnd的变化情况。
[root@localhost ns]# gnuplot
gnuplot> set title "Reno"
gnuplot> set xlabel "time"
gnuplot> set ylabel "cwnd"
gnuplot> plot "cwnd-Reno.tr" with linespoints 1
可得到图4：
图4 Reno的cwnd变化图
如图4所示，当检测到数据报遗失时，ssthresh和cwnd的值会被设置为先前cwnd值的一半。因此重传遗失数据报后，TCP Reno 会由 Congestion Avoidanc（CA）开始。由于结束Fast recovery 后，TCP Reno中cwnd的值由先前cwnd值的1/2开始增加，所以得到的平均吞吐量比TCP Tahoe 大一些。
此外，当TCP的传送端观察到端点到端点的路径没有拥塞的情况下，会持续地以累加的方式增加传送速率。但是，当检测到路径拥塞情况发生时，则以倍数方式减少传送速率。基于上述原因，TCP的拥塞控制算法又常被称为累加递增—倍数递减的算法（Additive-Increase，Multiplicative-Decrease，AIMD）。
小结
在这个实验中，我们对TCP Tahoe 和 TCP Reno 进行了比较与分析，看到了它们两者的区别和联系。尤其是Reno在Tahoe基础上的改进。使大家对这两种TCP版本有了一个比较清晰的认识。
原文转自：http://blog.sina.com.cn/s/blog_5d2054d90100s9tn.html