3.4.3后退N帧协议（GBN）

针对停止等待协议的弊端，首先提出流水线技术：

因此：
1.必须增加序号范围
2.发送方需要缓存多个分组。

针对以上问题，提出两种协议：
1.后退N帧协议（GBN）
2.选择重传协议（SR）

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

GBN发送方必须响应的三件事：

1.上层的调用：上层要发送数据时，发送方先检查发送窗口是否已满。如果未满，则产生一个帧并将其发送；如果窗口已满，发送方只需将数据返回给上层，暗示上层窗口已满。上层等一会再发。（实际实现中，发送方可以缓存这些数据，窗口不满时再发送帧）
2.收到了1个ACK：GBN协议中，对n号帧的确认采用累计确认的方式，标明接收方已经收到n号帧和它之前的全部帧。
3.超时事件：协议的名称为后退N帧，来源于出现丢失和时延过长帧时发送方的行为。就像在停止等待协议中一样，定时器将再次用于恢复数据帧或确认帧的丢失。如果出现超时，发送方将重传所有已发送但未被确认的帧

GBN接收方要做的事：

1.如果正确收到n号帧，并且按序，那么接收方为n帧发送一个ACK，并将该帧中的数据部分交付给上层。
2.其余情况都丢弃帧，并为最近按序接收的帧重新发送ACK。接收方无需缓存任何失序帧，只需维护一个信息：expectedseqnum(下一个按序接收的帧序号)

运行中的GBN：

###滑动窗口的长度
若采用n个比特对帧编号，那么发送窗口的尺寸WT应满足：1<=WT<=(2^n-1)。
因为发送窗口尺寸过大，就会使接收方无法区别新帧和旧帧。

比如用两个比特给帧编号：00、01、10、11。帧序列为【0，1，2，3】，【0，1，2，3】…
则发送窗口的大小最大为：3。
假如发送窗口的大小为4>3。如果第一个窗口发送的0123号的确认帧全部丢失（接收方收到但是给发送方的回复全丢失），计时器时间到之后发送方又重新发送了第一个窗口的0123号，而接收方的0号帧等待的已经是第二个窗口的0号帧（因为第一个窗口的0123号接收方已接收）

GBN协议性能分析

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