计算机网络滑动窗口协议

注：此文档仅用于学习记录，部分内容引用于王道考研的视频课

一、滑动窗口协议分类

滑动窗口协议主要分为以下三类：停止等待协议（Stop-and-Wait ARQ）、后退N帧协议（Go-Back-N ARQ）和选择性重传协议（Selective Repeat ARQ）‌‌。

‌停止等待协议（Stop-and-Wait ARQ）‌：这是最简单的滑动窗口协议形式，窗口大小固定为1。发送方发送一个数据帧后，停止发送并等待接收方的确认帧（ACK）。如果在规定时间内收到ACK，发送方继续发送下一个数据帧；若超时未收到ACK，则重发该数据帧。这种协议的优点是简单易实现，但缺点是信道利用率低，因为发送方在等待确认的过程中处于空闲状态‌。

‌后退N帧协议（Go-Back-N ARQ）‌：该协议的发送窗口大小大于1，接收窗口大小仍为1。发送方可以连续发送多个数据帧，而不需要等待每个帧的确认。接收方按顺序接收数据帧，如果收到一个正确的帧，就发送一个确认帧给发送方。如果某个帧丢失或出错，接收方会等待后续的帧，直到收到一个序号不正确的帧时，才发送一个针对最后一个正确接收帧的确认帧。这种协议提高了信道利用率，但在信道误码率高的情况下，可能会导致发送方的发送进度经常需要后退，传输效率低下‌。

‌选择性重传协议（Selective Repeat ARQ）‌：在这种协议中，每个数据帧发出时都设置一个计时器。如果某个数据帧未收到确认，计时器超时后重传该数据帧。如果接收方检测到错误，会发送否认帧（NAK）给发送方，发送方收到NAK后重传对应的数据帧。这种协议允许发送方只重传丢失或出错的数据帧，而不是整个窗口内的数据帧，提高了传输的可靠性‌。

注意：上述的三种协议目前没有明确规定用于计算机网络的哪一层中，由于教材的更新，实际上三种ARQ可以作用于数据链路层也可以作用于传输层，如果作用于链路层，那么发送的数据就是帧；如果说作用于传输层，那么发送的数据就是数据报，此时滑动窗口协议在教材中还有另一种说法：TCP流量控制、拥塞控制。
本文的二、三、四章节主要针对链路层的实现，对于传输层的概念集中于五、六两章节讲解！

二、停止等待协议

顾名思义，发送发 发送了一帧数据后，必须等到接收方接受到信息，并返回一个ack确认帧后才能再次发送第二帧，可以将停止等待协议看成一个特殊的，发送方和接收方的窗口大小都是1的滑动窗口协议。
1.停等协议无差错情况

这边为什么需要1bit来编号，而且为什么1位就足够呢？可以不编号吗？带着这些疑问往下看，当出现差错的情况下怎么办？

2.发送方出现差错

发送方发送1帧后，在RTT时间内没有收到确认帧，那么就会触发超时重传，这里有两点需要注意的：
(1)由于需要触发超时重传，所以每次发送帧的时候都需要保存当前帧的一个副本
(2)数据帧和确认帧需要编号，这个就是上一小节的疑问点了，为什么要编号很好理解，因为接收方如果收到了相同的帧序号，就说明这是一个重复帧，那么会丢弃上一帧，如果不编号，那么发送方不知道接收方你给我的确认帧是哪一帧的，接收方也不知道你发送的帧是不是重复帧，就会出现数据传输不可靠

那为什么用1位就可以呢？其实答案和上述的一样，1位bit可以表示0和1。我们模拟一下场景：
发送方：发送0帧。接收方：收到0帧，发送ACK=0
发送方：收到ACK=0，发送1帧。接收方：收到1帧，但是接收方检测到这个帧有问题，那好，我不给发送方确认信息了，因为这个帧有问题
发送方：RTT超时重传，没有收到ACK=1，说明需要重传1号帧，而不是0号帧。接收方：收到了1号帧的重传，因为帧编码是1，所以明确知道这个重传的是哪一个帧。
所以1位bit位就足够了（本质原因还是停等协议窗口大小就=1），那么有同学会问？2位3位更多位可以吗？当然可以，只是没必要浪费存储空间

3.接收方出现差错
接收方出现差错即ACK丢失，和2小节的概念其实也差不多很好理解，发送方超时重传了1帧，然后接收方收到了1帧，由于帧已经编号了，所以知道这个帧是要覆盖掉原来的帧，这里也可以解释为什么要对帧编号的理由。

4.ACK延迟

以上图为例，发送方发了0帧后，接收方发送的ACK=0在网络上太慢了，这时候发送方启动了超时重传，重新发送0帧，这时候接收方收到后 丢弃重复的0帧，重新发第二个ACK=0，并且这时候网速正常，接收方也收到了ACK=0，并且开始发送1帧，但发送完1帧后，接收方才收到了最早的第一个ACK=0的信息，这时候发送方就要对这个信息丢弃，那么接收方怎么知道这个ACK信息不是刚才发的1帧的ACK呢？很简单因为编码了呀！ACK=0，这里同样也可以解释为什么要对帧编码

5.停等协议性能分析

TD、TA表示的这一帧从第0bit开始发送，到最后一位bit发送结束的时间（发送n位bit的事件），也叫发送时延
RTT表示往返时延
相关例题：

题干分析：4kb/s就是发送bit速度，单向传播时延是30ms，那么RTT往返就是60ms，由于停等协议确认帧只有1位，我们忽略不计确认帧的发送时延，那么假设数据帧长度为x，根据公式可以得出x=960

三、后退N帧协议

为了应对停等协议的信道利用率低的情况，就有了后退N帧协议，此协议也是基于流水线的进一步优化。
后退N帧协议中发送窗口一般都是大于1，接受窗口固定为1。我们以图片形式来简单描述一下GBN协议的基本流程
1.我们假设窗口大小是6，窗口中0，1，2三个帧开始发送

2.上图中，其中0号帧接收到数据了，接收方窗口开始移动一位，如下图所示

3.上图中，其中1号帧接到到数据了，接收方窗口继续移动一位，如下图所示

4.上图中，其中2号帧也收到数据了，接收方窗口继续移动一位，且这一段的数据都接受成功了，所以发送一个ACK=2，表明我0,1,2三个帧都收到了，此时发送方开始移动窗口，知道前面三个帧已经完事了，如下图所示

至此GBN的基本逻辑讲解完毕，可以看到，GBN采用了滑动窗口协议，相比较于停等协议，接收端采用了累计确认的方式，帧0发送的时候，帧1帧2等都能继续发送，不需要等到帧0的ACK码后再发送，接收端收到一组信息后会发送一个ACK=N的确认信息，表示N编号及之前的帧我都确认无误收到了。
使用累计确认的好处：
1.即使确认分组丢失，发送方也可能不必重传，比如累计确认返回了ACK=3，然后又返回了ACK=6，但ACK=3在返回过程中丢失了，发送方只收到了ACK=6，但也不影响后续的传输，数据还是可靠的。
2.减少接收方的开销。
使用累计确认的坏处：
1.不能及时的和发送方确认帧丢失情况

当然上述只是理想情况，既然是GBA回退N帧协议，那么我们看下当出现传输异常的时候，是怎么做回退N帧的呢？

GBN重传

我们来看下如果在传输过程中出现了差错，那么GBN协议是如何进行重传，且如何保证重传数据是可靠的呢？我们看如下例子，这里就不采用累计重传的方式，主要是方便理解。
如上图所示，发送窗口为4，当0和1帧发送，并且收到了ACK0和ACK1的时候，发送窗口移动两格，这时候4和5帧开始发送，2号帧在传输过程中丢失，导致3号帧先到达，由于接收窗口只接受2号帧，和3号不匹配，所以立马发送ACK=1，表示0和1号帧是正确的，同时4和5号帧也达到了，同样和2号帧不匹配，也发送ACK=1，这里就要具体细分：
(a)有些网络结构定义同时接受了多次ACK=N时，直接触发重传，重发N+1号帧及后面已发送的所有帧。
(b)不触发重传，等到2号帧触发了超时后（一直没有收到ACK=2），对所有已发送的帧全部重发。

GBN窗口大小

假设对帧编码为n位，即帧的编码范围是[0,2ⁿ-1]，即如果n=3，编码范围就是0-7，那么发送窗口大小范围限定在[1,2ⁿ-1]，接收窗口大小固定=1，为什么发送窗口要这么限制呢？我们假设发送窗口大小为8，我们看如下异常，假设0-7帧（一共8个）全部发送，接收方收到之后返回一个ACK=7，同时窗口向后移动了7位，但ACK=7在返回过程中丢失了，所以发送方触发超时重传机制，对0-7帧全部重传，重传之后的数据对于接收方来说，这个数据并不知道是新的一组数据还是重复数据，所以会出现真实的数据中会出现两组一模一样的包，如下图所示：

最后发送ACK=7的时候出现异常，那么发送方会对所有已发送的帧全部超时重传，重传结果如下，很明显出错了：

那窗口大小在正常范围内，怎么就不会异常了呢？我们假设：如果窗口大小为限制到7，最后发送ACK=6的时候异常了，那么发送方全部重传已发送的帧，这时候接受窗口序号=7，重传的序列是0-6，这时候会发现全部不符合，接收方就会继续返回ACK=6，直到发送窗口恢复正常，如下图所示，最终发送窗口恢复到正常范围。

相关例题：
(1)

分析：发送方只收到了0,2,3帧的确认，根据累计重传原则：ACK=3表明，0,1,2,3帧全部正确接受了，4号帧发送后一直没有收到ACK，所以4,5,6,7需要重传，选择C

(2)

分析：想要达到最大平均传输率，甲窗口1000的字段需要一次性全部发出，甲发送窗口的发送时延=100010008/100M=0.08s=80ms，RTT=50*2=100ms，这两个数字什么意思呢？我们来画张图好了解了

可以看到在红色区域内的这20ms没有被利用到，这个时间段内，发送发不在发送数据，接收方返回的ACK也没有在路上，所以最大数据传输率=80%，选择C即可

(3)

分析：信道利用率要达到最高，那么我们假设利用率拉满了=100%，按照上述例题(2)的图来说，就是第一帧发送出去~最后一帧发送出去前，这个时间段内（也可以说发送时延）已经收到了第一帧的ACK码。题目中说帧的比特数至少是多少？换种说话就是支持发送最多帧，那么我们把数据帧的长度限定在最小就能算出至少，那么128字节的帧发送时间=（1288bit）/（161000bit/s）=64ms，经过RTT传播时延收到ACK的时间=64+270*2=668ms，在668ms内要确保发送方一直在发送帧，所以发送了=668/64=10.4（帧），用4位bit位即可编码。如下图所示

四、选择重传协议

上述GBN协议中，虽然相比较于停等协议效率大大提高，但是我们发现回退N帧实际上会把已经传输好的数据再次发送，难免造成了资源浪费，那么针对这个进一步优化，选择重传协议就来了，我们就只重传出错的帧
方法：设置单个确认，同时加大接收窗口，设置接收缓存，缓存乱序到达的帧

首先了解一下大致的逻辑，发送方和接收方都有两个窗口，且大于1，发送方发送一批帧后，什么时候会开始滑动发送窗口呢？我们知道GBN协议中，当收到了ACK码后（表面接收方的帧已经是有序的）会开始滑动，但是在SR协议中，我们可能会收到的ACK码是无序的，比如上图中，2,3,4帧都发送出去了，但是ACK=3优先被确认，2还是待确认，所以这时候窗口是不能动的，换句话说只有ACK=N（N是窗口的左临界点）窗口才会滑动，滑动到最小未确认帧处。
那什么时候开始滑动接收窗口呢？我们知道GBN协议中，只要发送方发送的帧和窗口中预期帧一样就滑动，不一样直接丢弃，但是SR协议中，接收窗口大小可不是1，这里分为两类情况：
(a)如果收到的帧在窗口预期内的一样，如果是左临界点，那么窗口滑动到最小未确认帧处，如果不是，窗口不动，直接缓存非左临界点的帧。
(b)如果收到的帧都不在窗口预期内，直接舍弃
按照上图所示，6号帧先被接收到了，但由于6不是左临界点，所以缓存起来，后面5号帧来了，5号帧是左临界点，那么滑动窗口开始移动，移动到最小未确认帧处，即7号帧位置

SR超时

SR协议中，每一个帧都有计时器，如果在规定时间内没有收到ACK，则会触发重传
(1)ACK码异常，导致超时重传，以下图为例，来了一个7帧（然后返回ACK=7），由于5还没收到，需要缓存起来

缓存后，5号帧也来了（然后返回ACK=5），如下图

这时候接收方窗口开始滑动，结果如下图

但是呢，上面说了，5,6,7发送的ACK码可能丢失了，所以发送方出现超时重传，所以我们可能在滑动窗口0,1,2,3的情况下，收到了小于左下界的帧(4,5,6,7，上一个窗口的帧)，这种情况下我们其实不用关心，我们只需要再次发送一个ACK即可，表明我们实际上已经收到了这个帧，只是ACK丢失了

(2)发送出现异常，导致超时重传

以上图为例开始解析，假设发送窗口和接收窗口大小都是4
(a) 发送窗口开始发送0帧，接受窗口收到0帧，并返回ACK=0，由于0帧是左下界，所以接受窗口移动到最小未确认出，现在窗口范围是1,2,3,4
(b) 发送窗口发送1帧，接受窗口收到1帧，并返回ACK=1，由于1帧是左下界，所以接收窗口移动到最小未确认出，现在窗口范围是2,3,4,5
(c ) 发送窗口开始发送2帧，但是发送过程中丢失了
(d) 发送窗口开始发送3帧，接收方收到了3帧，并返回ACK=3，但是3帧不是窗口左下界，所以窗口不能动，3帧开始缓存
(e) 最开始的ACK=0收到了，由于0是发送窗口左下界，所以发送窗口开始移动，现在发送窗口是1,2,3,4，这时候4号帧开始发送
(f) 接收到了4号帧，由于4号帧不是左下界，缓存起来，然后发送ACK=4
(g) 最开始的ACK=1收到了，由于1是发送窗口左下界，所以发送窗口开始移动，现在发送窗口是2,3,4,5，这时候5号帧开始发送
(h) 接收到了5号帧，由于5号帧不是左下界，缓存起来，然后发送ACK=5
(i) 2帧一直没有收到ACK=2，触发超时重传
(j) 接收方收到2号帧，由于2是窗口左下界，所以窗口移动，并且3,4,5都缓存起来了，所以窗口直接变成6,7,0,1，同时ACK=2返回
(k) 收到了ACK=3，由于3不是左下界，所以不动，只知道3帧对方明确收到缓存了，只有等到ACK=2收到后，才滑动窗口到6,7,0,1

SR窗口大小

以下图为例

0,1,2三个帧都收到了，窗口移动变成3,0,1，但是这ACK=0在返回过程中丢失了，发送窗口0号帧超时触发了重传，然后接收方收到了0号帧，但是这个0号帧在窗口3,0,1中被缓存起来了，也就说旧帧被当真新帧了。
结论，Wtmax=Wrmax=2^(n-1)，注意区分GBN发送窗口大小是2ⁿ-1

相关例题

(1)
分析：收到了1号帧的确认=接收方1号帧缓存，发送方1号帧确认收到，0,2超时了，所以需要重发0,2两帧，选择A。可能有人会有疑问：0-3帧一共4帧，编码位数就是2，那么窗口大小就是最大是2^2-1=2,0号帧没有收到ACK=0的情况下，2号帧不应该能发出去啊？？哈哈，问题点在于题干中没说0-3一定是完全编码好的，可能是编码位数是3位（0,1,2,3,4,5,6,7），窗口大小这时候是2^3-1=4，这样可以直接发送0-3帧。

注：选择重传是不需要累计确认的

五、TCP流量控制

此节的流量控制讲的主要是TCP的流量控制。采用的也是滑动窗口机制，但是区别在于发送窗口的大小是动态变化的。上面几节的滑动窗口机制用于数据链路层，所以窗口都是固定大小的。

概念：在通信过程中，接收方根据自己接收缓存的大小，动态的调整发送窗口大小（发送方通过接收方发送的ACK确认报文中的字段来确定发送窗口大小）。发送窗口=Min（接收窗口_rwnd，拥塞窗口_cwnd）
案例介绍：
1.首先发送方A和接收方B建立TCP连接，建立连接的时候B就已经告诉A我的接收窗口大小是多少了，然后A确认好发送窗口。这边我们以窗口4为例。

2.发送方开始发送数据，A开始给B发送seq=1的，第一组数据

3.发送方开始发送数据，A开始发送给Bseq=101，第二组数据

4.发送方开始发送数据，seq=201，但是发送途中丢失了

5.这时候B收到了前面两条报文seq=1，seq=101的数据了，开始处理数据上交上层，这里处理细节不做过多讨论，假设一个结论，处理完毕后自己的接收窗口rwnd=300，这时候需要返回给A相关数据了

如上图所示，发送ACK=1表面这是有效数据，ack=201表明201以前所有的数据已经接收到了（注意这里用的是累计确认），rwnd=300表示自己可用的缓存窗口大小

6.A收到了相关信息后，知道了我前面发送的两个报文已经确认收到了（ack=201），那么我可以窗口滑动了，但是呢，又收到了rwnd=300，所以重新滑动窗口后的样式如下图：

深蓝色表示已发送，浅色表示未发送，整体窗口大小为300

7.由于201~300的字段发送方不知道有没有丢失（超时器没有重传、也没有收到冗余ack），所以发送方继续发送301 ~400的报文

8.发送方继续发送401~500的报文

9.此时窗口所有数据已经发送完毕了，但是同时也一直没有收到ack码，所以此阶段处于等待阶段，不能再发送任何新报文

10.原先发送的seq=201的重传计时器超时，开始重传发送，记住！！这里重传了旧报文，即使发送窗口大小=0，还是可以发送的

11.B收到了seq=301和seq=401的两条报文，并返回ACK=1，ack=501的返回信息，同时自己处理缓存窗口数据，返回的rwnd=100

此时A等了半天终于收到了B来的ack码了，终于可以滑动窗口继续发新报文了，又看到了rwnd=100，所以滑动新窗口，设置新的窗口大小，如下图所示：

12.开始发送501~600的报文，我们可以看到这时候把rwnd设置成100的情况下，就是几乎是停等协议了，你发一个出去只有等到B返回了ack码才能继续发送

13.B收到seq=501，由于自己服务端很忙，自己没有额外的缓存窗口了，返回一个rwnd=0，告诉发送方你不要再发了，我这里承受不住了（笑嘻）

14.A收到rwnd=0，窗口设置为0，表示不再发送了（犹如晴天霹雳），此时A进入等待状态，一直等待B发送一个rwnd的新确认窗口大小，来告诉我什么时候可以再发了。当然了，如果B因为网络原因给你返回的rwnd丢失了，就会出现所谓的一个死锁状态：
A一直在等B发送的rwnd新窗口大小，B由于之前已经给你发送了一个非0的rwnd，一直等你重新给我发消息，出现了互相等的情况了。
所以针对上述情况，如果A收到了rwnd=0的情况，会开启一个计时器，超时后重新发送一个试探报文给B，表面我可以不可以发数据了，B返回一个当前最新rwnd，如果返回的最新rwnd还是0，那么计时器置0，重新开始新的一个循环。

注：可能大家有疑问，明明B表面了rwnd=0了，为什么还能收到探测报文呢？TCP协议规定：接收窗口即使大小为0的状态下，也需要留有空间接收探测报文等紧急报文

六、拥塞控制

拥塞控制相比较于上述的流量控制，拥塞控制是全局性的，流量控制是点对点的。在拥塞控制中就有几个非常重要的概念：拥塞窗口、慢开始、拥塞避免、快重传、快恢复
以下图为例，我们假设发送方的窗口不收接收方的接收窗口未定，仅仅限制于网络的拥塞情况决定。

慢开始和拥塞避免算法是1988年提出的（TCP tahoe）算法，现已废弃

为了进一步增加效率，1990年提出的新算法（TCP reno版本）新增了快重传与快恢复。
比如：在原先版本中，在cwnd到24的时候，由于网络出现的偶发性延迟，出发了超时重传，这种情况下容易被误判断成拥塞，为了避免这种情况，用更加准确的快重传逻辑。如下图所示快重传逻辑：M3丢失，发送M4、M5、M6的时候，都不是接收方想要的报文段，所以每次都会返回一个确认ack=M2的字段，发送方收到了这个字段就重新发送M3，从而不会错误的认为网络拥塞，导致设置了cwnd=1从而降低了网络性能效率。

我们再来看快恢复：发送方收到了接收方的3个快重传ACK就知道有报文个别丢失了，就不会认为网络拥塞了，直接快恢复即可，即发送方将慢开始门限值调整为当前窗口值的一半，然后开始拥塞避免算法

相关例题：

分析：16KB发生了超时，说明这个值是拥塞的阈值，直接开始更新cwnd=1，开始慢开始，这时候阈值=8kb，所以发送了三个RTT后就到了8，然后开始拥塞避免，第四个RTT往返就是9了，答案选择C。用人可能会问，你为什么不走快重传和快恢复呢？记住！快重传快恢复只是减少被误判断拥塞的情况罢了，题干中说了很清楚刀了16kb发生了超时，且发送的数据足够多，我们可以简单的理解成就是全局情况下的超时（而且你哪怕用快重传快恢复的逻辑来算，答案也没有你算到的啊- -。。。）

七、总结

1.滑动窗口协议不算一个协议，它本质上是一个抽象概念，滑动窗口协议在数据链路层可以具体应用到GBN回退N协议、SR选择重传协议、停等协议（特殊的滑动窗口），同时上述的三种协议又可以定义为ARQ（自动重传协议）。同时滑动窗口协议在传输层可以应用于TCP的流量控制欲拥塞避免。

2.停等协议的发送窗口和接收窗口大小都是1；GBN回退N帧协议的发送窗口大小[1,2ⁿ-1]，接受窗口大小=1；SR选择重传协议的发送窗口和接收窗口大小，Wtmax=Wrmax=2^(n-1)，n=报文序号的编码位数。

3.拥塞控制和流量控制的发送窗口大小不是固定的，区别于应用于数据链路层的滑动窗口协议。

4.快重传和快恢复主要是增加拥塞避免的效率，这俩也是绑定在一起的。