链路层-滑动窗口协议-回退N帧协议-窗口大小选择问题

问题

假设有N位比特可以用来表示帧的序列号，那么应用回退N帧协议的时候，窗口最大可以选择多少呢？

答案

2^N-1

疑点

相信很多人的疑问都是，为什么窗口的最大值不可以是2^n呢？这里首先来用一个图来说明。

假设比特数为3，那么我们按照我们最原始的构想，设计了如上图所示的窗口。按照窗口发送的规则，窗口二第一个元素发送的条件是窗口一中的第0号元素被接受，也就是收到的ACK>=0。
当还没有接收到ACK0的时候，是不会产生歧义的，因为窗口二中的0号元素还没有被发送，ACK0唯一的意义便是窗口1中的0被确认。
但是当接收到ACK0的同时，按照协议约定，发送端会继续发送窗口二中的0号元素。就在这时，歧义发生了——
假如再次收到了ACK0，那么如何判定ACK0的真实意义？
是对窗口一中的0元素的重复确认（窗口一后续元素全部丢失）？
还是对窗口二中刚刚发送的零号元素的确认呢？

解惑

为了避免这个问题的发生，一个非常巧妙的办法诞生了——窗口数目减小1。
这个方法究竟巧妙在了哪里呢？这里给出另外一张图来进行分析。

这个示例就是将窗口缩小1以后的示例。大家会发现一个奇妙的现象，不管接收到多少次ACKN，ACKN所表示的意义都是唯一的。举个例子，比如第一个窗口发送完以后，发送端接收到了ACK0，这时按照协议，窗口的第一个元素丢掉，发送端继续发送7元素,假如这次也很巧，碰到了和上次一样的问题，发送端再次接收到了ACK0，这时候你会发现，发送的所有帧中，**只有第一个窗口发送的帧中含有0元素，第二个窗口中的0元素还未发送，所以第二个ACK0必然代表了对窗口一中的0元素的回应，**也就是说窗口一中0之后的元素全部丢失，不会产生歧义。

总结

相较于第一种窗口大小取法，第二种取法的最大优势在于将已发送未完全确认的包的元素值永远控制在了每个包取唯一值的范围中。举个例子：如果收到ACK4,因为在收到ACK>=5之前第二个窗口的4元素永远不会发送，那么不管收到ACK4，这个ACK4只能是对窗口一中的4元素的确认。或者说，重复收到ACKN并未产生负面的影响（比如产生歧义），而第一种虽然窗口略大一帧，但是重复收到ACKN却会产生歧义。按我的理解而言，第二种窗口分配方案相对于第一种方案具有对于收到ACKN事件的幂等性。