一文带你看流水线协议、回退N步以及选择重传

写在前面:这里是小王成长日志，一名普通在校大学生，想成学习之余将自己的学习笔记分享出来，记录自己的成长轨迹，帮助可能需要的人，平时博客内容主要是一些学习笔记，项目实战笔记，一些技术的探究和自己的一些思考。欢迎大家关注，你们的每一个评论点赞关注我都会仔仔细细去看的。有任何问题欢迎交流，我会尽我所能帮助大家的，共创CSDN美好环境。

自学计算机网络系列，这几天正在整理笔记，如果有错，还请各位大佬指正

1.rdt 3 . 0 的不足

• 之前我们聊了rdt（reliable data transfer）可靠数据传输的三个版本，讨论了如何处理比特差错和丢包的情况，如果不太清楚，可以回去看看-RDT三个版本

• 在最后我们提出了RDT功能正确但性能并不让所有人满意的问题，其源头在于其是一个停等协议,这样的一个停等协议严重浪费了网络资源(在等的信号发送过程中)

• 所以我们自然而然就想要寻找一份新的协议或者尝试弥补rdt协议的缺憾.考虑一下流水线协议 :我们一次传输多个分组,因此接收方回复的ACK报文也是一次多个,提高了效率

• 停等协议与流水线协议的比较(图例)
  

2.流水线技术对可靠数据传输协议带来的影响

• 1.为了防止冗余分组，在rdt协议中我们为每个分组附加上序号1或0，而在流水线协议中，因为一次性发送多个分组，所以必须增加序号范围

  • 因为在每个输送中的分组必须有唯一的序号
  • 在也可能有多个待接收确认报文

• 2.协议的发送方和接收方两端必须缓存多个分组

  • 至少应该缓存哪些已发送待还没有被确认的分组

• 3.所需序号范围和对缓冲的要求取决于数据传输协议如何处理丢失、损坏及延时过大的分组 。

• 4.解决流水线的差错回复(分组发生比特差错或者直接丢包)的两种基本方法

  • 回退 N 步 (Go- Back- N，GBN)
  • 选择重传 (Selective Repeat. SR)

3.回退N步(Go- Back- N,GBN,滑动窗口协议)

• 在回退 N 步 (GBN) 协议中，允许发送方发送多个分组(当有多个分组可用时)而不需等待确认
• 发送方为每一个未确认分组设置一个定时器,当定时器超时则重发所有未确认分组
• 接收方只发送累积确认报文,即若有缺失则步发送序号在缺失的分组后的分组的确认报文
• 在发送方的流水线中,至多有N个未确认的分组,其中N是窗口长度
• 在 GBN 协议中，接收方丢弃所有失序分组(因为发送方必将重传),并按照顺序向上层交付数据

3.1 序号范围

• 基序号(base)

  • 指最早的未确认分组的序号

• 下一个序号(nextseqnum)

  • 指最小的未使用序号,即下一个待发分组的序号

• 窗口长度(window size)

  • 已被发送但还未被确认的分组的许可序号范围可以被看成是一个在序号范围内长度为 N 的窗口 。
  • 随着协议的运行，该窗口在序号空 间向前滑动 。
  • 因此
    • N 常被称为窗口长度 (window size)
    • GBN 协议也常被称为滑动窗口协议

3.2 FSM描述

发送方

• 图例

• GBN 发送方必须响应三种类型的事件:

  • 1.上层的调用

    • 当上层调用 rdt_send() 时，发送方首先检查发送窗口是否已满，即是否有 N 个已发送但未被确认的分组 。
    • 如果窗口未满，则产生一个分组并将其发送，并相应地更新变量 。
    • 如果窗口已满，发送方只需将数据返回给上层，隐式地指示上层该窗口已满 。 然后上层可能会过一会儿再试 。
    • 在实际实现中，发送方更可能缓存(并不立刻发送)这些数据，或者使用同步机制(如一个信号量或标志)允许上层在仅当窗口不满时才调用 rdt_send() 。

  • 2.接收ACK

    • 在 GBN 协议中，对序号为 n 的分组的确认采取累积确认( cumulative acknowledgment) 的方式，表明接收方已正确接收到序号为凡的以前且包括 n在内的所有分组 。

  • 3.处理超时事件

    • 就像在停等协议中那样，定时器将再次用于恢复数据或确认分组的丢失 。
    • 如果出现超时，发送方重传所有已发送但还未被确认过(从第一个未被确认的分组开始之后所有分组都会重发,因为接收方采用的是累计确认的方式)的分组 。

接收方

• 图例

• 接收方的行为
  • 接收方只对正确接收(无差错且序号正确)的分组发送确认报文
    • 所以可能会重复发送童同一个序号的确认报文,因为在这个序号后面的一个分组并没有被正确接收,当收到这个序号之后的分组时都会发送被正确接收的分组的最大序号
  • 对于失序分组,接收方会直接丢弃,因为发送方必将重传

3.4 一个运行示例(窗口长度为4)

4.选择重传(Selective Repeat. SR)

4.1 GBN的优缺点

• GBN使用流水线技术避免了停等协议中的信道利用率问题

• 但是GBN中回退N步 明显部分分组是不需要重传的,在窗口长度较大的情况下,GBN代价较大

• 因此我们再来看看选择重传
  SR,如其名,通过让发送方仅重传那些它怀疑在接收方出错(即丢失或受损)的分组而避免了不必要的重传 。

4.2 选择重传序号空间

4.3 FSM描述

发送方的行为

• 1. 从上层收到数据 。
  • 当从上层接收到数据后，检查序号是否有可用。
  • 如果序号位于发送方的窗口内，则将数据打包并发送;
  • 否则就像在 GBN 中一样，要么将数据缓存，要么将其返回给上层以便以后传输。
• 2. 超时
  • 现在每个分组必须拥有其向己的逻辑定时器，因为超时发生后只能发送一个分组 。
  • 可以使用单个硬件定时模拟多个逻辑定时器的操作 。
• 3. 收到 ACK
  • 如果收到ACK ，倘若该分组序号在窗口内，则 SR 标记该分组已确认
  • 如果该分组的序号等于 send_base， 则窗口基序号向前移动
  • 如果窗口移动了并且有序号落在窗口内的未发送分组，则发送这些分组 。

接收方的行为

• 1.序号在[ rcv_base , rcv_base + N - 1] 内的分组

  • 正确接收 ,回复ACK
  • 如果该分组以前没收到过，则缓存该分组 。
  • 如果其序号等于接收窗口的基序号 ，则该分组以及以前缓存的序号连续的(起始于 rcv_base 的)分组交付给上层 。
  • 然后，接收窗口接向前移动分组的编号向上交付这些分组 。
  • 举例子来说，考虑一下上图,当收到一个序号为rcv_base =2的分组时，该分组及分组 3 、 4 、 5 可被交付给上层 。
• 2. 序号在[ rcv_base - N， rcv_base- 1 ]内的分组
  • 如果正确接收 , 在此情况下，必须产生一个 ACK ，即使该分组是接收方以前已确认过的分组 。
  • 因为只要不回复,定时器一到会一直重发这一个分组
• 3. 其他情况 。 忽略该分组 。

4.4 一个运行示例(窗口长度为4)

4.5 SR存在的隐患

• 当我们面对有限序号范围的现实时，发送方和接收方窗口间缺乏同步会产生严重的后果

• 该例有包括 4 个分组序号 0 、 1 、 2 、 3 的有限序号范围且窗口氏度为 3 。 假定发送了分组 0 至 2 ，并在接收方被正确接收且确认了 。 此时，接收方窗口落在第 4 、 5 ， 6 个分组上，其序号分别为 3 、 0 、 l 。 现在考虑两种情况 。 在第一种情况下，如上面的图所示，对前 3 个分组的 ACK 丢失，因此发送方重传这些分组 。 因此，接收方下一步要接收序号为 0 的分组，即第一个发送分组的副本 是一个新分组还是重传?

  • 我们没办法区分

• 所以我们的窗口长度(接收窗口)必须小于或等于序号空间(发送窗口)大小的一半
  以下是一个关于长度的知乎回答
  

---

都看到这里了，各位哥哥姐姐叔叔阿姨给小王点个赞 关个注 留个言吧，和小王一起成长吧，你们的关注是对我最大的支持。

---

如果以上内容有任何不准确或遗漏之处，或者你有更好的意见，就在下面留个言让我知道吧-我会尽我所能来回答。