数据链路层协议窗口的计算问题

首先，我们知道数据链路层的协议常用的有三种：

• 停-等协议
• 回退N帧协议
• 选择重传协议

这三个协议的知识点除了基本的原理以外，更多的是对窗口大小的计算。

我觉得这个窗口的大小计算，不彻底弄清楚来龙去脉，每一个计算都是天书一样的，令人头大。

这三个协议，可以综合到一个大的概念中：滑动窗口。

在发送端和接收端，各维护一个窗口。窗口的大小依据协议而不同。

无论如何，有两个原则不可打破：

• 发送窗口不能大于接收窗口
• 发送窗口要能区分接收端发出的响应是当前这个轮回的还是上一个轮回的

具体到协议里面来，停等协议很简单，发送窗口 = 接收窗口 = 1.

双方就是很开心的一个一个帧的发送–接受–发送响应–发送下一帧。

而回退N帧协议和选择重传协议，牵涉到窗口大小设计的逻辑，就需要一点点思考了。

回退N帧协议里，发送窗口>1, 接收窗口 = 1.

所以回退N帧协议里，接收窗口优哉游哉的接收，但是发送端很急，因此会连续发送一堆，这样一个心急，一个不着急，两者在设计上就不在一个调上。发送方发送的一堆数据，就有可能需要在接收出错时，重新发送。
如果接收方仍然是对每一个帧进行确认，那么，假设发送方发送了10个帧，接收方一帧一帧确认，在第五帧时候认为帧出错，那么发送方就需要重发第五帧和第五帧以后的数据。这个逻辑不会错。即使在捎带确认中也是一样。

捎带确认是，确认帧可以不必对每一个发送过来的帧进行确认，可以是对当前序号以前的帧全都确认，具体如何实现我们不管。
但是，这里也显示出，回退N帧协议，是一种有序传输帧的协议。

同时我们提到了对帧进行编号。编号是一种防止帧重复的策略，ps:超时机制是一种应对帧丢失的机制。

假设我们用n个比特对帧进行编号，那么可编号的个数是2n，这个毫无争议。需要仔细思考的是：新窗口序号和旧窗口序号如何判别？

一个经典的解释但我到现在还没被说服的是：

用三个比特进行编号，共可编出8个不同的序号，假设定发送窗口为8，编号为0-7.看一种情况：假设8个数据帧全都正确发送到了接收端，并且对每一个数据帧都发送了确认帧。但是所有的确认帧全都丢了，经过一段时间，触发了超时重传机制，重新发送0-7编号的数据帧。接收方会很懵逼，其实这是重传的，但是接收方认为上一轮我确认过了，这新的8个数据帧是新一轮的吧！这样就出错了。

因此，设置发送窗口大小为8是不行的。

what? 那么设置发送窗口为2，3，4，5，6，7就是可以的了吗，如果按照这个逻辑？
假设就编号0,1共两个发送窗口。数据帧正确发送到了接收端，接收端也同样对每一帧发送了确认帧，但是确认帧全都搞丢了。于是发送端重新发送了0,1编号的数据帧，注意这是重传的，但是接收端以为这是新的，所以就没法区分新，旧。
所以，这里的逻辑并不能推演出来我们需要的结论。想一想很可怕。这根本就是随便举个例子，试图解释一个自己压根没弄明白的问题。

我想了很久，也很痛苦，除了记一个简单的结论：发送窗口 + 接收窗口（GBN下是1） <=2n ，n是编号的比特数。

根本理不清到底是为什么。我只能猜想，或许：我们采用3位比特编号的时候，重复使用的是0-7这8个编号，但是，发送窗口大小却必须小于8，即：最大是7.那么，当0-6编号的数据帧全都发送成功，但是确认帧全都消失在路上的时候，重传的帧编号变成：0，1，2，3，4，5，6，接收端看到以后就很开心的知道哦，这是重传的。如果确认帧收到了，继续发送的编号是：7 ，0，1， 2， 3， 4。这样就区别开了上面那个问题。

但是具体是不是这样的编号，为什么用比编号数目小一个的数值作为发送窗口大小，这是我能想到的最合理的解释。至今也没看到具体的编号例题，用于证明。看到的都是结论的运用，看到的是根本解释不了问题的号称解释的解释。

以上猜测，留待证明，更留待被打脸之后的证明。

假设我们带着这个结论看题目，题目自然是很简单就可以解决的。

对于窗口大小为n的滑动窗口，最多可以有多少帧已发送但是没有确认？
发送窗口 + 接收窗口 <= 窗口编号总数，也即窗口数 = n
所以当接收窗口数是1的时候，发送窗口数最大 = n-1

以上。

update1: 看到一个细节，是一个佐证。

在滑动窗口协议中，每一个要发送的帧都包含一个序号，范围是从0到某个最大值，最大值通常是2n−1，n为帧序号的长度。

所以应证了上面的解释。即，3个比特编号的时候，最大编号是7，最小编号是0.