Client和Server之间的逻辑关系如图4中所示。Profile定义了业务，包含有业务开始时间、偏置时间、持续时间、操作模式等，同时也定义了与Application的关系。Application定义了各种应用，Server为Application定义的应用提供支持，也就是Client向Profile请求业务，Profile找到这个业务相应的应用，然后找到Server以支持该应用，从而使Client和Server建立关系。
4.2.2 业务配置
    定义的业务规格如图5所示，我们定义的与Application的关系是FTP_Application，偏置时间是根据所要传输的文件大小而定的。
 图5  定义业务规格
定义的应用如图6所示，这里我们定义应用个数为1个，对应用的描述定义为FTP，FTP定义的两个重要参数为文件大小和请求时间间隔。
 图6  定义应用
4.2.3 TCP参数配置
    我们通过利用OPNET仿真工具，针对各种拥塞控制算法配置不同的参数。在建立模型后，需要配置服务器和客户端的TCP参数[14]，如图7所示。
Maximum Segment Size表示一个数据包的大小。Receive Buffer表示接收缓冲区大小。Slow-Start Initial count是表示在进入慢启动阶段时设置初始拥塞窗口大小值，1表示一个数据包，2表示两个，依次类推，在这里我们设初始值为1。Fast Retransmit是快速重传，Fast Recovery是快速恢复，Selective ACK选择性重传，Enabled表示有效，Disabled表示无效，要想实现不同版本的算法就得改变上述的参数。
  图7  TCP参数配置
TCP参数配置的关键参数如表1所示，从表中我们可以明显的看出在执行TCP拥塞控制四种不同版本时的快速重传和快速恢复以及选择性确认三种参数的不同设置。
表1  TCP关键参数设置
参数设置    TCP Tahoe    TCP Reno    TCP New Reno    SACK
Fast Retransmit    Enabled    Enabled    Enabled    Disabled
Fast Recovery    Disabled    Reno    New Reno    Disabled
Selective ACK    Disabled    Disabled    Disabled    Enabled    
4.2.4 仿真结果分析
    在本文中我们主要关注的是不同版本的TCP在拥塞控制方面的性能，所以我们主要收集FTP服务器端的拥塞窗口大小。用OPNET仿真器仿真了这几种算法，将结果显示在同一张图上，由此可以清楚的看出它们之间的区别。为了方便比较，所有算法都是在相同外部条件下仿真的，数据设定在同一时刻丢失一个数据包。                    
图8  存在丢包网络中各版本TCP的拥塞窗口变化
 
图9  存在丢包网络中各版本TCP的拥塞窗口局部放大图
Tahoe算法，它采用了快速重传算法，遇到丢包的时候，TCP发送方启动快速重传算法，根据收到的重复ACK的数目来决定是否重传报文段，默认的是收到连续3个重复的ACK来通告报文段丢失事件。此时，定时器可能没有超时，所以与通过定时器超时来通告报文丢失的方式相比，它可以更加快速的发现丢包事件。Reno算法，在Tahoe的基础上增加了快速恢复算法。发生拥塞时，我们不必要将拥塞窗口减为一个数据包。比较Tahoe算法和Reno算法，发现Reno算法丢失数据时，将cwnd设置成当前窗口的一半加3个SMSS，重设ssthresh为当前发送窗口的一半，然后进入拥塞控制阶段。每次收到重复的ACK时，扩充cwnd为一个SMSS。当快速恢复结束后，将cwnd设置为ssthresh。New Reno算法，是在Reno基础上改进的，提高了Reno的执行效率。New Reno版的快速恢复可以进行部分确认的处理，因此较Reno版它在快速恢复阶段持续的时间会更长，在局部放大图9中可以看出，New Reno的拥塞窗口在发生拥塞之后的一段很长的时间(111.5s~114.5s)内都是增长的。SACK算法，SACK自动启动快速重传和快速恢复两个算法，并且因为使用了选择性确认和重传，SACK的重传更具目的性和明确性，所以在一个窗口内，它可以很快的完成本次发送窗口内丢失报文段的重传工作，从图中可以看出，SACK每次结束重传过程比New Reno更快。 基于OPNET的TCP协议研究与仿真(9):http://www.751com.cn/tongxin/lunwen_1272.html