实验目的
学习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版本有了一个比较清晰的认识。
相关推荐
首先,TCP Reno和TCP Tahoe都是TCP拥塞控制算法的早期版本,主要目标是在网络出现拥塞时调整发送速率,避免数据包的丢失,从而提高网络性能。TCP Tahoe是最基础的拥塞控制算法,它采用慢启动、拥塞避免和快速重传/...
通过本实验,学习TCP的拥塞控制机制,并深入了解TCP Tahoe和TCP Reno两种不同版本的拥塞控制算法的工作原理及其差异。 #### 实验背景知识 **TCP拥塞控制策略** TCP(Transmission Control Protocol)作为Internet...
TCP Tahoe与Reno 运行机制对比分析以及ns2.35环境变量配置问题 实验代码
综上所述,Tahoe与Reno算法作为TCP拥塞控制的重要组成部分,不仅深刻影响了网络技术的发展,也为互联网服务的高效传输提供了坚实的理论基础和技术支持。随着网络环境的不断演变,未来对拥塞控制算法的研究和优化仍将...
自己总结整理的关于TCP拥塞控制的PPT,主要介绍并比较了Tahoe、Reno、NewReno与SACK四种算法,并对拥塞的产生进行了深入剖析
本文将对 TCP 的多个版本进行介绍和比较,包括 Tahoe、Reno、New Reno、SACK 和 Vegas 等版本的理解和特点。 Tahoe 是最早的 TCP 版本,它包括了三个最基本的拥塞控制算法:“慢启动”、“拥塞避免”和“快速重传”...
NS-2下的TCP和TCP Reno模块分析 3.3 NS-2下的TCP Reno模块分析 根据前面的分析,TCP Veno是在TCP Reno上做了一些修改的。在NS-2上,也沿用了TCP Reno的一些算法。因此,对Reno进行分析是很有必要的。 我们知道,...
TCP_Reno是在TCP Tahoe的基础上发展起来的,其主要目标是解决快速重传和快速恢复的问题,以提高网络效率和数据传输的可靠性。TCP_Reno引入了SACK(选择确认)选项,允许接收方告诉发送方哪些段已经被正确接收,从而...
NS2 学习笔记(10)——各种TCP版本、TCP同步化现象及影响因素 ...(2)探讨TCP Vegas和Reno系列的TCP版本在网络上共同运行所遭遇的问题 (3)探讨TCP同步化现象出现的原因 (4)了解几个常见的影响TCP执行效果的因素
3. **NS-2中的TCP模型**:详细解析NS-2支持的TCP实现,如TCP Reno、TCP Tahoe、TCP Vegas等,以及如何在NS-2中选择和配置这些模型。 4. **TCP模拟案例**:提供实际的模拟场景,比如不同网络条件下的TCP性能比较,...
- **TCPReno**:改进了Tahoe算法,引入了快速恢复机制,提高了拥塞窗口恢复的速度。 - **TCPNew-Reno**:进一步改进了Reno算法,解决了某些情况下恢复过慢的问题。 - **TCPSACK**:选择性确认机制,允许接收方告诉...
本题涉及到TCP拥塞控制的两个算法:TCP Reno和TCP Tahoe,以及它们在不同情况下的行为。 TCP Reno和TCP Tahoe都是在TCP/IP协议栈中实现的拥塞控制策略,但它们在处理拥塞和重传时有所不同。TCP Reno引入了快速恢复...
在TCP Tahoe和TCP Reno这两种常见的版本中,当出现丢包时,它们会采取不同的策略来降低发送速率。TCP Tahoe采用慢启动算法(Slow Start)和拥塞避免算法(Congestion Avoidance),而TCP Reno则增加了快速重传和快速...
It only covers TCP modification till Tahoe and Reno but chapter 24 gives you a more or less good idea about what the future will be like (in which we actually are, by the timeline of this book.)
在NS2中,我们可以设置不同的TCP选项,比如TCP Tahoe、NewReno或SACK,然后模拟各种网络条件下的TCP连接,如拥塞控制、数据重传等。 4. **UDP (User Datagram Protocol)**:UDP是另一种传输层协议,它比TCP更轻量级...
应用 6 要求: ns-3.20 图形 怎么跑? 将 application6.cc 复制到 /home/.../ns-allinone-3.20/ns-3.20/scratch 将 ass4.sh 复制到 /...此结果目录包含绘图和其他有用数据。 随意发现错误,打开问题并使用代码。