流量控制之GBN协议
停等协议的弊端：
停等协议大多数时间都在等待(空闲)，发送的时间占比比较低
浪费资源、太闲了
改善：
1.现在要连续发送多个帧，每个帧编号不同，便于出错我们定位是哪一个帧，因此帧的编号必须扩充。
- 停等协议的缓冲区只有一个，因为它一次只能发送一个帧，出错的话，直接取缓冲区中唯一的一个帧；但是采用连续发送多个帧，自然缓冲区就得扩容，扩充之后的缓冲区放入每个帧对应的拷贝，当发送出现问题需要再次发送的时候，就可以在大号缓冲区中找到对应的拷贝，供再次发送。
引入GBN、SR协议
GBN协议(后退N帧协议)
接收窗口接收到0#帧之后，就会返回一个0#确认帧，紧接着接收窗口的窗口就会向后移动一个，接收窗口变成1；然后，发送窗口收到0#确认帧之后，发送窗口也会向后移动一个窗口
发送窗口有6个并不表示这6个都会连续发送，而是可能会2个、3个连续发送。发送窗口可能不一定会被填满，6个窗口的发送窗口，可能目前只有2、3个帧，剩下位置是空的。
GBN发送方必须做的三件事：
-
发送方必须先检查发送窗口是否已满，要是满的话，发送方会告诉上层 发送窗口已满，等一会再发送（实际情况是上层还是会发给发送方的缓冲区）；要是没有满，上层就会把数据发送给发送窗口
-
累计确认：累计确认就是指 对n号帧累计确认，不仅暗示已经收到了n号帧，而且收到了n号帧之前的所有帧。 正是由于累计确认的方式，GBN方式下不用对每一个帧都返回确认帧，可以每隔几个帧返回确认帧。这样比较高效
-
超时事件(后退N帧) 没收到的帧以及没收到的帧之后的帧，随后会再次被发送
比如说，发送方发送出去n号帧，但是n号帧在路上丢失了，但是n+1,n+2这两个帧仍然顺利发送出去；但是接收方接收窗口只能容纳一个帧，此时的接收方（根据前面的n-1号帧）还是期望收到一个n号帧，所以面对发来的n+1,n+2号帧还是丢弃。一直到n号帧因为超时重传被再次发送过来，n+1,n+2号帧会随n号帧之后被再次发送过来。
GBN接收方要做的三件事：
-
如果正确收到n号帧，并且n号帧之前的帧也都按序，那么只发送一个ack n 帧给发送方
-
如果有帧丢失以及其他出错情况，比如发送出去 1 2 4 5这样4个帧，3号帧丢失，接收方会陆续收到1 2 帧，之后，期待的是3号帧，但是发现传来的是4号帧和5号帧，就会把4 5号帧丢弃，并返回一个ack 2给发送方，发送方收到ack 2之后，就会把3 4 5帧又全部的发送出去。
发送帧一般是连续连续的发送，遇到编号不连续（丢帧）的帧，把连续部分发送出去，不连续部分二次连续的发送出去
帧编号（比特位数）和发送窗口长度的关系： 发送窗口长度小于帧编号
帧编号(由比特位数决定，比如max{0 1 2 3 4 5 6 7}) \(>\) 发送窗口长度
- 累计确认(偶尔捎带确认)
- 接收方只按序接收帧，无序则 丢掉
- 遇到差错的 确认序列号会是前面有序帧序号最大值的ack值，比如ack 2返回给发送方，3号帧以及以后的帧则会重发
- 发送窗口最大值是 \(2^n-1\) ，接收窗口1
GBN协议的性能：
缺点：丢失的帧出错，不仅要把丢失的帧重传，还要把丢失的帧之后的帧也得重传
因为连续发送提高了信道利用率
重传时必须把原来正确的数据帧重传，传送效率降低
