TCP协议控制窗口算法实现
TCP协议作为?一个可靠的?面向流的传输协议，其可靠性和流量量控制由滑动窗?口协议保证，?而拥塞控制则由控制窗?口结合?一系列列的控制算法实现。?一、滑动窗?口协议关于这部分?自?己不不晓得怎么叙述才好，因为理理解的部分更更多，下?面就?用?自?己的理理解来介绍下TCP的精髓：滑动窗?口协议。所谓滑动窗?口协议，?自?己理理解有两点：1. “窗?口”对应的是?一段可以被发送者发送的字节序列列，其连续的范围称之为“窗?口”；2. “滑动”则是指这段“允许发送的范围”是可以随着发送的过程?而变化的，?方式就是按顺序“滑动”。在引?入?一个例例?子来说这个协议之前，我觉得很有必要先了了解以下前提： -1. TCP协议的两端分别为发送者A和接收者B，由于是全双?工协议，因此A和B应该分别维护着?一个独?立的发送缓冲区和接收缓冲区，由于对等性（A发B收和B发A收），我们以A发送B接收的情况作为例例?子； -2. 发送窗?口是发送缓存中的?一部分，是可以被TCP协议发送的那部分，其实应?用层需要发送的所有数据都被放进了了发送者的发送缓冲区； -3. 发送窗?口中相关的有四个概念：已发送并收到确认的数据（不不再发送窗?口和发送缓冲区之内）、已发送但未收到确认的数据（位于发送窗?口之中）、允许发送但尚未发送的数据以及发送窗?口外发送缓冲区内暂时不不允许发送的数据； -4. 每次成功发送数据之后，发送窗?口就会在发送缓冲区中按顺序移动，将新的数据包含到窗?口中准备发送；TCP建?立连接的初始，B会告诉A?自?己的接收窗?口?大?小，?比如为‘20’：字节31-50为发送窗?口
A发送11个字节后，发送窗?口位置不不变，B接收到了了乱序的数据分组：
只有当A成功发送了了数据，即发送的数据得到了了B的确认之后，才会移动滑动窗?口离开已发送的数据；同时B则确认连续的数据分组，对于乱序的分组则先接收下来，避免?网络重
复传递：
?二、流量量控制流量量控制?方?面主要有两个要点需要掌握。?一是TCP利利?用滑动窗?口实现流量量控制的机制；?二是如何考虑流量量控制中的传输效率。
1. 流量量控制所谓流量量控制，主要是接收?方传递信息给发送?方，使其不不要发送数
据太快，是?一种端到端的控制。主要的?方式就是返回的ACK中会包含?自?己的接收窗?口的?大?小，并且利利?用?大?小来控制发送?方的数据发送：
这?里里?面涉及到?一种情况，如果B已经告诉A?自?己的缓冲区已满，于是A停?止发送数据；等
待?一段时间后，B的缓冲区出现了了富余，于是给A发送报?文告诉A我的rwnd?大?小为400，但是这个报?文不不幸丢失了了，于是就出现A等待B的通知||B等待A发送数据的死锁状态。为了了
处理理这种问题，TCP引?入了了持续计时器?（Persistence timer），当A收到对?方的零窗
?口通知时，就启?用该计时器?，时间到则发送?一个1字节的探测报?文，对?方会在此时回应?自
身的接收窗?口?大?小，如果结果仍未0，则重设持续计时器?，继续等待。
2. 传递效率?一个显?而易易?见的问题是：单个发送字节单个确认，和窗?口有?一个空
余即通知发送?方发送?一个字节，?无疑增加了了?网络中的许多不不必要的报?文（请想想为了了?一个字节数据?而添加的40字节头部吧！），所以我们的原则是尽可能?一次多发送?几个字节，或者窗?口空余较多的时候通知发送?方?一次发送多个字节。对于前者我们?广泛使?用Nagle算法，即：1. 若发送应?用进程要把发送的数据逐个字节地送到TCP的发送缓存，则发送?方就把第?一个数据字节先发送出去，把后?面的字节先缓存起来；2. 当发送?方收到第?一个字节的确认后（也得到了了?网络情况和对?方的接收窗?口?大?小），再把缓冲区的剩余字节组成合适?大?小的报?文发送出去；3. 当到达的数据已达到发送窗?口?大?小的?一半或以达到报?文段的最?大?长度时，就?立即发送?一个报?文段；对于后者我们往往的做法是让接收?方等待?一段时间，或者接收?方获得?足够的空间容纳?一个报?文段或者等到接受缓存有?一半空闲的时候，再通知发送?方发送数据。
三、拥塞控制?网络中的链路路容量量和交换结点中的缓存和处理理机都有着?工作的极限，当?网络的需求超过它们的?工作极限时，就出现了了拥塞。拥塞控制就是防?止过多的数据注?入到?网络中，这样可以使?网络中的路路由器?或链路路不不致过载。常?用的?方法就是：
1. 慢开始、拥塞控制
2. 快重传、快恢复?一切的基础还是慢开始，这种?方法的思路路是这样的： -1. 发
送?方维持?一个叫做“拥塞窗?口”的变量量，该变量量和接收端?口共同决定了了发送者的发送窗?口； -2. 当主机开始发送数据时，避免?一下?子将?大量量字节注?入到?网络，造成或者增加拥塞，选择发送?一个1字节的试探报?文； -3. 当收到第?一个字节的数据的确认后，就发送2个字节的报?文； -4. 若再次收到2个字节的确认，则发送4个字节，依次递增2的指数级； -5. 最后会达到?一个提前预设的“慢开始?门限”，?比如24，即?一次发送了了24个分组，此时遵循下?面的条件判定：1. cwnd < ssthresh，继续使?用慢开始算法；2. cwnd > ssthresh，停?止使?用慢开始算法，改?用拥塞避免算法；3. cwnd = ssthresh，既可以使?用慢开始算法，也可以使?用拥塞避免算法； -6. 所谓拥塞避免算法就是：每经过?一个往返时间RTT就把发送?方的拥塞窗?口+1，即让拥塞窗?口缓慢地增?大，按照线性规律律增?长； -7. 当出现?网络拥塞，?比如丢包时，将慢开始?门限设为原先的?一半，然后将cwnd设为1，执?行行慢开始算法（较低的起点，指数级增?长）；
上述?方法的?目的是在拥塞发?生时循序减少主机发送到?网络中的分组数，使得发?生拥塞的路路由器?有?足够的时间把队列列中积压的分组处理理完毕。慢开始和拥塞控制算法常常作为?一个整体使?用，?而快重传和快恢复则是为了了减少因为拥塞导致的数据包丢失带来的重传时间，从?而避免传递?无?用的数据到?网络。快重传的机制是：
-1. 接收?方建?立这样的机制，如果?一个包丢失，则对后续的包继续发送针对该包的重传请求； -2. ?一旦发送?方接收到三个?一样的确认，就知道该包之后出现了了错误，?立刻重传该包； -3. 此时发送?方开始执?行行“快恢复”算法：1. 慢开始?门限减半；2. cwnd设为慢开始?门限减半后的数值；3. 执?行行拥塞避免算法（?高起点，线性增?长）；
课程设计报告滑动窗口协议仿真
课程设计报告滑动窗口 协议仿真 公司内部档案编码：[OPPTR-OPPT28-OPPTL98-OPPNN08]
滁州学院 课程设计报告课程名称：计算机网络 设计题目：滑动窗口协议仿真 系别：计算机与信息工程学院 专业：计算机科学与技术 组别：第五组 起止日期: 2011年11月24日~2011年12月7日 指导教师:赵国柱 计算机与信息工程学院二○一一年制
课程设计任务书 一. 引言 二. 基本原理 窗口机制 1bit滑动窗口协议
后退N协议 选择重传协议 流量控制 三. 需求分析 课程设计题目 开发环境 运行环境 课程设计任务及要求 界面要求 网络接口要求 四. 详细设计 结构体的定义 发送方的主要函数 接受方的主要函数 五. 源代码 发送方的主要代码 接收方的主要代码 六. 调试与操作说明 致谢 [参考文献] 课程设计的主要内容1.引言
早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道网络拥塞状况，一起发送数据，导致中间结点阻塞掉包，谁也发不了数据。在数据传输过程中，我们总是希望数据传输的更快一些，但如果发送方把数据发送的过快，接收方就可能来不及接收，这就造成数据的丢失。因此就有了滑动窗口机制来解决这些问题。早期我们使用的是1bit滑动窗口协议，一次只发送一个帧，等收到ack确认才发下一个帧，这样对信道的利用率太低了。因此提出了一种采用累积确认的连续ARQ协议，接收方不必对收到的帧逐个发送ack 确认，而是收到几个帧后，对按序到达的最后一个帧发送ack确认。同1bit滑动窗口协议相比，大大减少了ack数量，并消除了延迟ack对传输效率的影响。但是，这会产生一个新的问题，如果发送方发送了5个帧，而中间的第3个帧丢失了。这时接收方只能对前2个帧发出确认。发送方无法知道后面三个帧的下落，只好把后面的3个帧再重传一次，这就是回退N协议。为了解决这个问题，又提出了选择重传协议。当接收方发现某帧出错后，继续接受后面送来的正确的帧，只是不交付它们，存放在自己的缓冲区中，并且要求发送方重传出错的那一帧。一旦收到重传来的帧后，就可以将存于缓冲区中的其余帧一并按正确的顺序递交给主机。 2.基本原理 窗口机制
TCP协议中的流量控制和拥塞控制研究(毕业论文)
毕业设计(论文) TCP协议中的流量控制和拥塞控制研究 院别数学与统计学院 专业名称信息与计算科学 班级学号 学生姓名 指导教师 年月日
TCP协议中的流量控制和拥塞控制研究 摘要 计算机网络技术是当今发展最迅速的计算机技术之一，而保证网络稳定可靠运行的关键是计算机网络协议。TCP协议作为网络协议中的核心协议之一，其重要性更是不言而喻，因而对于该协议的研究与完善是促进网络发展的重要手段之一。 随着互联网规模和互联网应用的快速增长，网络拥塞和数据冲突问题已引起人们密切的关注。拥塞控制与流量控制技术针对网络中的拥塞和数据冲突而成为网络领域的核心技术。其中流量控制的对象是接收端，目的是使发送端的发送速率不超过接收端的接收能力；拥塞控制的对象是网络环境，目的是使负载不超过网络的传送能力。 TCP的流量控制主要依赖于滑动窗口，通过流量约束，减少接收端出的数据流失，提高发送效率，充分利用接收端资源。 TCP的拥塞控制主要原理依赖于一个拥塞窗口(cwnd)来控制，窗口值的大小就代表能够发送出去的但还没有收到ACK的最大数据报文段，显然窗口越大那么数据发送的速度也就越快，但是也就越可能使得网络出现拥塞，如果窗口值为1，那么就简化为一个停等协议，每发送一个数据，都要等到对方的确认才能发送第二个数据包，显然数据传输效率低下。TCP拥塞控制算法就是要在这两者之间权衡，选取最的cwnd值，从而使得网络吞吐量最大化且不产生拥塞。 本文首先对TCP协议的发展做了简要的概述，然后分析了TCP协议的报文段格式和结构，TCP的数据传输过程，接着讨论了TCP的流量控制机制，最后针对TCP 的重点部分拥塞控制进行了分析，讨论了几个TCP拥塞控制算法。 关键词：TCP协议，流量控制，拥塞控制
滑动窗口协议分析与实现
滑动窗口协议分析与实现 目录 1 引言 (2) 1.1 滑动窗口协议概述 (2) 1.2 本次设计任务 (2) 2 滑动窗口协议介绍 (3) 2.1 滑动窗口协议工作原理 (3)
1 引言 1.1 滑动窗口协议概述 滑动窗口协议可能是计算机网络中最著名的算法，它是TCP使用的一种流量控制方法。滑动窗口协议也称为回退N步协议Go-Back-N(GBN)协议，它可以有三个不同的功能，第一个功能，即在不可靠链路上可靠地传输帧。（一般来说，该算法被用于在一个不可靠的网络上可靠地传输消息。）这是该算法的核心功能。 滑动窗口算法的第二个功能是用于保持帧的传输顺序。这在接收方比较容易实现，因为每个帧有一个序号，接收方要保证已经向上层协议传递了所有序号比当前帧小的帧，才向上传送该当前帧。即，接收方缓存了（即没有传送）错序的帧。 滑动窗口算法的第三个功能是，它有时支持流量控制（flowcontrol），它是一种接收方能够控制发送方使其降低速度的反馈机制。这种机制用于抑制发送方发送速度过快，即抑制传输比接收方所能处理的更多的数据。 滑动窗口协议，允许发送方传输多个分组而不需等待确认，但它也受限于在流水账中未确认的分组数不能超过最大允许数N。只有在接收窗口向前滑动，即接收方向发送方发送了确认反馈，同时发送方收到确认消息时，发送窗口才能向前滑动。 1.2 本次设计任务 本次的设计任务是根据滑动窗口协议的工作原理，在WebRTC的基础上，用C++语言编写一个滑动窗口协议的程序。 要求该程序实现滑动窗口协议的基本功能功能，如：发送帧被接收与否的判断，帧超时重发，帧缓存等。同时需要设计一个测试机制，以检测该程序的正确性、可靠性。
课程设计报告-滑动窗口协议仿真
滁州学院 课程设计报告 课程名称：计算机网络 设计题目：滑动窗口协议仿真 系别：计算机与信息工程学院 专业：计算机科学与技术 组别：第五组 起止日期: 2011年11月24日~2011年12月7日指导教师:赵国柱 计算机与信息工程学院二○一一年制
课程设计任务书
一. 引言 二. 基本原理 2.1 窗口机制 2.2 1bit滑动窗口协议 2.3 后退N协议 2.4 选择重传协议 2.5 流量控制 三. 需求分析 3.1 课程设计题目 3.2 开发环境 3.3 运行环境 3.4 课程设计任务及要求 3.5 界面要求 3.6 网络接口要求 四. 详细设计 4.1 结构体的定义 4.2 发送方的主要函数 4.3 接受方的主要函数 五.源代码 5.1 发送方的主要代码 5.2 接收方的主要代码 六. 调试与操作说明 致谢 [参考文献] 课程设计的主要内容
1.引言 早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。由于大家 不知道网络拥塞状况，一起发送数据，导致中间结点阻塞掉包，谁也发不了数据。在 数据传输过程中，我们总是希望数据传输的更快一些，但如果发送方把数据发送的过快， 接收方就可能来不及接收，这就造成数据的丢失。因此就有了滑动窗口机制来解决这些 问题。早期我们使用的是1bit滑动窗口协议，一次只发送一个帧，等收到ack确认 才发下一个帧，这样对信道的利用率太低了。因此提出了一种采用累积确认的连续ARQ 协议，接收方不必对收到的帧逐个发送ack确认，而是收到几个帧后，对按序到达的最后一 个帧发送ack确认。同1bit滑动窗口协议相比，大大减少了ack数量，并消除了延迟ack 对传输效率的影响。但是，这会产生一个新的问题，如果发送方发送了5个帧，而中间的第 3个帧丢失了。这时接收方只能对前2个帧发出确认。发送方无法知道后面三个帧的下落， 只好把后面的3个帧再重传一次，这就是回退N协议。为了解决这个问题，又提出了选择重 传协议。当接收方发现某帧出错后，继续接受后面送来的正确的帧，只是不交付它们， 存放在自己的缓冲区中，并且要求发送方重传出错的那一帧。一旦收到重传来的帧后， 就可以将存于缓冲区中的其余帧一并按正确的顺序递交给主机。 2.基本原理 2.1 窗口机制 滑动窗口协议的基本原理就是在任意时刻，发送方都维持了一个连续的允许发送的帧的序号，称为发送窗口；同时，接收方也维持了一个连续的允许接收的帧的序号，称为接收窗口。发送窗口和接收窗口的序号的上下界不一定要一样，甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。发送方窗口内的序号代表了那些已经被发送，但是还没有被确认的帧，或者是那些可以被发送的帧。接受方为其窗口内的每一个序号保留了一个缓冲区。与每个缓冲区相关联的还有一位，用来指明该缓冲区是满的还是空的。 若从滑动窗口的观点来统一看待1比特滑动窗口、后退n及选择重传三种协议，它们的差别仅在于各自窗口尺寸的大小不同而已。1比特滑动窗口协议：发送窗口=1，接收窗口=1；后退N协议：发送窗口>1，接收窗口=1；选择重传协议：发送窗口>1,接收窗口>1。 2.2 1bit滑动窗口协议 当发送窗口和接收窗口的大小固定为1时，滑动窗口协议退化为停等协议（stop－and－wait）。该协议规定发送方每发送一帧后就要停下来，等待接收方已正确接收的确认（acknowledgement）返回后才能继续发送下一帧。由于接收方需要判断接收到的帧是新发的帧还是重新发送的帧，因此发送方要为每一个帧加一个序号。由于停等协议规定只有一帧完全发送成功后才能发送新的帧，因而只用一比特来编号就够了。其发送方和接收方运行的流程图如图所示。
TCP拥塞控制算法性能比较-Read
TCP拥塞控制算法性能比较 一、NS2仿真 1.仿真实验的网络结构图 如图所示0、1、2为源节点，3为路由器，4为目的节点。源节点0、1、2为TCP代理节点，频宽为8Mbps，传递延迟时间为0.1ms，仿真时使用FTP流量。路由器的队列管理机制使用DropTail，频宽为0.8Mbps，传递延迟为100ms。在这个实验中建立3条TCP数据流，0和4、1和4、2和4。在OTCL编码中，代理节点的协议代理分别设置为TCP/Reno、TCP/Newreno、TCP/Sack1和tcp/Vegas，来模拟这四种算法。 二、模拟结果与算法分析比较 1、模拟拥塞控制四种算法的cwnd变换图：
2、TCP拥塞控制的四个阶段 这是TCP拥塞控制的核心，也体现了TCP拥塞控制的基本思想，它分为启动阶段，拥塞避免，快速重传和快速恢复阶段。 (1) 启动阶段 当连接刚建立或在发生一次超时的情况下，进入慢启动阶段。 一个新的TCP连接建立后，cwnd被初始化为1，源端只被允许发送一个报文段。当发出的报文收到接受端的ACK确认后，cwnd加1，即增加一个报文段发送。在这个阶段中，cwnd随RTT呈指数增长。 采用慢启动方法，可以防止TCP在启动一个新的连接时发送过多的数据而造成数据丢失和网络拥塞，同时，由于cwnd实际上以指数规律增长也就避免了单纯的AIMD算法造成的吞吐量增加过慢的问题。 cwnd的无限增长必将引起网络拥塞，于是引入一个状态变量：慢启动阈值ssthresh。 当cwnd
课程设计报告滑动窗口协议仿真
滁州学院 课程设计报告 课程名称: 计算机网络 第五组 起止日期：2011年n 月24 口~2011年12月7 n 指导教师: 设计题目: 滑动窗口协议仿贞 别: 计算机与信息工程学院 业: 计算机科学与技术 计算机与信息工程学院二O —一年制 别: 赵国柱
课程设计任务书 一.引言二-基本原理 窗口机制 Ibit滑动窗口协议后退N协议选择重传协议流量控制三.需求分析 课程设计题目开发环境
运行环境 课程设计任务及要求 界面要求 网络接口要求 0. 详细设计 结构体的定义 发送方的主要函数 接受方的主要函数 五. 源代码 发送方的主要代码 接收方的主要代码 调试与操作说明 致谢 ［参考文献］ 课程设计的主要内容 L引言 早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道网络拥塞状况，一起发送数据，导致中间结点阻塞掉包，谁也发不了数据。在数据传输过程中，我们总是希望数据传输的更快一些，但如果发送方把数据发送的过快，接收方就可能來不及接收，这就造成数据的丢失。因此就有了滑动窗口机制来解决这些问题。早期我们使用的是Ibit滑动窗口协议，一次只发送一个帧, 等收到ack确认才发下一个帧，这样对信道的利用率太低了。因此提出了一种采用累积确认的连续ARQ协议，接收方不必对收到的帧逐个发送 ack确认，而是收到儿个帧后，对按序到达的最后一个帧发送ack确认。 同Ibit滑动窗口协议相比，大大减少了 ack数量，并消除了延迟ack对传输效率的影响。但是，这会产生一个新的问题，如果发送方发送了 5个帧，而中间的第3个帧丢失了。这时接收方只能对前2个帧发出确认。发送方无法知道后面三个帧的下落，只好把后面的3个帧再重传一次，这就是回退N协议。为了解决这个问题，乂提出了
TCP拥塞控制算法比较
TCP拥塞控制算法比较 TCP发展到现在已经形成了TCP Tahoe、TCP Reno、TCP NewReno、SACK、Vegas等不同版本，这些算法各有利弊。 Tahoe算法是TCP的早期版本。它的核心思想是：让cwnd以指数增长方式迅速逼近可 用信道容量，然后慢慢接近均衡。它包括了3个基本的拥塞控制算法：慢启动、拥塞避免、快速重传。Tahoe的缺点体现在快速重传后转向慢启动算法，这样不能有效的利用网络带宽并且还引入较大的延时。 Reno算法是针对Tahoe算法的不足而做的改进。改进主要有两方面：一是对于收到连 续3个重复的ACK确认，算法不经过慢启动，而直接进入拥塞避免阶段；二是增加了快速重传和快速恢复机制。Reno算法以其简单、有效和鲁棒性成为TCP源算法的主流，被广泛的 采用。但它不能有效的处理多个报文分组从同一发送窗口中丢失的情况。 NewReno对Reno中快速恢复算法进行了补充，它考虑了一个发送窗口内多个报文分组 同时丢失的情况。Reno算法中，发送方收到一个不重复的应答后就退出快速恢复，而NewReno 中，只有当所有的报文分组都被应答后才退出快速恢复状态。NewReno的实现只要修改TCP 发送端的实现代码，实现简单。 SACK算法也针对一个窗口内多个报文分组丢失的情况而对Reno算法进行改进：SACK 定义了一个变量pipe来表示出现在路由器上报文分组的估计数量，接收方TCP发送SACK 分组来通知发送方的接收状况，这样源端就能准确的知道哪些报文分组被正确的传到接收端，从而避免不必要的重传，提高网络吞吐量。但SACK算法的实现需要修改TCP发送端和接收端的实现代码，增加了TCP的复杂性，因此不易大规模的应用。 Vegas与上述的算法不同，它是以RTT的变化作为拥塞信号，调节源端的发送速率。通过监测RTT的变化来改变cwnd的大小。由于Vegas采用RTT的改变来判断网络的可用带宽，能较好的预测网络带宽的使用情况，其公平性、效率都较好。但是，由于Vegas与其它算法在竞争带宽方面存在不公平现象，因此未能在因特网中普遍采用，还需要继续改进。
TCP拥塞控制分析
TCP 拥塞控制分析 摘要：随着计算机网络的飞速发展，网络用户数量急剧增加，Internet 在各个领域也发挥越来越重要的作用，但随着其流量的急剧增加，由此引发的网络拥塞已经成为制约网络发展和应用的瓶颈问题。拥塞容易造成传输延迟和吞吐量等性能指标的下降，严重影响带宽、缓存等网络资源的利用率。TCP 作为应用最广泛的传输协议，它的拥塞控制已经成为其成功的关键。本文针对这一现象对TCP 性能及拥塞控制进行研究，我们将简单探讨网络拥塞出现的原因，着重介绍TCP 拥塞控制的原理并分析四个TCP 拥塞控制算法，最后论述TCP 拥塞控制所面临的问题，根据此提出进一步的研究方向。 关键词：TCP 拥塞、拥塞控制、TCP Tahoe 、TCP Reno 、TCP SACK 、TCP Vegas 1. 拥塞产生的原因 拥塞是一种持续过载的网络状态，此时用户对网络资源（包括链路带宽，存储空间和处理器的处理能力等）的需求超过了其固有的容量。拥塞导致的直接结果就是分组丢失率增加，端到端延时加大，甚至有可能使整个系统发生崩溃。 网络产生拥塞的根本原因在于用户或端系统提供给网络的负载大于网络资源容量和处理能力，即网络提供的资源不足以满足用户的需求，这些资源包括缓存空间、链路带宽容量和中间结点的处理能力等，使其产生数据包时延增加、丢弃概率增大、上层应用系统性能显著下降等典型现象。拥塞产生的直接原因有三点： （1）存储空间不足。缓存的容量不够大，当缓存已经装满，没有空闲的空间时就只能将新到达的分组丢弃。 （2）带宽容量不足，低速链路对高速数据流的输入也会产生拥塞。任何信道带宽最大值为()N +B =S C 1log 2(N 为信道噪声平均功率，S 为信源平均功率，B 为信道带宽) [1]。 要求所有信源发送的速率R 必须小于等于信道容量C 。 （3）处理器处理能力弱，速度慢。低速链路对高速CPU 也会产生拥塞。 要避免拥塞的发生，必须对链路带宽、路由器处理速度和存储容量等问题予以考虑，尽可能使系统的各个部分相互匹配。但由于网络流量分布的不均衡性，随着用户数量和
滑动窗口协议模拟程序的设计与实现
长沙理工大学 《网络协议编程》课程设计报告 梁碧莹 学院计算机与通信工程专业网络工程 班级网络08-02 学号200858080205 学生姓名梁碧莹指导教师王静 课程成绩完成日期2011年7 月 2 日
课程设计任务书 计算机与通信工程学院网络工程专业
课程设计成绩评定 学院计算机通信工程专业网络工程 班级网络08-02 班学号200858080205 学生姓名梁碧莹指导教师王静 课程成绩完成日期2011年7 月2 日指导教师对学生在课程设计中的评价 指导教师对课程设计的评定意见
滑动窗口协议模拟程序的设计与实现 学生：梁碧莹指导老师：王静 摘要：本文主要介绍如何根据滑动窗口协议的原理，在Visual C++的平台上设计一个滑动窗口协议模拟程序，并最终使该程序得以实现。本次程序设计分两部分：第一部分是发送方，第二部分是接收方。通过发送方和接收方之间的数据帧传输模拟，学习滑动窗口协议控制流量的原理和方法，以及滑动窗口协议的工作机制。 关键词：滑动窗口协议流量控制工作机制模拟程序 Design and Implementation of Sliding Window Protocol Procedures Student: Liang Biying Instructor: Wang Jing Abstract: This paper describes the principle of Sliding Window Protocol and how to design and implement a procedure about the Sliding Window Protocol. The program design in two parts, one is the sender, the other is the receiver. After all, studying the principle and method of how the Sliding Window Protocol control the flow, and how the Sliding Window Protocol works through the transmission of data between the sender and the receiver. Keywords: Sliding window protocol Flow control Working mechanism Simulation program
滑动窗口的仿真协议书范本
计算机网络课程设计书
计算机网络课程设计说明书 （封面） 学院名称：计算机与信息工程学院班级名称：网络工程一班 学生： 学号： 201321 题目：滑动窗口协议仿真指导教师 姓名：邵雪梅 起止日期： 2015.6.23－2015.6.29
第一部分：正文部分 一，选题背景 早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道网络拥塞状况，一起发送数据，导致中间结点阻塞掉包，谁也发不了数据。在数据传输过程中，我们总是希望数据传输的更快一些，但如果发送方把数据发送的过快，接收方就可能来不及接收，这就造成数据的丢失。因此就有了滑动窗口机制来解决这些问题。早期我们使用的是1bit滑动窗口协议，一次只发送一个帧，等收到ack确认才发下一个帧，这样对信道的利用率太低了。因此提出了一种采用累积确认的连续ARQ协议，接收方不必对收到的帧逐个发送ack确认，而是收到几个帧后，对按序到达的最后一个帧发送ack确认。 同1bit滑动窗口协议相比，大大减少了ack数量，并消除了延迟ack对传输效率的影响。但是，这会产生一个新的问题，如果发送方发送了5个帧，而中间的第3个帧丢失了。这时接收方只能对前2个帧发出确认。发送方无法知道后面三个帧的下落，只好把后面的3个帧再重传一次，这就是回退N协议。为了解决这个问题，又提出了选择重传协议。当接收方发现某帧出错后，继续接受后面送来的正确的帧，只是不交付它们，存放在自己的缓冲区中，并且要求发送方重传出错的那一帧。一旦收到重传来的帧后，就可以将存于缓冲区中的其余帧一并按正确的顺序递交给主机。本文主要介绍如何根据滑动窗口协议的原理，在Visual C++的平台上设计一个滑动窗口协议模拟程序，并最终使该程序得以实现。本次程序设计分两部分：第一部分是发送方，第二部分是接收方。通过发送方和接收方之间的数据帧传输模拟，学习滑动窗口协议控制流量的原理和方法，以及滑动窗口协议的工作机制。
程序员面试必考题(十八)--TCP的拥塞控制机制
拥塞控制（congestion control)是TCP协议的一项重要功能，TCP 的拥塞控制机制是从端到端的角度，推测网络是否发生拥塞，如果推断网络发生拥塞，则立即将数据发送速率降下来，以便缓解网络拥塞。TCP的拥塞控制采用的是窗口机制，通过调节窗口的大小实现对数据发送速率的调整。TCP的发送端维持一个称为拥塞窗口cwnd的变量，单位为字节，用于表示在未收到接收端确认的情况下，可以连续发送的数据字节数。cwnd的大小取决于网络的拥塞程度，并且动态地发生变化。拥塞窗口调整的原则是：只要网络没有出现拥塞，就可以增大拥塞窗口，以便将更多的数据发送出去，相当于提高发送速率；一旦网络出现拥塞，拥塞窗口就减小一些，减少注入网络的数据量，从而缓解网络的拥塞。 发送端判断网络发生拥塞的依据是：发送端设置一个重传计时器RTO，对于某个已发出的数据报文段，如果在RTO计时到期后，还没有收到来自接收端的确认，则认为此时网络发生了拥塞。 TCP的拥塞控制算法包括了慢启动（slow start）、拥塞避免（congestion avoidance）、快速重传（fast retransmit）和快速恢复（fast recovery）四部分。 慢启动算法作用在TCP数据传输的开始阶段，当主机开始发送数据时，因为不知道网络中的负荷情况，如果立即发送大量的数据，有可能会引起网络的拥塞。因此，TCP采用试探的方法，逐渐增大拥塞窗
口。通常在刚开始发送数据报文段时，先将拥塞窗口cwnd设置为一个TCP最大段长度MSS的值。而在每收到一个数据报文段的确认后，cwnd就增加一个MSS的数值。这样就可以逐渐增大发送端的拥塞窗口，使数据注入网络的速率比较合理。如果定义从发送端发出一个数据报文段到收到这个数据报文段的确认的时间间隔为往返时间RTT，则在慢启动阶段，每经过一个RTT，cwnd的值就加倍。 为了防止拥塞窗口增长过快而引起网络拥塞，TCP还需要设置一个慢启动阈值ssthresh，当拥塞窗口的值增加到ssthresh时，就要减缓拥塞窗口的增长速度，具体的做法是每经过一个RTT，拥塞窗口cwnd 的值加1（单位为MSS），这样就可以使cwnd按线性规律缓慢增长，这个过程称之为“加性增加”（Additive Increase）算法。通常情况下，拥塞窗口cwnd的初值被设置为1，慢启动阈值ssthresh的初值被设置为16。当拥塞避免算法执行到某个时刻，发送端在规定时间内没有收到接收端的确认，即发生了网络超时，则意味着网络发生了拥塞。此时，发送端首先将ssthresh的值变为发生超时时cwnd值的一半，同时将cwnd的值置为1，重新执行慢启动算法。这样做的好处是，当网络频繁出现拥塞时，ssthresh下降得很快，可以大大减少注入网络中的数据报文段。通常称这个过程为“乘性减小”（MultiplicativeDecrease）算法。TCP中的“加性增加”和“乘性减小”算法合起来称为AIMD算法。
TCP协议拥塞控制算法
TCP协议拥塞控制算法研究 摘要：自从1986年互联网出现严重的拥塞崩溃现象后，网络拥塞控制受到了广泛的关注。随着网络的不断发展，网络用户及需求急剧增加，网络拥塞也越来越严重。如何有效解决网络拥塞，成为人们急需解决的问题。TCP作为目前互联网上使用最广泛的一种传输协议，TCP拥塞控制机制对互联网的稳定运行起着重要的作用。本文阐述了TCP的拥塞控制机制以及几种TCP拥塞控制算法，并对它们进行了仿真，比较了他们各自的优缺点，并指出了进一步改进TCP拥塞控制的必要性。 关键字：互联网；TCP；拥塞控制 Abstract：Since the advent of the Internet congestion collapse in 1986, network congestion control has been widespread concern. With the continuous development of the network, network users and the demand are increasing rapidly, network congestion has become increasingly serious. How to effectively solve network congestion become an urgent problem. TCP currently used on the Internet as the most widely used transport protocol, TCP congestion control mechanisms for the stable operation of the Internet plays an important role. This paper describes the TCP congestion control mechanisms as well as several TCP congestion control algorithms, and their simulation to compare their advantages and disadvantages, and pointed out the need for further improvement of TCP congestion control. Keywords：Internet；TCP；Congestion control 1 引言 近年来以IP为基础的internet呈爆炸式增长，网络用户数量迅速增加，internet 在各个领域也发挥着越来越重要的作用，但随着其流量急剧增加，由此而引发的网络拥塞已经成为制约网络发展和应用的瓶颈问题。在计算机网络中的宽带、交换节点中的缓存和处理机等，都是网络资源。如果网络相对于负载需求表现为节点存储空间不足、链路带宽不足、处理器处理速度慢，以及系统各部分性能不匹配等等，从而导致网络上的包时延增加，丢包率上升，吞吐量下降，直接使服务质量下降。概括来说就是在某一时间段里，如果网络中的某一资源的需求量超过了该网络所能提供的网络资源的可用部分，网络的性能就能变坏。诸如网络延时
TCP拥塞控制四个主要过程
TCP拥塞控制四个主要过程（如图（a）和（b）所示）简要介绍如下： 图（a）：慢启动和拥塞避免图（b）：快速重传和快速恢复 1.慢启动阶段：早期开发的TCP应用在启动一个连接时会向网络中发送大量的数据包，这样 很容易导致路由器缓存空间耗尽，网络发生拥塞，使得TCP连接的吞吐量急剧下降。由于TCP源端无法知道网络资源当前的利用状况，因此新建立的TCP连接不能一开始就发送大量数据，而只能逐步增加每次发送的数据量，以避免上述现象的发生。具体地说，当建立新的TCP连接时，拥塞窗口（congestion window，cwnd）初始化为一个数据包大小。源端按 cwnd大小发送数据，每收到一个ACK确认，cwnd就增加一个数据包发送量，这样cwnd就将随着回路响应时间（Round Trip Time，RTT）呈指数增长，源端向网络发送的数据量将急剧增加。事实上，慢启动一点也不慢，要达到每RTT发送W个数据包所需时间仅为 RTT×logW。由于在发生拥塞时，拥塞窗口会减半或降到1，因此慢启动确保了源端的发送速率最多是链路带宽的两倍。 2.拥塞避免阶段：如果TCP源端发现超时或收到3个相同ACK副本时，即认为网络发生了拥 塞（主要因为由传输引起的数据包损坏和丢失的概率很小（<<1%））。此时就进入拥塞避免阶段。慢启动阈值（ssthresh）被设置为当前拥塞窗口大小的一半；如果超时，拥塞窗口被置1。如果cwnd>ssthresh，TCP就执行拥塞避免算法，此时，cwnd在每次收到一个ACK时只增加1/cwnd个数据包，这样，在一个RTT内，cwnd将增加1，所以在拥塞避免阶段，cwnd 不是呈指数增长，而是线性增长。 3.快速重传和快速恢复阶段：快速重传是当TCP源端收到到三个相同的ACK副本时，即认为 有数据包丢失，则源端重传丢失的数据包，而不必等待RTO超时。同时将ssthresh设置为当前cwnd值的一半，并且将cwnd减为原先的一半。快速恢复是基于“管道”模型（pipe model）的“数据包守恒”的原则（conservation of packets principle），即同一时刻在网络中传输的数据包数量是恒定的，只有当“旧”数据包离开网络后，才能发送“新”数据包进入网络。如果发送方收到一个重复的ACK，则认为已经有一个数据包离开了网络，于是将拥塞窗口加1。如果“数据包守恒”原则能够得到严格遵守，那么网络中将很少会发生拥塞；本质上，拥塞控制的目的就是找到违反该原则的地方并进行修正。 经过十多年的发展，目前TCP协议主要包含有四个版本：TCP Tahoe、TCP Reno、TCP NewReno 和TCP SACK。TCP Tahoe是早期的TCP版本，它包括了3个最基本的拥塞控制算法－“慢启动”、“拥塞避免”和“快速重传”。TCP Reno在TCP Tahoe基础上增加了“快速恢复”算法。TCP NewReno对TCP Reno中的“快速恢复”算法进行了修正，它考虑了一个发送窗口内多个数据包丢失的情况。在Reno 版中，发送端收到一个新的ACK后旧退出“快速恢复”阶段，而在NewReno版中，只有当所有的数据包都被确认后才退出“快速恢复”阶段。TCP SACK关注的也是一个窗口内多个数据包丢失的情况，它避免了之前版本的TCP重传一个窗口内所有数据包的情况，包括那些已经被接收端正确接收的数据包，而只是重传那些被丢弃的数据包。
课程设计报告滑动窗口协议仿真精编
课程设计报告滑动窗口 协议仿真精编 Document number：WTT-LKK-GBB-08921-EIGG-22986
滁州学院 课程设计报告 课程名称：计算机网络 设计题目：滑动窗口协议仿真 系别：计算机与信息工程学院 专业：计算机科学与技术 组别：第五组 起止日期: 2011年11月24日~2011年12月7日指导教师:赵国柱 计算机与信息工程学院二○一一年制
课程设计任务书 一. 引言 二. 基本原理 窗口机制 1bit滑动窗口协议 后退N协议 选择重传协议 流量控制
三. 需求分析 课程设计题目 开发环境 运行环境 课程设计任务及要求 界面要求 网络接口要求 四. 详细设计 结构体的定义 发送方的主要函数 接受方的主要函数五. 源代码 发送方的主要代码 接收方的主要代码六. 调试与操作说明 致谢 [参考文献]
课程设计的主要内容 1.引言 早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道网络拥塞状况，一起发送数据，导致中间结点阻塞掉包，谁也发不了数据。在数据传输过程中，我们总是希望数据传输的更快一些，但如果发送方把数据发送的过快，接收方就可能来不及接收，这就造成数据的丢失。因此就有了滑动窗口机制来解决这些问题。早期我们使用的是1bit滑动窗口协议，一次只发送一个帧，等收到ack确认才发下一个帧，这样对信道的利用率太低了。因此提出了一种采用累积确认的连续ARQ 协议，接收方不必对收到的帧逐个发送ack确认，而是收到几个帧后，对按序到达的最后一个帧发送ack确认。同1bit滑动窗口协议相比，大大减少了ack数量，并消除了延迟ack对传输效率的影响。但是，这会产生一个新的问题，如果发送方发送了5个帧，而中间的第3个帧丢失了。这时接收方只能对前2个帧发出确认。发送方无法知道后面三个帧的下落，只好把后面的3个帧再重传一次，这就是回退N协议。为了解决这个问题，又提出了选择重传协议。当接收方发现某帧出错后，继续接受后面送来的
数据链路层滑动窗口协议的设计和实现样本
数据链路层滑动窗口协议的设计和实现样本数据链路层滑动窗口协议的设计和实现本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 数据链路层滑动窗口协议的设计与实现实验报告 一、实验任务及内容利用所学数据链路层原理，设计一个滑动窗口协议并在仿真环境下编程实现有噪音信道环境下的可靠的双工通信。 信道模型为8000bps全双工卫星信道，信道传播时延270毫秒，信道误码率为10--55，信道提供字节流传输服务，网络层分组长度在240~256字节范围。 (1)实现有噪音信道环境下的无差错传输。 (2)运行程序并检查在信道没有误码和存在误码两种情况下的信道利用率。 (3)提高滑动窗口协议信道利用率，根据信道实际情况合理地为协议配置工作参数，包括滑动窗口的大小和重传定时器时限以及ACK搭载定时器的时限。 实验环境Windows7环境PC，机，Microsoft VisualC++集成化开发环境 二、协议设计协议的分层结构及层服务::包括物理层，数据链路层和网络层三层。
该实验主要设计数据链路层协议，为实现有噪声环境下高信道利用率传输，我们采用回本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 退n n帧（go backn）技术的协议。 发送方窗口大小为31；通过捎带确认来完成可靠的数据通信；出现信道误码导致收帧出错时，接受方丢弃所有后续帧，待定时器超时后发送方重发。 该层提供服务::从网络层接受要发送的数据包，将之分拆成数据帧；按一定的成帧方案完成分帧，加校验码，加ack等操作；进行适当的流量判断和拥塞控制；启动定时器将之传递给物理层。 数据帧经信道传送给接受方，接受方数据链路层执行与成帧相逆的操作；处理ack信息，终止定时器（或启动ack定时器，ack成帧传送）；判断是否为欲接受数据，数据是否出错，提交给网络层。 退回N N步工作原理示意图::本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。 文档如有不当之处，请联系本人或网站删除。 实验所形成帧((成帧方案))::DATA Framen+=========+========+========+===============+======== +|KIND (1)|ACK (1)|SEQ
滑动窗口的仿真协议
计算机网络课程设计书 学 院 计算机与信息工程学院专业网络工程 课程名称计算机网络题目滑动窗口协议仿真完成期限自2015年6月23日至2015年6月29日共1周 内容及任务一、项目的目的 掌握滑动窗口协议的工作原理，并能够用所学计算机高级 语言进行编程模拟其运行过程;培养学生的动手实践和思考能力。 二，项目任务的主要内容和要求 (1)本次设计任务是根据滑动窗口协议的工作原理，在Visual C++ 6.0的平台上用C++语言编写一个基本TCP滑动窗口协议的模拟程序。 (2)要求该程序能够实现滑动窗口协议的发送和接收数据帧 功能，在此功能上体现滑动窗口协议的运作。 (3) 程序按照滑动窗口协议实现端对端的数据传送。包括协议的各种策略，如包丢失、停等应答、超时等都应有所仿真实现； (4) 显示数据传送过程中的各项具体数据。双方帧的个数变化，帧序号，发送和接受速度，暂停或重传提示等； 三、项目设计（研究）思路 (1) 查阅相关资料，理解滑动窗口协议的工作原理； (2) 设计滑动窗口协议实现端对端数据传送的功能流程图； (3) 编写代码实现滑动窗口协议工作的模拟程序，包括包丢失、停等应答、超时等； (4) 测试程序功能的实现情况。 四、具体成果形式和要求 (1)滑动窗口协议实现端对端数据传送的模拟程序。 (2)按照要求撰写课程设计报告并准备答辩。
进度安排 起止日期工作内容 2015.6.23-2015 .6.24 了解网络协议编程的基本知识； 2015.6.25-2015 .6.26 了解滑动窗口协议的工作机制； 2015.6.27-2015 .6.28 使用编程语言编写一个滑动窗口协议的模拟 程序，按要求实现程序。 2015.6.29最后汇总，调试，答辩 主要参考资料[1] 谢希仁. 计算机网络[M]. 4版. 北京:电子工业出版社, 2003. [2] 李仁发.何彦. 基于虚拟实验方法的滑动窗口协议分析[J]. 系统仿真学报. 2002. 8 (14) ; 1026 - 1063. [3] 李建中,张冬冬. 滑动窗口规模的动态调整算法[J]. 软件学报. 2004. 12 (15) : 1800 - 1814. [4] 王栩,李建中,王伟平. 基于滑动窗口的数据流压缩技术及连续查询处理方法[ J ]. 计算机研究与发展. 2004. 10 (41) : 1639- 1644. [5] 特南鲍姆. 计算机网络（第四版）. 清华出版社 指导教师 意见 （签字）：×年×月×日 系（教研 室）主任 意见 （签字）：×年×月×日
分析TCP的拥塞控制原理
分析TCP的拥塞控制原理 TCP是Transmission Control Protocol的缩写，即传输控制协议，它对应于OSI七层模型中的传输层，建立于网络层之上。TCP旨在给互联网提供一种可*的端到端的字节传输流。 自从1988年问世以来，TCP在研究者的努力下先后得到了许多新的发展，目前主要的模型包括四个，即TCP TAHOE，TCP RENO，TCP NEWRENO和TCP SACK。TCP TAHOE 模型是最早的TCP协议之一，它由Jacobson提出。Jacobson观察到，TCP报文段（TC P Segment）丢失有两种原因，其一是报文段损坏，其二是网络阻塞，而当时的网络主要是有线网络，不易出现报文段损坏的情况，网络阻塞为报文段丢失的主要原因。针对这种情况，TCP TAHOE对原有协议进行了性能优化，其特点是，在正常情况下，通过重传计时器是否超时和是否收到重复确认信息（dupack）这两种丢包监测机制来判断是否发生丢包，以启动拥塞控制策略；在拥塞控制的情况下，采用慢速启动（Slow Start）算法和快速重传（Fast Retransmit）算法来控制传输速率。 在试验中，我们以TCP TAHOE模型为例，对TCP的拥塞控制原理进行分析，包括两种丢包监测机制和拥塞控制中的慢速启动算法和快速重传算法。 1. TCP拥塞控制相关技术简介 1.1 慢速启动算法 在TCP TAHOE模型中，拥塞控制主要是通过调整发送端的发送速率，而这又主要是通过三个变量实现的：拥塞窗口（Congestion Window），接收端窗口（Receivers’s W indow），慢速启动阈值（Slow Start Threshold，SSTHRESH）。发送端一旦监测到数据包丢失（其原因可能是重传计时器超时，亦可能是收到重复的ACK信令），它就会开始调整发送速率。这包括，ssthresh调整为当前拥塞窗口的一半，同时拥塞窗口将降低到1个报文段。然后，随着通信过程的恢复，拥塞窗口持续增长。在拥塞窗口大小未达到ssthresh之前，它以指数速度增长；到达之后则开始线性增长。有趣的是，虽然这种算法称为慢速启动算法，但实际上一点儿也不慢，它是指数增长的。 1.2 快速重传算法 当发送端连续收到3个对应于同一个序列号的ACK信令时，就触发了其快速重传算法，即发送端不等重传计时器超时，立即向接收端发送指定的报文段。 1.3 丢包检测机制有如下两种 (1). 重复ACK信令 重复ACK有两个作用，其一，发送端可以确信该ACK序列号之前的TCP报文段都已经被接收端成功接收；其二，发送端可以据此判断出接收端接收到的TCP报文段发生了乱序的情况和接收端当前期待的TCP报文段序列号，从而触发其拥塞控制策略。
TCP拥塞控制算法性能比较
TCP拥塞控制算法性能比较 1011010409 秦树东 1、NS2仿真 仿真实验的网络结构图 如图所示0、1、2为源节点，3为路由器，4为目的节点。源节点0、1、2为TCP代理节点，频宽为8Mbps，传递延迟时间为0.1ms，仿真时使用FTP流量。路由器的队列管理机制使用DropTail，频宽为0.8Mbps，传递延迟为100ms。在这个实验中建立3条TCP数据流，0和4、1和4、2和4。在OTCL编码中，代理节点的协议代理分别设置为TCP/Reno和TCP/Vegas，来模拟这两种算法。 2、模拟结果与算法分析比较 1、模拟拥塞控制TCP Reno算法的cwnd变换图：
TCP Reno Tcl代码如下： #产生一个仿真对象 set ns [new Simulator] #开启一个trace文件，用来记录封包传送过程 set nd [open out.tr w] $ns trace-all $nd #开启3个文件用来记录3条TCP Connection的cwnd变化情况set f0 [open cwnd0.tr w] set f1 [open cwnd1.tr w] set f2 [open cwnd2.tr w] #定义一个结束程序 proc finish {} { global ns nd f0 f1 f2 $ns flush-trace #关闭文件 close $nd close $f0 close $f1 close $f2
exit 0 } #定义一个记录的程序 #每隔0.01s记录当时的cwnd proc record {tcp_} { global ns f0 f1 f2 upvar $tcp_ tcp set now [$ns now] puts $f0 "$now [$tcp(0) set cwnd_]" puts $f1 "$now [$tcp(1) set cwnd_]" puts $f2 "$now [$tcp(2) set cwnd_]" $ns at [expr $now+0.01] "record tcp" } #设置路由节点 set r0 [$ns node] #设置目的节点 set d0 [$ns node] #路由与目的节点的链路属性 $ns duplex-link $r0 $d0 0.8Mb 100ms DropTail $ns queue-limit $r0 $d0 64 for {set i 0} {$i < 3} {incr i} { #设置源节点 set s($i) [$ns node] set d($i) [$ns node] $ns duplex-link $s($i) $r0 8Mb 0.1ms DropTail #设置代理 set tcp($i) [new Agent/TCP/Reno] set tcpsink($i) [new Agent/TCPSink] $ns attach-agent $s($i) $tcp($i) $ns attach-agent $d0 $tcpsink($i) $ns connect $tcp($i) $tcpsink($i) $tcp($i) set fid_ $i