停等协议的弊端
信道利用率低：在停等协议中，发送方在发送完一帧后必须等待接收方确认（ACK）才能发送下一帧。如果确认丢失或延迟，发送方会因超时而重新发送数据帧，这导致信道在等待确认时处于空闲状态，造成信道资源的浪费。（通过对比完成发送两个帧的所需时长可知道）
流水线：每个数据帧都会接着上一个数据帧发送
此时需要增加序号范围（流水线发送多）并可能还需要缓存多个数据帧（流水线连续发送）
后退N帧协议中的滑动窗口
发送窗口是一组连续的发送的帧序号（即一个一个发送出去）
发送一个帧后会复制一份保持到发送方
接受方接受到0号帧后会右移一位
发送方接受到0号帧的确认帧ACK 0后会右移一位
接受方可以接受多个帧后再发送最后一个帧的确认帧，这样也能保证前面的帧都已经接受到是因为接受到一个帧接收方的接受窗口才会移动，所以能发送最后一个帧那么之前的帧都已经接受到了。
GBN发送方必须响应的三件事
累计确认：GBN（Go-back-N）协议中的累计确认是一种机制，用于告知发送方哪些数据已经被接收方成功接收。
在GBN协议中，接收方使用累积确认（Cumulative Acknowledgment）的方式来通知发送方数据的接收状态。这意味着接收方不会为每一个成功接收的数据包都发送确认消息，而是发送一个确认号（ACK），该确认号代表了接收方期望收到的下一个数据包的序号。通过这种方式，发送方可以得知接收方已经成功接收了所有序号在确认号之前的数据包。
例如，如果接收方收到了序号为1、2和3的数据包，但是序号为4的数据包出现了错误或者丢失，那么接收方会发送确认号为4的ACK，表示它已经成功接收了序号为1、2和3的数据包，并且在等待序号为4的数据包。
超时事件GBN的处理行为与停等协议不同
GBN接受方要做的事
并为最近按序接收的帧重新发送ACK：将没有接收的序号的前一个的确认帧发送，发送方接收到后知道接收方接收到的帧的序号，从而能够发送接收方没有接收到的帧
运行中的GBN
当发送完1帧接收方并且接收到1帧后，发送的2帧丢失后，即使3帧发送并且接收方接收到了，也会丢弃并发送1号确认帧
当发送方接收到一个确认帧就会右移动相应的窗口数
发送方接收2号确认帧超时时将重传2号帧以及其之后的帧
可以理解接收方吃汉堡必须按照每层规定的吃
滑动窗口长度
后退N帧协议（Go-Back-N ARQ）中的滑动窗口长度的上界是为了确保接收方能够正确区分新帧和旧帧。
后退N帧协议中，发送方和接收方分别维护一个发送窗口和接收窗口。这些窗口本质上是序号的集合，指示了哪些帧可以被发送或接收。具体来说：
- 发送窗口：允许发送方发送一组连续编号的帧。
- 接收窗口：接收方只允许接受一个指定序号的帧，即接收窗口大小通常为1。
使用n比特进行帧编号时，可以产生(2^n)个不同的序号。为了确保接收方不会混淆新旧数据帧，发送窗口的大小应满足1 ≤ W_T ≤ 2^n - 1的条件。如果发送窗口的大小超过 (2^n - 1)，则可能会发生一种情况，即某个已经发送但未被确认的数据帧的序号再次出现在窗口中，导致接收方无法区分这是新的传输还是之前已发送过的旧帧的重传。
例如，如果用3比特进行编号，虽然理论上可以有8个不同的序号，但如果设置发送窗口大小为8，那么当发送完0到7号帧后，若这些帧都已正确到达但还未被确认，发送窗口将满且暂停发送。此时，如果发生了错误需要重传，由于序号会重复出现，接收方将无法区分是新的传输还是旧帧的重传，从而可能导致混乱。
GBN协议重点总结
偶尔捎带确认：接收方偶尔会发送数据给发送方并将确认帧捎带上
确认序列号最大的，按序到达的帧：即当接收到1，2，4确认帧时，会以2为确认帧传回
发送窗口确定后在运行过程就不能轻易改变
习题1
收到3号帧确认时此时意味着3及之前的帧都接收到了，那么发送窗口将右移4个
习题2
发送方接收到第一个确认帧时已经发送的字节/发送方接收到第一个确认帧的时间
GBN协议性能分析
小结
2420
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
