个人主页：兜里有颗棉花糖
欢迎 点赞👍 收藏✨ 留言✉ 加关注💓本文由 兜里有颗棉花糖 原创
收录于专栏【计算机网络】
本专栏旨在分享学习计算机网络的一点学习笔记，欢迎大家在评论区交流讨论💌
目录
一、停止等待协议回顾
如下图所示：发送方每发送一个数据分组，就停止发送并等待接收方的确认分组。当发送方接收方针对该数据分组的确认分组后才能够发送下一个数据分组，如此反复进行。通过下图我们可以看到发送方每发送一个数据分组，就至少要等待一个收发双方之间的往返时间。
当往返时间较大时（比如卫星链路），停止-等待协议的信道利用率很低；如果遇到超时重传，信道利用率只会更低。
**如果发送方在接收到接收方的确认分组之前可以连续发送多个数据分组，则可以大大提高信道利用率。这是一种流水线式的传说。就本地而言，同等条件下，相同时间内，使用停止等待-协议的发送方只能发送一个数据分组，
而采用流水线的方式的发送方可以发送多个数据分组。
**
二、回退N帧协议
**现在，我们来学习回退
N帧协议
，该协议在流水线传输的基础上，
利用发送窗口来限制发送方可以连续发送数据分组的个数
。**
**
举个栗子
**：假设使用三个比特来给分组便序号，故
序号的取值范围是0-7
。
下图是收发双方各自的分组序号，当序号增加到7时，下一个序号又从0开始。发送方要维持一个发送窗口，序号落在发送窗口内的数据分组可以被连续发送而不必等收到接收方的相应确认分组后再进行发送。
- 发送窗口的尺寸记为WT，对于本地，其取值范围时
1<WT<=2^3-1（3表示本例取WT值的数量）。其中的是构成分组序号的比特数量。在本例中WT值的取值为5，如果WT的值为1的话则是停止-等待协议。如果WT的值超过取值范围的上限则会造成严重的错误。
如下图所示，序号落在窗口内的这五个信号可以连续发送，而序号落在窗口外的数据分组不允许发送，
接收窗口的尺寸记为WR
。对于回退N帧协议WR的取值只能为1（与停止等待协议相同）。现在再来看接收窗口（如下图所示），序号落在接收窗口内的序号允许接收，序号落在接收窗口外的数据分组不允许接收。
三、不同情况举例
无差错情况
先来看最简单的情况，即无差错情况：发送方将落在发送窗口内的0-4号序号的数据分组依次连续发送出去，数据分组经过互联网的传输正确到达了接收方（没有出现乱序和误码）。
接收方按序接受它们，每接受一个，接收窗口就向前滑动一个位置。并给发送方发送针对该数据分组的确认分组。最后，0-4号确认分组经过互联网的传输就到达了发送方。发送方每接收一个数据分组，发送窗口就先前移动一个位置，这样就有了新的序号落入了发送窗口，同时发送方可以将收到确认的数据分组从缓存中删除。**
接收方可以选择时机将接收到的数据分组交付给上层处理
**。
累计确认
使用回退N帧协议的接收方可以采用累计确认的方式，意思就是接收方不一定要对接收到的数据分组逐个发送确认。而是在收到某个数据分组后，对按序列到达的最后一个数据分组发送确认。**
ACKn表示序号n及n以前的所有数据分组都已经正确接收了
。**
下面我们来举个累计确认情况的栗子：发送方将落在发送窗口内的0到4号数据分组依次连续发送出去，经过互联网的传输到达了接收方，接收方按需对其进行接收。**当接收完0号和1号数据分组时，接收方给发送方发送了一个累计确认ACK1。当接受完2到4号数据分组后，接收方给发送方发送了一个
累计确认ACK4
**。现在假设ACK1在传输过程中丢失了，而ACK4正确到达了发送方，发送方接收ACK4后就知道了。序号4及之前的数据分组已经被接收方正确接收了。于是将发送窗口向前移动5个位置。此时也就有了新的序号落入了发送窗口（如下图所示）：
然后发送方可以将收到确认分组的数据分组从缓存中删除了；而接收方可以择机将已接收的数据分组交付上层处理（如下图）。
通过这个栗子我们就可以发现，使用累计确认的其中一个优点：即使确认分组丢失，发送方也可能不必重传。例如本例中ACK1丢失了，但是并没有触发1号数据分组的超时重传。
当然，使用累计确认也有一些其它好处，比如可以减少接收方的开销，减少对网络资源的占用。
同时，累计确认也有缺点：不能向发送方及时反映出接收方已经正确接收的数据分组信息。
回退N帧
现在我们来看有差错的情况，发送方将序号落在窗口内的这五个数据分组依次连续发送出去，其经过互联网的传输后到达了接收方。现在假设其在传输过程中收到了干扰，其中5号数据分组出现了误码，接收方通过数据分组中的检测码发现了错误，于是丢弃该数据分组；而后续到达的这四个数据分组的序号与接收窗口中的序号不匹配，故接收方同样也不能够接收它们，将它们丢弃，并对之前按需接受的最后一个数据分组进行确认（也就是发送ACK4）。每丢弃一个数据分组就发送一个ACK4。这4个ACK4经过互联网的传输到达了发送方，因为发送方之前就已经接受过ACK4，当收到这些重复的ACK4时就知道了之前所发送的数据分组出现了差错。于是可以不用等待超时计时器超时就可以立即开始重传。至于收到几个重复确认就立即重传，由具体实现来决定。
在本例中，假设收到这4个重复的确认并不会触发发送方立即重传，一段时间后，超时计时器出现超时，发送方将发送窗口内已发送过的这些数据分组全部重传。
在本例中。尽管序号为6、7、0、1的数据分组正确到达接收方，但由于5号数据分组误码不被接受。它们也“受到牵连”而不被接受，发送方还要重传这些数据分组,这就是所谓的
Go-back-N(回退N帧)
。
所以，当通信线路质量不好时，回退N帧协议的信道利用率并不比停止-等待协议高。
WT超过其取值范围上限的情况
现在我们来看看如果发送窗口的尺寸WT超过其取值范围的上限会发送什么事情。
依然是采用3个比特给分组编序号，故WT最大值为7，现在我们故意使得WT的取值为8。现在发送方将序号落在发送窗口内的0到7号这8个数据分组依次连续发送出去。其经过互联网的传输到达了接收方。接收方按序依次将其接收后，给发送方发回
累计确认ACK7
。假设ACK7在传输过程中丢失了，这将导致发送方的超时重传，重传的0到7号数据分组到达接收方（如下图）。
现在问题来了，接收方根据当前接收窗口内的序号，会对这8个数据分组按序接收，但是接收方之前已经接受过这8个数据分组了，现在是在重复接收，也就是说接收方无法接收新旧分组，进而会产生分组重复这种传输错误。因此，**
发送窗口的尺寸不能够超过其上限
**。
小练习
四、总结
本文到这里就结束喽，希望友友们可以支持一下一键三连哈。嗯，就到这里吧，再见啦！！！
版权归原作者 兜里有颗棉花糖 所有， 如有侵权，请联系我们删除。