TCP 滑动窗口协议 详解
滑动窗口机制
(1).窗口机制
滑动窗口协议的基本原理就是在任意时刻，发送方都维持了一个连续的允许发送的帧的序号，称为发送窗口；同时，接收方也维持了一个连续的允许接收的帧的序号，称为接收窗口。发送窗口和接收窗口的序号的上下界不一定要一样，甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。发送方窗口内的序列号代表了那些已经被发送，但是还没有被确认的帧，或者是那些可以被发送的帧。下面举一个例子（假设发送窗口尺寸为2，接收窗口尺寸为1）：
分析：①初始态，发送方没有帧发出，发送窗口前后沿相重合。接收方0号窗口打开，等待接收0号帧；②发送方打开0号窗口，表示已发出0帧但尚确认返回信息。此时接收窗口状态不变；③发送方打开0、1号窗口，表示0、1号帧均在等待确认之列。至此，发送方打开的窗口数已达规定限度，在未收到新的确认返回帧之前，发送方将暂停发送新的数据帧。接收窗口此时状态仍未变；④接收方已收到0号帧，0号窗口关闭，1号窗口打开，表示准备接收1号帧。此时发送窗口状态不变；⑤发送方收到接收方发来的0号帧确认返回信息，关闭0号窗口，表示从重发表中删除0号帧。此时接收窗口状态仍不变；⑥发送方继续发送2号帧，2号窗口打开，表示2号帧也纳入待确认之列。至此，发送方打开的窗口又已达规定限度，在未收到新的确认返回帧之前，发送方将暂停发送新的数据帧，此时接收窗口状态仍不变；⑦接收方已收到1号帧，1号窗口关闭，2号窗口打开，表示准备接收2号帧。此时发送窗口状态不变；⑧发送方收到接收方发来的1号帧收毕的确认信息，关闭1号窗口，表示从重发表中删除1号帧。此时接收窗口状态仍不变。
若从滑动窗口的观点来统一看待1比特滑动窗口、后退n及选择重传三种协议，它们的差别仅在于各自窗口尺寸的大小不同而已。1比特滑动窗口协议：发送窗口=1，接收窗口=1；后退n协议：发窗口>1，接收
窗口>1；选择重传协议：发送窗口>1,接收窗口>1。
(2).1比特滑动窗口协议
当发送窗口和接收窗口的大小固定为1时，滑动窗口协议退化为停等协议（stop－and－wait）。该协议规定发送方每发送一帧后就要停下来，等待接收方已正确接收的确认（acknowledgement）返回后才能继续发送下一帧。由于接收方需要判断接收到的帧是新发的帧还是重新发送的帧，因此发送方要为每一个帧加一个序号。由于停等协议规定只有一帧完全发送成功后才能发送新的帧，因而只用一比特来编号就够了。其发送方和接收方运行的流程图如图所示。
(3).后退n协议
由于停等协议要为每一个帧进行确认后才继续发送下一帧，大大降低了信道利用率，因此又提出了后退n协议。后退n协议中，发送方在发完一个数据帧后，不停下来等待应答帧，而是连续发送若干个数据帧，即使在连续发送过程中收到了接收方发来的应答帧，也可以继续发送。且发送方在每发送完一个数据帧时都要设置超时定时器。只要在所设置的超时时间内仍收到确认帧，就要重发相应的数据帧。如：当发送方发送了N个帧后，若发现该N帧的前一个帧在计时器超时后仍未返回其确认信息，则该帧被判为出错或丢失，此时发送方就不得不重新发送出错帧及其后的N帧。
从这里不难看出，后退n协议一方面因连续发送数据帧而提高了效率，但另一方面，在重传时又必须把原来已正确传送过的数据帧进行重传（仅因这些数据帧之前有一个数据帧出了错），这种做法又使传送效率降低。由此可见，若传输信道的传输质量很差因而误码率较大时，连续测协议不一定优于停止等待协议。此协议中的发送窗口的大小为k，接收窗口仍是1。
(4).选择重传协议
在后退n协议中，接收方若发现错误帧就不再接收后续的帧，即使是
正确到达的帧，这显然是一种浪费。另一种效率更高的策略是当接收方发现某帧出错后，其后继续送来的正确的帧虽然不能立即递交给接收方的高层，但接收方仍可收下来，存放在一个缓冲区中，同时要求发送方重新传送出错的那一帧。一旦收到重新传来的帧后，就可以原已存于缓冲区中的其余帧一并按正确的顺序递交高层。这种方法称为选择重发(SELECTICE REPEAT)，其工作过程如图所示。显然，选择重发减少了浪费，但要求接收方有足够大的缓冲区空间。
滑动窗口协议
仍然考虑链路的延迟与带宽的乘积为8 K B，帧尺寸为1 K B的情形。让发送方在收到第一帧的A C K的同时准备发送第九帧。允许我们这样做的算法称为滑动窗口（ sliding window），时间线如图2 - 2 1所示。1.滑动窗口算法
滑动窗口算法工作过程如下。首先，发送方为每1帧赋一个序号（sequence number），记作S e q N u m。现在，让我们忽略S e q N u m是由有限大小的头部字段实现的事实，而假设它能无限增大。发送方维护3个变量：发送窗口大小（send window size），记作S W S，给出发送方能够发
送但未确认的帧数的上界； L A R表示最近收到的确认帧（ last acknowledgement re c e i v e d）的序号；L F S表示最近发送的帧（last frame sent）的序号，发送方还维持如下的不变式：
LAR-LFR≤RWS
当一个确认到达时，发送方向右移动L A R，从而允许发送方发送另一帧。同时，发送方为所发的每个帧设置一个定时器，如果定时器在A C K到达之前超时，则重发此帧。注意：发送方必须存储最多S W S个帧，因为在它们得到确认之前必须准备重发。
接收方维护下面3个变量：接收窗口大小（receive window size），记
为RW S，给出接收方所能接收的无序帧数目的上界； L A F表示可接收帧（l a rgestacceptable frame）的序号；L F R表示最近收到的帧（last frame re ce i v e d）的序号。接收方也维持如下不变式：
LFS-LAR≤SWS
当一个具有顺序号S e q N u m的帧到达时，接收方采取如下行动：如果S e q N u m≤L F R或S e q N u m > L A F，那么帧不在接收窗口内，于是被丢弃；如果L F R＜Se q N u m≤L A F，那么帧在接收窗口内，于是被接收。现在接收方需要决定是否发送一个A C K。设S e q N u m To A C K表示未被确认帧的最大序号，则序号小于或等于S e q N u m To Ac k的帧都已收到。即使已经收到更高序号的分组，接收方仍确认S e q N u m To A c k的接收。这种确认被称为是累积的（c u m u l a t i v e）。然后它设置L F R = S e q Nu m To A c k，并调整L A F = L F R + RW S。例如，假设L F R= 5（即，上次接收方发送的A C K是为了确认顺序号5的），并且RWS = 4。这意味着L A F = 9。如果帧7和8到达，则存储它们，因为它们在接收窗口内。然而并不需要发送A C K，因为帧6还没有到达。帧7和8被称为是错序到达的。（从技术上讲，接收方可以在帧7和8到达时重发帧5的A C K。）如果帧6当时到达了（或许它在第一次丢失后又重发从而晚到，或许它只是被延迟了），接收方确认帧8，L F R置为8，L A F置为1 2。如果实际上帧6丢失了，则出现发送方超时，重发帧6。我们看到，当发生超时时，传输数据量减少，这是因为发送方在帧6确认之前不能向前移动窗口。这意味着分组丢失时，此方案将不再保证管道满载。注意：分组丢失时间越长，这个问题越严重。
注意，在这个例子中，接收方可以在帧7刚一到达时就为帧6发送一个认帧N A K（negative acknowledgment）。然而，由于发送方的超时机制足以发现这种情况，发送N A K反而为发送方增加了复杂性，因此不必这样做。正如我们已提到的，当帧7和8到达时为帧5发送一个额外的A C K是合理的；在某些情况下，发送方可以使用重复的A C K作为一个帧丢失的线索。这两种方法都允许早期的分组丢失检测，有助于改进性能。
关于这个方案的另一个变种是使用选择确认（selective
acknowledgements）。即，接收方能够准确地确认那些已收到的帧，而不只是确认按顺序收到最高序号的帧。因此，在上例中，接收方能够确认帧7、8的接收。如果给发送方更多的信息，就能使其较容易地保持管道满载，但增加了实现的复杂性。
发送窗口大小是根据一段给定时间内链路上有多少待确认的帧来选择的；对于一个给定的延迟与带宽的乘积，S W S是容易计算的。另一方面，接收方可以将RW S设置为任何想要的值。通常的两种设置是：RW S= 1，表示接收方不存储任何错序到达的帧； RW S=S W S，表示接收方能够缓存发送方传输的任何帧。由于错序到达的帧的数目不可能超过S W S个，所以设置RWS >S W S没有意义。
2.有限顺序号和滑动窗口
现在我们再来讨论算法中做过的一个简化，即假设序号是可以无限增大的。当然，实际上是在一个有限的头部字段中说明一个帧的序号。例如，一个3比特字段意味着有8个可用序号0 ~ 7。因此序号必须可重用，或者说序号能回绕。这就带来了一个问题：要能够区别同一序号的不同次发送实例，这意味着可用序号的数目必须大于所允许的待确认帧的数目。例如，停止等待算法允许一次有1个待确认帧，并有2个不同的序号。
假设序号空间中的序号数比待确认的帧数大1，即S W S ≤ M A a xS e q N u m -1 ，其中M a x Seq N u m 是可用序号数。这就够了吗？答案取决于RW S 。如果RW S = 1，那么MaxSeqNum≥SWS+1是足够了。如果RW S等于S W S，那么有一个只比发送窗口尺寸大1的M a x S e q N u m是不够的。为看清这一点，考虑有8个序号0 ~ 7的情况，并且S W S = RW S = 7。假设发送方传输帧0 ~ 6，并且接收方成功接收，但A C K丢失。接收方现在希望接收帧7，0 ~ 5，但发送方超时，然后发送帧0 ~ 6。不幸的是，接收方期待的是第二次的帧0 ~ 5，得到的却是第一次的帧0 ~ 5。这正是我们想避免的情况。
结果是，当RW S = S W S时，发送窗口的大小不能大于可用序号数的一半，或更准确地说，SWS<(Maxseqnum+1)/2直观地，这说明滑动窗口协议是在序号空间的两半之间变换，就像停止等待协议的序号是在0
和1之间变换一样。唯一的区别是，它在序号空间的两半之间连续滑动而不是离散的变换。
注意，这条规则是特别针对RW S = S W S的。我们把确定适用于RW S 和S W S的任意值的更一般的规则留做一个练习。还要注意，窗口的大小和序号空间之间的关系依赖于一个很明显以至于容易被忽略的假设，即帧在传输中不重新排序。这在直连的点到点链路上不能发生，因为在传输过程中一个帧不可能赶上另一个帧。然而，我们将在第5章看到用在一个不同环境中的滑动窗口算法，并且需要设计另一条规则。
3.滑动窗口的实现
下面的例程说明我们如何实现滑动窗口算法的发送和接收的两个方面。该例程取自一个正在使用的协议，称为滑动窗口协议S W P（Sliding Window Pro t o c o l）。为了不涉及协议图中的邻近协议，我们用H L P（高层协议）表示S W P上层的协议，用L I N K（链路层协议）表示S W P下层的协议。我们先定义一对数据结构。首先，帧头部非常简单：它包含一个序号（ S e q N u m）和一个确认号（ A c k N u m）。它还包含一个标志（ F l a g s）字段，表明帧是一个A C K帧还是携带数据的帧。
其次，滑动窗口算法的状态有如下结构。对于协议发送方，该状态包括如上所述的变量L A R和L F S，以及一个存放已发出但尚未确认的帧的队列（ s e n d Q）。发送方状态还包含一个计数信号量（ counting semaphore），称为s e n d Wi n d o w N o t F u l l。下面我们将会看到如何使用它，但一般来说，信号量是一个支持s e m Wa i t和s e m S i g n a l操作的同步原语。每次调用S e m S i g n al，信号量加1，每次调用S e m Wa i t，信号量减1。如果信号量减小，导致它的值小于0，那么调用进程阻塞（挂起）。一旦执行了足够的s e m S i g n a l操作而使信号量的值增大到大于0，在调用s e m Wa i t的过程中阻塞的进程就允许被恢复。
对于协议的接收方，如前所述，该状态包含变量L F R ，加上一个存放已收到的错序帧的队列（r e c v Q）。最后，虽然未显示，发送方和接收方的滑动窗口的大小分别由常量S W S和RW S表示。
S W P的发送方是由s e n d S W P过程实现的。这个例程很简单。首先， s e m Wa i t使这个进程在一个信号量上阻塞，直到它可以发另一帧。一旦允许继续， s e n d S W P设置帧头部中的顺序号，将此帧的拷贝存储在发送队列（s e n d Q）中，调度一个超时事件以便处理帧未被确认的情况，并将帧发给低层协议。
值得注意的一个细节是刚好在调用m s g A d d H dr之前调用s t o r e _ s w p _ h d r。该例程将存有S W P头部的C语言结构（ s t a t e -> h d r）转化为能够安全放在消息前面的字节串（ h b u f）。该例程（未给出）必须将头部中的每一个整数字段转化为网络字节顺序，并且去掉编译程序加入C语言结构中的任意填充。7 . 1节将详细讨论字节顺序的问题，但现在，假设该例程将多字整数中最高有效位放在最高地址字节就足够了。
这个例程的另一个复杂性是使用s e m Wa i t 和s e n dW i n d ow N o t F u l l 信号量。S e n dWi n d o w N o t F u l l被初始化为发送方滑动窗口的大小S W S（未给出这一初始化）。发送方每传输一帧， s e m Wa i t操作将这个数减1，如果减小到0，则阻塞发送方进程。每收到一个A C K，在d e l i v e r SW P中调用s e m S i g n a l操作（见下面）将此数加1，从而激活正在等待的发送方进程。
在继续介绍S W P的接收方之前，需要调整一个看上去不一致的地方。一方面，我们说过，高层协议通过调用s e n d操作来请求低层协议的服务，所以我们就希望通过S W P发送消息的协议能够调用s e n d（S W P, p a c k e t）。另一方面，用来实现S W P的发送操作的过程叫做s e n d S W P，并且它的第一个参数是一个状态变量（ S w p S t a t e）。结果怎样呢？答案是，操作系统提供了粘结代码将对s e n d的一般调用转化为对s e n d S W P的特定协议调用的粘结代码。这个粘结代码将s e n d的第一个参数（协议变量S W P）映射为一个指向s e n d S W P的函数指针和一个指向S W P工作时所需的协议状态的指针。我们之所以通过一般函数调用使高层协议间接调用特定协议函数，是因为我们想限制高层协议中对低层协议编码的信息量。这使得将来能够比较容易地改变协议图的配置。现在来看d e l i v e r操作的S W P的特定协议实现，
它在过程d e l i v e r SW P中实现。这个例程实际上处理两种不同类型的输入消息：本结点已发出帧的A C K和到达这个结点的数据帧。在某种意义上，这个例程的ACK部分是与send SWP中所给算法的发送方相对应的。通过检验头部的F l a g s字段可以确定输入的消息是ACK还是一个数据帧。注意，这种特殊的实现不支持数据帧中捎带A C K。当输入帧是一个ACK时，delive rSWP仅仅在发送队列（send Q）中找到与此ACK相应的位置（slot），取消超时事件，并且释放保存在那一位置的帧。由于A C K可能是累积的，所以这项工作实际上是在一个循环中进行的。对于这种情况值得注意的另一个问题是子例程swp In Wind o w的调用。这个子例程在下面给出，它确保被确认帧的序号是在发送方当前希望收到的A C K的范围之内。
当输入帧包含数据时， d e l i v e r S W P首先调用m s g S t r i pH d r和l o a d _ s w p _ h d r以便从帧中提取头部。例程l o a d _ s w p_ h d r 对应着前面讨论的s t o r e _ s w p _ h d r，它将一个字节串转化为容纳S W P头部的C语言数据结构。然后d e l i v e r SW P调用s w p I n Wi n d o w以确保帧序号在期望的序号范围内。如果是这样，例程在已收到的连续的帧的集合上循环，并通过调用d e l i v e r HL P例程将它们传给上层协议。它也要向发送方发送累积的A C K，但却是通过在接收队列上循环来实现的（它没有使用本节前面给出的s e q N u m To Ac k变量）。
最后，s w p I n Window是一个简单的子例程，它检查一个给定的序号是否落在某个最大和最小顺序号之间。
4.帧顺序和流量控制
滑动窗口协议可能是计算机网络中最著名的算法。然而，关于该算法易产生混淆的是，它可以有三个不同的功能，第一个功能是本节的重点，即在不可靠链路上可靠地传输帧。（一般来说，该算法被用于在一个不可靠的网络上可靠地传输消息。）这是该算法的核心功能。
滑动窗口算法的第二个功能是用于保持帧的传输顺序。这在接收方比较容易实现，因为每个帧有一个序号，接收方要保证已经向上层协议传递
了所有序号比当前帧小的帧，才向上传送该当前帧。即，接收方缓存了（即没有传送）错序的帧。本节描述的滑动窗口算法确实保持了帧的顺序，尽管我们可以想象一个变异，即接收方没有等待更早传送的帧都到达就将帧传给下一个协议。我们可以提出的一个问题是：我们是否确实需要滑动窗口协议来保持帧的顺序，或者，这样的功能在链路层是否是不必要的。不幸的是，我们还没有看到足够多的网络体系结构来回答这个问题我们首先需要理解的是，点到点链路序列如何由交换机连接而形成一条端到端的路径。
滑动窗口算法的第三个功能是，它有时支持流量控制（f l o w c o n t ro l），它是一种接收方能够控制发送方使其降低速度的反馈机制。这种机制用于抑制发送方发送速度过快，即抑制传输比接收方所能处理的更多的数据。这通常通过扩展滑动窗口协议完成，使接收方不仅确认收到的帧，而且通知发送方它还可接收多少帧。可接收的帧数对应着接收方空闲的缓冲区数。在按序传递的情况下，在将流量控制并入滑动窗口协议之前，我们应该确信流量控制在链路层是必要的。
尚未讨论的一个重要概念是系统设计原理，我们称其为相关性分离（separation of concerns）。即，你必须小心区别有时交织在一种机制中的不同功能，并且你必须确定每一个功能是必要的，而且是被最有效的方式支持的。在这种特定的情况下，可靠传输、按序传输和流量控制有时组合在一个滑动窗口协议里，我们应该问问自己，在链路层这样做是否正确。带着这样的疑问，我们将在第3章（说明X. 2 5网如何用它实现跳到跳的流量控制）和第5章（描述T C P如何用它实现可靠的字节流信道）重新考虑滑动窗口算法。
课程设计报告滑动窗口 协议仿真 公司内部档案编码：[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.基本原理 窗口机制
滁州学院 课程设计报告 课程名称：计算机网络 设计题目：滑动窗口协议仿真 系别：计算机与信息工程学院 专业：计算机科学与技术 组别：第五组 起止日期: 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的滑动窗口机制 TCP这个协议是网络中使用的比较广泛，他是一个面向连接的可靠的传输协议。既然是一个可靠的传输协议就需要对数据进行确认。TCP协议里窗口机制有2种一种是固定的窗口大小。一种是滑动的窗口。这个窗口大小就是我们一次传输几个数据。 我们可以看下面一张图来分析一下固定窗口大小有什么问题。 这里我们可以看到假设窗口的大小是1，也是就每次只能发送一个数据只有接受方对这个数据进行确认了以后才能发送第2个数据。我们可以看到发送方每发送一个数据接受方就要给发送方一个ACK对这个数据进行确认。只有接受到了这个确认数据以后发送方才能传输下个数据。 这样我们考虑一下如果说窗口过小，那么当传输比较大的数据的时候需要不停的对数据进行确认，这个时候就会造成很大的延迟。如果说窗口的大小定义的过大。我们假设发送方一次发送100个数据。但是接收方只能处理50个数据。这样每次都会只对这50个数据进行确认。发送方下一次还是发送100个数据，但是接受方还是只能处理50个数据。这样就避免了不必要的数据来拥塞我们的链路。所以我们就引入了滑动窗口机制，窗口的大小并不是固定的而是根据我们之间的链路的带宽的大小，这个时候链路是否拥护塞。接受方是否能处理这么多数据了。 我们看看滑动窗口是如何工作的。我们看下面几张图。
首先是第一次发送数据这个时候的窗口大小是根据链路带宽的大小来决定的。我们假设这个时候窗口的大小是3。这个时候接受方收到数据以后会对数据进行确认告诉发送方我下次希望手到的是数据是多少。这里我们看到接收方发送的ACK=3。这个时候发送方收到这个数据以后就知道我第一次发送的3个数据对方只收到了2个。就知道第3个数据对方没有收到。下次在发送的时候就从第3 个数据开始发。这个时候窗口大小就变成了2 。 这个时候发送方发送2个数据。
滑动窗口协议分析与实现 目录 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++语言编写一个滑动窗口协议的程序。 要求该程序实现滑动窗口协议的基本功能功能，如：发送帧被接收与否的判断，帧超时重发，帧缓存等。同时需要设计一个测试机制，以检测该程序的正确性、可靠性。
1. 滑动窗口算法 -------------------------------------------------------------------------------- 滑动窗口算法工作过程如下。首先，发送方为每1帧赋一个序号（sequence number），记作S e q N u m 。现在，让我们忽略S e q N u m是由有限大小的头部字段实现的事实，而假设它能无限增大。发送方维护3个变量：发送窗口大小（send window size），记作S W S ，给出发送方能够发 送但未确认的帧数的上界；L A R 表示最近收到的确认帧（last acknowledgement re c e i v e d）的序号；L F S 表示最近发送的帧（last frame sent）的序号，发送方还维持如下的不变式：LAR-LFR≤RWS 当一个确认到达时，发送方向右移动L A R，从而允许发送方发送另一帧。同时，发送方为所发的每个帧设置一个定时器，如果定时器在A C K到达之前超时，则重发此帧。注意：发送方必须存储最多S W S个帧，因为在它们得到确认之前必须准备重发。 接收方维护下面3个变量：接收窗口大小（receive window size），记为RW S，给出接收方所能接收的无序帧数目的上界；L A F表示可接收帧（l a rgest acceptable frame）的序号；L F R表示最近收到的帧（last frame re c e i v e d）的序号。接收方也维持如下不变式： LFS-LAR≤SWS
当一个具有顺序号S e q N u m的帧到达时，接收方采取如下行动：如果S e q N u m≤L F R 或S e q N u m > L A F，那么帧不在接收窗口内，于是被丢弃；如果L F R＜Se q N u m≤L A F，那么帧在接收窗口内，于是被接收。现在接收方需要决定是否发送一个A C K。设S e q N u m To A C K表示未被确认帧的最大序号，则序号小于或等于S e q N u m To A c k的帧都已收到。即使已经收到更高序号的分组，接收方仍确认S e q N u m To A c k的接收。这种确认被称为是累积的（c u m u l a t i v e）。然后它设置L F R = S e q N u m To A c k，并调整L A F = L F R + RW S。例如，假设L F R= 5（即，上次接收方发送的A C K是为了确认顺序号5的），并且RWS = 4。这意味着L A F = 9。如果帧7和8到达，则存储它们，因为它们在接收窗口内。然而并不需要发送A C K，因为帧6还没有到达。帧7和8被称为是错序到达的。（从技术上讲，接收方可以在帧7和8到达时重发帧5的A C K。）如果帧6当时到达了（或许它在第一次丢失后又重发从而晚到，或许它只是被延迟了），接收方确认帧8，L F R置为8，L A F置为1 2。如果实际上帧6丢失了，则出现发送方超时，重发帧6。我们看到，当发生超时时，传输数据量减少，这是因为发送方在帧6确认之前不能向前移动窗口。这意味着分组丢失时，此方案将不再保证管道满载。注意：分组丢失时间越长，这个问题越严重。注意，在这个例子中，接收方可以在帧7刚一到达时就为帧6发送一个认帧N A K（negative acknowl edgment）。然而，由于发送方的超时机制足以发现这种情况，发送N A K反而为发送方增加了复杂性，因此不必这样做。正如我们已提到的，当帧7和8到达时为帧5发送一个额外的A C K是合理的；在某些情况下，发送方可以使用重复的A C K作为一个帧丢失的线索。这两种方法都允许早期的分组丢失检测，有助于改进性能。 关于这个方案的另一个变种是使用选择确认（selective acknowledgements）。即，接收方能够准确地确认那些已收到的帧，而不只是确认按顺序收到最高序号的帧。因此，在上例中，接收方能够确认帧7、8的接收。如果给发送方更多的信息，就能使其较容易地保持管道满载，但增加了实现的复杂性。 发送窗口大小是根据一段给定时间内链路上有多少待确认的帧来选择的；对于一个给定的延迟与带宽的乘积，S W S是容易计算的。另一方面，接收方可以将RW S设置为任何想要的值。通常的两种设置是：RW S= 1，表示接收方不存储任何错序到达的帧；RW S=S W S，表示接收方能够缓存发送方传输的任何帧。由于错序到达的帧的数目不可能超过S W S个，所以设置RWS >S W S没有意义。 2. 有限顺序号和滑动窗口 -------------------------------------------------------------------------------- 现在我们再来讨论算法中做过的一个简化，即假设序号是可以无限增大的。当然，实际上是在一个有限的头部字段中说明一个帧的序号。例如，一个3比特字段意味着有8个可用序号0 ~ 7。因此序号必须可重用，或者说序号能回绕。这就带来了一个问题：要能够区别同一序号的不同次发送实例，这意味着可用序号的数目必须大于所允许的待确认帧的数目。例如，停止等待算法允许一次有1个待确认帧，并有2个不同的序号。 假设序号空间中的序号数比待确认的帧数大1，即S W S ≤M A a x S e q N u m -1 ，其中M a x Seq N u m 是可用序号数。这就够了吗？答案取决于RW S 。如果RW S = 1，那么MaxSeqNum≥SWS+1是足够了。如果RW S等于S W S，那么有一个只比发送窗口尺寸大1的M a x S e q N u m是不够的。为看清这一点，考虑有8个序号0 ~ 7的情况，并且S W S = RW S = 7。假设发送方传输帧0 ~ 6，并且接收方成功接收，但A C K丢失。接收方现在希望接收帧7，0 ~ 5，但发送方超时，然后发送帧0 ~ 6。不幸的是，接收方期待的是第二次的帧0 ~ 5，得到的却是第一次的帧0 ~ 5。这正是我们想避免的情况。
滁州学院 课程设计报告 课程名称: 计算机网络 第五组 起止日期：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使用的一种流量控制方法。该协议允许发送方在停止并等待确认前可以连续发送多个分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输。 只有在接收窗口向前滑动时（与此同时也发送了确认），发送窗口才有可能向前滑动。 收发两端的窗口按照以上规律不断地向前滑动，因此这种协议又称为滑动窗口协议。 当发送窗口和接收窗口的大小都等于 1时，就是停止等待协议。 当发送窗口大于1，接收窗口等于1时，就是回退N步协议。 当发送窗口和接收窗口的大小均大于1时，就是选择重发协议。 协议中规定，对于窗口内未经确认的分组需要重传。这种分组的数量最多可以等于发送窗口的大小，即滑动窗口的大小n减去1（因为发送窗口不可能大于（n-1），起码接收窗口要大于等于1）。 工作原理 TCP协议在工作时，如果发送端的TCP协议软件每传输一个数据分组后，必须等待接收端的确认才能够发送下一个分组，由于网络传输的时延，将有大量时间被用于等待确认，导致传输效率低下。为此TCP在进行数据传输时使用了滑动窗口机制。 TCP滑动窗口用来暂存两台计算机问要传送的数据分组。每台运行TCP协议的计算机有两个滑动窗口：一个用于数据发送，另一个用于数据接收。发送端待发数据分组在缓冲区排队等待送出。被滑动窗口框入的分组，是可以在未收到接收确认的情况下最多送出的部分。滑动窗口左端标志X的分组，是已经被接收端确认收到的分组。随着新的确认到来，窗口不断向右滑动。 TCP协议软件依靠滑动窗口机制解决传输效率和流量控制问题。它可以在收到确认信息之前发送多个数据分组。这种机制使得网络通信处于忙碌状态，提高了整个网络的吞吐率，它还解决了端到端的通信流量控制问题，允许接收端在拥有容纳足够数据的缓冲之前对传输进行限制。在实际运行中，TCP滑动窗口的大小是可以随时调整的。收发端TCP协议软件在进行分组确认通信时，还交换滑动窗口控制信息，使得双方滑动窗口大小可以根据需要动态变化，达到在提高数据传输效率的同时，防止拥塞的发生。称窗口左边沿向右边沿靠近为窗口合拢，这种现象发生在数据被发送和确认时。 当窗口右边沿向右移动时将允许发送更多的数据，称之为窗口张开。这种现象发生在另一端的接收进程读取已经确认的数据并释放了TCP的接收缓存时。当右边沿向左移动时，称为窗口收缩。Host Requirements RFC强烈建议不要使用这种方式。但TCP必须能够在某一端产生这种情况时进行处理。 如果左边沿到达右边沿，则称其为一个零窗口。 注意事项 （1）发送方不必发送一个全窗口大小的数据。（2）来自接收方的一个报文段确认数据并把窗口向右边滑动，这是因为窗口的大小事相对于确认序号的。（3）窗口的大小可以减小，但是窗口的右边沿却不能够向左移动。（4）接收方在发送一个ACK前不必等待窗口被填满。 滑动窗口 滑动窗口(Sliding window )是一种流量控制技术。早期的网络通信中,通信双方不会考虑网
计算机网络课程设计书
计算机网络课程设计说明书 （封面） 学院名称：计算机与信息工程学院班级名称：网络工程一班 学生： 学号： 201321 题目：滑动窗口协议仿真指导教师 姓名：邵雪梅 起止日期： 2015.6.23－2015.6.29
第一部分：正文部分 一，选题背景 早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道网络拥塞状况，一起发送数据，导致中间结点阻塞掉包，谁也发不了数据。在数据传输过程中，我们总是希望数据传输的更快一些，但如果发送方把数据发送的过快，接收方就可能来不及接收，这就造成数据的丢失。因此就有了滑动窗口机制来解决这些问题。早期我们使用的是1bit滑动窗口协议，一次只发送一个帧，等收到ack确认才发下一个帧，这样对信道的利用率太低了。因此提出了一种采用累积确认的连续ARQ协议，接收方不必对收到的帧逐个发送ack确认，而是收到几个帧后，对按序到达的最后一个帧发送ack确认。 同1bit滑动窗口协议相比，大大减少了ack数量，并消除了延迟ack对传输效率的影响。但是，这会产生一个新的问题，如果发送方发送了5个帧，而中间的第3个帧丢失了。这时接收方只能对前2个帧发出确认。发送方无法知道后面三个帧的下落，只好把后面的3个帧再重传一次，这就是回退N协议。为了解决这个问题，又提出了选择重传协议。当接收方发现某帧出错后，继续接受后面送来的正确的帧，只是不交付它们，存放在自己的缓冲区中，并且要求发送方重传出错的那一帧。一旦收到重传来的帧后，就可以将存于缓冲区中的其余帧一并按正确的顺序递交给主机。本文主要介绍如何根据滑动窗口协议的原理，在Visual C++的平台上设计一个滑动窗口协议模拟程序，并最终使该程序得以实现。本次程序设计分两部分：第一部分是发送方，第二部分是接收方。通过发送方和接收方之间的数据帧传输模拟，学习滑动窗口协议控制流量的原理和方法，以及滑动窗口协议的工作机制。
滑动窗口实验报告（含源码） 一、实验目的 1.实现一个数据链路层协议的数据传送部分。 2.更好地理解数据链路层协议中的“滑动窗口”技术的基本工作 原理。 3.掌握计算机网络协议的基本实现技术。 二、实验要求 在一个数据链路层的模拟实现环境中，用C语言实现下两个数据链路层协议。 1.1比特滑动窗口协议 2.回退N帧滑动窗口协议 三、实验内容 充分理解滑动窗口协议，根据滑动窗口协议，模拟滑动窗口协议中发送端的功能，对系统发送的帧进行缓存并加入窗口等待确认，并在超时或者错误时对部分帧进行重传。 编写停等及退回N滑动窗口协议函数，响应系统的发送请求、接收帧消息以及超时消息，并根据滑动窗口协议进行相应处理。四、源代码及注释 #include "" #include
buffer[last_buffered_frame % BUFFER_SIZE].size = bufferSize; ize); continue; SendFRAMEPacket((unsigned char*)(&buffer[i % BUFFER_SIZE]), buffer[i % BUFFER_SIZE].size); } return 0; } default : break; } return -1; } /* * 回退n帧测试函数 */ int stud_slide_window_back_n_frame(char *pBuffer, int bufferSize, UINT8 messageType) { Frame_head* p = (Frame_head*)pBuffer; unsigned int timeoutNum = *(unsigned int*)pBuffer; switch (messageType) { ead = *p; buffer[last_buffered_frame % BUFFER_SIZE].size = bufferSize; ++ last_buffered_frame; cout << "exp_ack : " << exp_ack << endl; if (ack >= exp_ack) { ++ expect_frame; if (next_frame < last_buffered_frame) { SendFRAMEPacket((unsigned char*)(&buffer[next_frame % BUFFER_SIZE]), buffer[next_frame % BUFFER_SIZE].size); ++ next_frame; } } else break; } return 0;
长沙理工大学 《网络协议编程》课程设计报告 梁碧莹 学院计算机与通信工程专业网络工程 班级网络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
课程设计报告滑动窗口 协议仿真精编 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 滑动窗口协议 详解 滑动窗口机制 (1).窗口机制 滑动窗口协议的基本原理就是在任意时刻，发送方都维持了一个连续的允许发送的帧的序号，称为发送窗口；同时，接收方也维持了一个连续的允许接收的帧的序号，称为接收窗口。发送窗口和接收窗口的序号的上下界不一定要一样，甚至大小也可以不同。不同的滑动窗口协议窗口大小一般不同。发送方窗口内的序列号代表了那些已经被发送，但是还没有被确认的帧，或者是那些可以被发送的帧。下面举一个例子（假设发送窗口尺寸为2，接收窗口尺寸为1）： 分析：①初始态，发送方没有帧发出，发送窗口前后沿相重合。接收方0号窗口打开，等待接收0号帧；②发送方打开0号窗口，表示已发出0帧但尚确认返回信息。此时接收窗口状态不变；③发送方打开0、1号窗口，表示0、1号帧均在等待确认之列。至此，发送方打开的窗口数已达规定限度，在未收到新的确认返回帧之前，发送方将暂停发送新的数据帧。接收窗口此时状态仍未变；④接收方已收到0号帧，0号窗口关闭，1号窗口打开，表示准备接收1号帧。此时发送窗口状态不变；⑤发送方收到接收方发来的0号帧确认返回信息，关闭0号窗口，表示从重发表中删除0号帧。此时接收窗口状态仍不变；⑥发送方继续发送2号帧，2号窗口打开，表示2号帧也纳入待确认之列。至此，发送方打开的窗口又已达规定限度，在未收到新的确认返回帧之前，发送方将暂停发送新的数据帧，此时接收窗口状态仍不变；⑦接收方已收到1号帧，1号窗口关闭，2号窗口打开，表示准备接收2号帧。此时发送窗口状态不变；⑧发送方收到接收方发来的1号帧收毕的确认信息，关闭1号窗口，表示从重发表中删除1号帧。此时接收窗口状态仍不变。 若从滑动窗口的观点来统一看待1比特滑动窗口、后退n及选择重传三种协议，它们的差别仅在于各自窗口尺寸的大小不同而已。1比特滑动窗口协议：发送窗口=1，接收窗口=1；后退n协议：发窗口>1，接收
ARQ与滑动窗口概念 滑动窗口协议，是TCP使用的一种流量控制方法。该协议允许发送方在停止并等待确认前可以连续发送多个分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输。 自动重传请求（Automatic Repeat-reQuest，ARQ）是OSI模型中数据链路层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。ARQ可能包括停止等待ARQ协议、回退ARQ和连续ARQ协议，错误检测（Error Detection）、正面确认（Positive Acknowledgment）、超时重传（Retransmission after Timeout）和负面确认及重传（Negative Acknowledgment and Retransmission）等机制。 他们的概念是差不多的只是作用于不同的网络层。数据链路层的滑动窗口是“个数固定”的。而TCP的滑动窗口是“个数可变”的，可以由接收端设置WIN字段来修改。 传统自动重传请求分成为三种，即停等式(stop-and-wait）ARQ，回退n帧（Go-back-n）ARQ，以及选择性重传（selective repeat）ARQ。后两种协议是滑动窗口技术与请求重发技术的结合，由于窗口尺寸开到足够大时，帧在线路上可以连续地流动，因此又称其为连续ARQ协议。三者的区别在于对于出错的数据报文的处理机制不同。三种ARQ协议中，复杂性递增，效率也递增。除了传统的ARQ，还有混合ARQ（Hybrid-ARQ）。 当发送窗口和接收窗口的大小都等于1时，就是停止等待协议。 当发送窗口大于1，接收窗口等于1时，就是回退N步协议。 当发送窗口和接收窗口的大小均大于1时，就是选择重发协议
滑动窗口算法 1. 滑动窗口算法 滑动窗口算法工作过程如下。首先，发送方为每1帧赋一个序号（sequence number），记作S e q N u m。现在，让我们忽略S e q N u m 是由有限大小的头部字段实现的事实，而假设它能无限增大。发送方维护3个变量：发送窗口大小（send window size），记作S W S，给出发送方已经发 送但未确认的帧数的上界；L A R表示最近收到的确认帧（last acknowledgement re c e i v e d）的序号；L F S表示最近发送的帧（last frame sent）的序号，发送方还维持如下的不变式： LAR-LFR≤RWS 当一个确认到达时，发送方向右移动L A R，从而允许发送方发送另一帧。同时，发送方为所发的每个帧设置一个定时器，如果定时器在A C K到达之前超时，则重发此帧。注意：发送方必须存储最多S W S个帧，因为在它们得到确认之前必须准备重发。 接收方维护下面3个变量：接收窗口大小（receive window size），记为RW S/* 对应允许接受的数据包*/，给出接收方所能接收的无序帧数目的上界；L A F表示可接收帧（largest acceptable frame）的序号；L F R表示最近收到的帧（last frame re c e i v e d）的序号。接收方也维持如下不变式： LFS-LAR≤SWS (NFE为等待下一帧的序号) 当一个具有顺序号S e q N u m的帧到达时，接收方采取如下行动：如果S e q N u m≤L F R或S e q N u m > L A F，那么帧不在接收窗口内，于是被丢弃；如果L F R＜Se q N u m≤L A F，那么帧在接收窗口内，于是被接收。现在接收方需要决定是否发送一个A C K。设SeqNumToACK表示未被确认帧的最大序号，则序号小于或等于SeqNumToACK的帧都已收到。即使已经收到更高序号的分组，接收方仍确认SeqNumToACK的接收。这种确认被称为是累积的（c u m u l a t i v e）。然后它设置L F R = S e q N u m To A c k，并调整L A F = L F R + RW S。例如，假设L F R= 5（即，上次接收方发送的A C K是为了确认顺序号5的），并且RWS = 4。这意味着L A F = 9。如果帧7和8到达，则存储它们，因为它们在接收窗口内。然而并不需要发送A C K，因为帧6还没有到达。帧7和8被称为是错序到达的。（从技术上讲，接收方可以在帧7和8到达时重发帧5的A C K。）如果帧6当时到达了（或许它在第一次丢失后又重发从而晚到，或许它只是被延迟了），接收方确认帧8，L F R置为8，L A F置为1 2。如果实际上帧6丢失了，则出现发送方超时，重发帧6。我们看到，当发生超时时，传输数据量减少，这是因为发送方在帧6确认之前不能向前移动窗口。这意味着分组丢失时，此方案将不再保证管道满载。注意：分组丢失时间越长，这个问题越严重。
计算机网络原理一位滑动窗口协议 一位滑动窗口协议是指发送窗口和接收窗口尺寸都是1。也就是说发送端在未接收到确认前只能发1数据帧；接收方也只能接收落在当前窗口内的1数据帧，并给出确认数据帧。停-等协议就属于1位滑动窗口协议，但它只适用于数据单向传输，向反方向发送确认数据帧的情况。而1位滑动窗口协议支持数据的双向传输，即支持双工通信。 在实际的双工通信中，是在数据帧中增加一个字段，用来携带给对方的应答信息。这种将应答信息搭载在数据帧上发送给对方的应答方式称为捎带应答。采取捎带应答的全双工通信的工作过程，是由通信双方的某一方首先开始发送数据，它从网络层获得一个分组，将该分组封装成帧，通过物理层发送出去。接收方收到后检查是否有错和重复，如果有错或重复就丢弃；如果无错就交给网络层。然后查看有无数据帧要发送，如果有就将应答信息捎带在数据帧上发送出去，如果没有就发一个独立的确认帧。发送方收到应答数据帧后，检验对方发来的数据帧，如果无误上交给网络层，在确认自己发送的上一帧已经被妥收后，准备发送下一帧，并将对对方数据帧的应答信息搭载在上面，一起发送给对方。图4-4给出了一位滑动窗口协议的工作情况。 发 01A0收 01A0 收 01A0 发 00B0 发 10A1收 10A1 收 11B1 发 11B1 发 01A2收 01A2 收 00B2发 00B2 发 10A3收 10A3 图4-4 一位滑动窗口协议的工作情况 在正常情况下，通过检查所接收的数据帧的发送序号，判定是否是重复帧，如果是重复帧就丢弃，否则就接收下来；通过检查应答序号，可以判定上次所发的帧是否被正确接收，如果未得到应答，就要超时重发。