对于数据链路层滑动窗口协议中窗口大小的总结

本文是学习《计算机网络》一书3.4节的一些总结，主要关注窗口大小限制的由来。若要浏览此文，请保证你已了解滑动窗口协议中的基本机制，在这里推荐一篇博客：https://blog.csdn.net/do_best_/article/details/79771841

3.4节中介绍了三种滑动窗口协议：1位滑动窗口协议、GBN协议、SR协议。1位滑动窗口协议本质上就是一种全双工的停等式协议，它的发送窗口和接收窗口大小都是1，在此不做赘述，我主要分析后两种协议的窗口大小。

在SR协议中，窗口大小默认满足如下两个基本条件：
发送窗口大小 = 接收窗口大小
发送窗口大小 + 接收窗口大小 <= 2^n

由此我们可以推得：发送(或接收)窗口大小 <= 2^(n-1)

问题一 : 发送窗口大于接收窗口会发生什么情况?

如果你做过一些计网的题目，你可能会发现发送窗口大于或小于接收窗口大小情况。实际上这两种情况并不会导致SR协议出错，只是效率不高而已。发送窗口小于接收窗口的情况我们就不谈了，因为这显然是一种浪费，我主要讨论发送窗口大于接收窗口时的情况。

我们假设帧序号采用3bit表示，那么帧序号为 0, 1, 2, 3, 4, 5, 6, 7。
令发送窗口为5，接收窗口为3，采用SR(选择重传)协议时的过程如下：

首先发送方一次性连续发送了 0,1,2,3,4 帧序号的比特流 , 因为接收方的接收窗口为3 , 那么在0,1,2号帧正确无误的被接收方接收后,接收方向上交付0,1,2号帧 . 3,4号帧虽然被正确接收,但接收方现在还未将接收到的0,1,2号帧向上交付,并发回ack(n)的确认收到信息（比如协议使用了捎带确认，但短时间内没有反向流量，辅助计时器也没超时的情况）,多余的3,4号帧将被抛弃,只有在接收方发回确认信息后,接收窗口才会向后移动, 接收方下一个窗口便才会期待3,4,5 号帧 .因此早到的帧会被抛弃. 那么发送方迟迟收不到3,4号帧的ack3,ack4 .只收到ack0,ack1,ack2 , 因此发送方的计时器超时后接收方才会再次发送3,4号帧,这时候接收方才能正确接收. 这样的配合方式使得每个周期都会有数据超时重传,因此传输效率是低下的,也是没必要的。

综上，我们不如直接令发送窗口大小 = 接收窗口大小。

问题二: 如果发送窗口大小为5,接收窗口大小为5 (即发送窗口+接收窗口>2^n)会发生什么情况?

假设帧序号采用3bit表示，发送窗口大小为5，接收窗口大小为5，发送方一次性发送0,1,2,3,4号帧的比特流。

情况1: 在没有差错发生的情况下(此处差错考虑帧差错的帧丢失) : 发送方发送的所有数据都被正确接收了 , 并且接收方所有确认数据都正常接收到了.那么这种情况将一个周期一个周期的循环下去。

情况2: 发送方发送了0-4号帧,接收方正确接收,但是接收方的回复的所有确认收到信息全部丢失 , 发送方以为自己的数据发送失败,即没有到达接收方,因为如果到达了接收方即使发生了帧差错,接收方也会返回NAK(n)的回复信息 , 那么在计时器超时后发送方再次发送在缓存中的0-4号旧帧,那么接收方因为正确之前已经正确接收到0-4号帧后,它的接收窗口已经向后移动,此时接收窗口期望的是5,6,7,0号帧 . 当接收方再次接收到0-4号帧时,他并不能区别此时的0号帧是旧帧还是新帧,实际上是我们知道是旧帧,但是接收方接收到此0号帧了,它只能以为是新帧.那么此时就造成了帧重复的差错了。

这时再来看GBN协议对于窗口大小的限制就很好理解了。在GBN协议中，接收窗口大小固定为1，但依然存在发送窗口大小 + 接收窗口大小 <= 2^n 这个条件，其原因和问题二的情况二类似，所以最终我们可以得知发送(或接收)窗口大小 <= 2^n-1

参考内容：https://zhidao.baidu.com/question/432120567493536524.html