美文网首页
TCP Tahoe 与 Reno 运行机制对比分析

TCP Tahoe 与 Reno 运行机制对比分析

作者: 就算过了一载春秋 | 来源:发表于2020-04-20 21:26 被阅读0次

    一、实验目的

    学习 TCP 的拥塞控制机制并了解 TCP Tahoe 和 TCP Reno 协议的运行机制

    二、实验内容

    观测 tahoe 和 reno 协议的特征

    观察 Tahoe 版本的 congestion window 的变化情况

    观察 Reno 版本的 congestion window 的变化情况

    三、实验步骤

    环境:ubuntu16.04

    1、安装NS2

    1.1 更新系统

    sudo apt-get update    #更新源列表
    sudo apt-get upgrade   #更新已安装的包
    

    1.2 安装NS2运行时需要的三个依赖包

    sudo apt-get install build-essential
    sudo apt-get install tcl8.5 tcl8.5-dev tk8.5 tk8.5-dev
    sudo apt-get install libxmu-dev libxmu-headers
    

    1.3 下载安装包并编译安装(ns 2.35)

    NS-2下载地址:https://sourceforge.net/projects/nsnam/files/(先下载再解压)

    tar xvfz ns-allinone-2.35.tar.gz    #解压压缩包 
    cd ns-allinone-2.35         #定位到所在文件夹
    

    修改ls文件,位置是:ns-2.35/linkstate/ls.h第137行:

    void eraseAll() { erase(baseMap::begin(), baseMap::end()); }
    

    改为:

    void eraseAll() { this->erase(baseMap::begin(), baseMap::end()); }
    

    然后执行

    ./install
    

    等待安装成功

    1.4 配置环境变量

    打开.bashrc文件

    gedit  ~/.bashrc     # ~ 这个符号为当前用户根目录,即/home/用户名
    

    直接在文档的最后面加上以下环境变量

    export NS_HOME=/home/用户名/ns-allinone-2.35  #这里填自己的安装路径
    export PATH=$PATH:$NS_HOME/bin:$NS_HOME/tcl8.5.10/unix:$NS_HOME/tk8.5.10/unix
    export LD_LIBRARY_PATH=$NS_HOME/otcl-1.14:$NS_HOME/lib  
    export TCL_LIBRARY=$NS_HOME/tcl8.5.10/library   
    

    1.5 验证ns2是否成功安装

    关闭终端,重启终端,输入ns,出现%,说明ns2安装成功

    1.6 测试ns并验证nam是否安装成功

    倘若弹出动画演示框,则证明ns完全安装正确


    2、Tahoe和Reno算法的测试

    安装绘图软件gunplot

    sudo apt-get install gnuplot-x11
    

    安装好后输入gnuplot可启动gnuplot

    实验网络拓扑结构 和 链路参数配置 (FTP代表端施加恒定的流CBR):

    本实验tcl程序:

    if { $argc!=1 } {
        puts"Usage:ns lab11.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.0/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
    

    2.1 观察Tahoe版本的congestion window的变化情况

    输入如下指令即可得到使用Tahoe版本下拥塞窗口的变化情况:

    得到文件Tahoe.trcwnd-Tahoe.tr

    然后利用gnuplot绘图:

    得到gif图片swnd-Tahoe.gif:

    在 TCP 的 Tahoe 版本中,Congestion Windows 值会呈现周期性的重复变化。刚开始采用 Slow-Start 开始,cwnd 呈指数方式增长,当 cwnd 超过 Ssthresh 时 就进入了 Congestion Avoidance 阶段。由于网络上的数据包不断增加,超过路由器的转发 能力时,排队缓冲队列出现了溢出,路由器开始使用 Drop-tail 将数据包丢掉。当数据包丢失后,Tahoe 版本 TCP 将 ssthresh 设为出现数据包丢失时的 Windows 值的 1/2,并将 cwnd 值重设为 1,并重新开始执行 Slow-Start 算法。

    2.2 观察 Reno 版本的 congestion window 的变化情况

    输入如下指令即可得到使用Reno版本下拥塞窗口的变化情况:

    得到文件Reno.trcwnd-Reno.tr

    然后利用gnuplot绘图:

    得到gif图片swnd-Reno.gif:

    在 TCP 的 Reno 版本中,开始阶段与 Tahoe 的表现一样。当网络上的数据包不断增加,超过路由器的转发能力时,排队缓冲队列出现了溢出,路由器开始使 用 Drop-tail 将数据包后,Reno 版本 TCP 将 ssthresh 和 cwnd 都设为出现数据包丢失时的Windows 值的 1/2,并开始执行 Congestion Avoidance 算法。

    3、题目

    3.1 A

    这个实验中只对 cwnd 的测量,没有对 ACK 帧的测量,能够能体现出“快重传”(不 管在 Tahoe 还是在 Reno 中都有快重传这一特性的)这一特性吗?

    答:

    在Tahoe中,不能体现快速重传这一特性,因为发送端在收到重复的ACK和发生超时都是采用慢启动策略,现象是一样的,所以不能体现;

    在Reno中,能体现快速重传这一特性,可以看到图中的情况都是收到DupACK后然后快速重传的例子,因为发送端在收到重复的ACK后采用快速重传,而发生超时是采用慢启动策略,所以能体现。

    3.2 B

    为什么 Reno 版本在出现封包丢失后选择将 ssthresh 和 cwnd 都设为出现数据包丢失 时的 Windows 值的 1/2,而不是其它值呢?比如 1/3,2/3?

    答:

    四、实验中遇到的问题

    1、在更新源列表时,键入

    sudo apt-get update
    

    后,出现了下图所示的错误:

    通过查找相关资料,找到解决方法:

    sudo rm /var/lib/apt/lists/lock
    

    2、然后在更新源列表时,速度真的非常感人,于是通过修改/etc/apt/sources.list,换成了清华大学的源,下载速度简直飞的起。(可参考https://blog.csdn.net/zl10086111/article/details/82917462

    3、安装gnuplot时提示无法定位软件包,

    再执行一次

    sudo apt-get update
    

    再次安装就行了

    五、实验心得

    通过这次实验,我对TCP Tahoe和TCP Reno协议的运行机制有了更深刻的了解。

    从以上分析可以看出 Tahoe 版本的 TCP 在每次出现封包丢失的时候都重新开始执行 Slow-Start 算法,这样使得网络的吞吐率并不高。但经过改进后的 Reno 版本出现封包丢失 的时候,并不是把当前 cwnd 设为 1,而是设为出现封包丢失时的 1/2,所以 Reno 版本的 TCP 的平均吞吐率较 Tahoe 更高,这一点可以从实验结果得证。

    参考链接:
    https://blog.csdn.net/circle2015/article/details/52490582
    https://blog.csdn.net/yyd19981117/article/details/89331937
    https://blog.csdn.net/qq_40323844/article/details/89329686

    相关文章

      网友评论

          本文标题:TCP Tahoe 与 Reno 运行机制对比分析

          本文链接:https://www.haomeiwen.com/subject/skrsihtx.html