3.4节中介绍了三种滑动窗口协议:1位滑动窗口协议、GBN协议、SR协议。1位滑动窗口协议本质上就是一种全双工的停等式协议，它的发送窗口和接收窗口大小都是1，在此不做赘述，我主要分析后两种协议的窗口大小。
在SR协议中，窗口大小默认满足如下两个基本条件:
发送窗口大小= 接收窗口大小
发送窗口大小+接收窗口大小2^n
由此我们可以推得:发送(或接收)大少2^(-1)
问题一: 发送窗口大于接收窗口会发生什么情况?
如果你做过一些计网的题目，你可能会发现发送窗口大于或小于接收窗口大小情况。实际上这两种情况并不会导致SR协议出错，只是效率不高而已。发送窗口小于接收窗口的情况我们就不谈了，因为这显然是一种浪费，我主要讨论发送窗口大于接收窗口时的情况。
我们假设帧序号采用3bit表示，那么帧序号为 0,1,2,3,45,6,7。令发送窗口为5，接收窗口为3，采用SR(选择重传)协议时的过程如下:
首先发送方一次性连续发送了 0.1.2,3.4 序号的比特流，因为接收方的接收窗口为3，那么在0,1.2号正确无误的被接收方接收后,接收方向上交付0.1.2号顺，3.4号虽然被正确接收,但接收方现在还未将接收到的0,1.2号向上交付,并发回ackn)的确认收到信息比如协议使用了挡带确认，但短时间内没有反向流量，辅助计时器也没超时的情况》,多余的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)的回复信息，那么在计时器超时后发送方再次发送在缓存中的04号旧帧,那么接收方因为正确之前已经正确接收到0-4号后,它的接收窗口已经向后移动,此时接收窗口期望的是5,6.7.0号顿。当接收方再次接收到0-4号懒时,他并不能区别此时的0号帧是旧帧还是新帧,实际上是我们知道是旧帧,但是接收方接收到此0号帧了,它只能以为是新帧，那么此时就造成了倾重复的差错了。
这时再来看GBN协议对于窗口大小的限制就很好理解了。在GBN协议中，接收窗口大小固定为1，但依然存在发送窗口大小 + 接收窗口大小<= 2n 这个条件，其原因和问题二的情况二类似，所以最终我们可以得知发送(或接收)窗口大小<= 2^n-1
标签：协议,窗口,发送窗口,发送,大小,滑动,接收,链路层 From： https://www.cnblogs.com/hello-world-01/p/17279098.html