后退N帧协议（GBN）

前言： GBN协议和SR协议，都是为了提高信道利用率。

 

流水线技术

在流水线技术中：
1.发送方需要缓存多个分组，可以发送多个分组。
2.如果发生帧丢失或者帧差错，那么就会用到帧的副本。（后文会提及）。我们需要更大的空间来存放这些副本。

 

后退N帧协议中的滑动窗口

建议大家认真看下图：

窗口的移动：
原来的发送窗口中是0~5帧，发送0帧之后，如果接收窗口接收到0帧，窗口后移一格，并发送确认帧ACK0。接收到确认帧后，发送窗口就会移动，移动一格，这时要发送1 ~ 6帧。
我们发送1和2帧，当然后面窗口中的其他帧也是可以发送的。

 

运行中的GBN（具体细节）

若接收成功：
发送方如果发送0帧，那么接收方就要接受0帧并返回确认帧ACK0。这个时候，接收方就会根据帧编码推算下一个帧为1号帧。
那么根据上图发送窗口发送1号帧，接受窗口成功接收到了1号帧，并返回ACK1。接收端推算出下一个帧应该为2号帧。

若接收失败：
可是2号帧在发送中意外丢失，没有给到接收窗口。而接收方继续发送3号帧，这时在接收窗口接收到了3号帧。可惜接收窗口很专一啊，2号帧没有来，谁来也不好使，接收窗口就会把3号帧丢弃，继续发送确认帧1，提醒发送窗口该发送2号帧了，4、5帧也是同等待遇。（专一的接收窗口，我哭了~~）。

接收失败的措施：
在发送窗口，每发送一个帧，就会启动超时计时器。比如我们的2号帧一旦发送，就会启动超时计时器。没有接收到确认帧2，就会超过计时器时间导致重新发送。
上面我们的发送窗口一直接收的是确认帧1，迟迟没来确认帧2，那么就会导致确认帧2以及2之后的，发送过的帧重新发送（即使这些帧在接收窗口接收到了）。

 

滑动窗口长度

很多人会问这个问题，既然为了提高信道利用率，那我的发送窗口岂不是越多越好？

这样显然是不对的。

若采用n个比特对帧编号，那么发送窗口的尺寸w应满足：1<=w<=2ⁿ-1
如果发送窗口尺寸过大，会使的接收方无法区别新帧和旧帧。
我们举个例子：
如果n=2，那么编号为00、01、10、11对应0、1、2、3，w最大为3。
如果我们w=4，也就是发送窗口大小为4，在发送过程中，很不幸，所有数据帧发送失败，超时计时器结束之后，那么必然要全部重新发送
再次发送编号为0、1、2、3的数据帧，问题就来了，这是重新发送的，还是下一次全部发送过来的，接收方就会搞不清楚。

 

GBN协议性能分析

1.因连续发送数据帧而提高了信道利用率
2.在重传时必须把原来已经正确传送的数据帧重传，使传送效率降低。