计算机网络学习（六）传输层 Ⅲ

正在学习计算机网络课程，以下是学习《计算机网络-自顶向下方法》的一些笔记，部分图片来自mooc网 哈尔滨工业大学 计算机网络课程：https://www.icourse163.org/course/HIT-154005。

1.滑动窗口协议

1.1流水线机制与滑动窗口协议

rdt 3.0 是一个功能正确的协议，但它的性能不能让人满意，rdt 3.0 性能问题的核心在于它是一个停等协议。

• 解决问题的简单方法是：流水线技术
• 效率对比
  • 停等操作
    
  • 流水线机制
    
• 流水线（pipeline）技术：不使用停等方式运行，而是允许发送方发送多个分组而无需等待确认
  • 必须增加序号范围
  • 协议的发送方和接收方两端需要更大的存储空间以缓存分组
• 滑动窗口协议（sliding- window protocol）：
  • 窗口：允许使用的序列号范围
  • 窗口尺寸为 N ：最多有N个等待确认的消息
  • 滑动：随着协议的允许，窗口在序列号空间内向前滑动
  • 具体协议：GBN、SR
    

1.2 GBN（Go-Back-N）协议

• 基序号( send_base) 定义为最早的未确认分组的序号

• 下一个序号( nextseqnum) 定义为最小的未使用序号(即下一个待发分组的序号）

  • 绿色段内的序号对应于已经发送并被确认的分组
  • 黄色段内对应已经发送但未被确认的分组
  • 蓝色段内的序号能用于那些要被立即发送的分组
  • 白色段内的序号是不能被使用的分组

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

  • 1.上层的调用
    • 当上层调用 rdt_send() 时，发送方首先检查发送窗口是否已满
    • 如果窗口未满，则产生一个分组并将其发送， 并相应地更新变量。 如果窗口已满，发送方只需将数据返回给上层，隐式地指示 上层该窗口已满，过会儿再试
  • 2.收到一个 ACK
    • 在 GBN 协议中，对序号为 n 的分组的确认采取累积确认的方式，表明接收方已正确接收到序号为 n 之前且包括 n 在内的所有分组。
  • 3.超时事件
    • 就像在停等协议中那样，定时器将再次用于恢复数据或确认分组的丢失
    • 如果出现超时，发送方重传所有已发送但还未被确认过的分组
    • 如果收到一个 ACK ，但仍有已发送但未被确认的分组，则定时器被重新启动。 如果没有已发送但未被确认的分组，该定时器被终止

• GBN 接收方的动作：

  • 如果一个序号为 n 的分组被正确接收到，并且按序(即上次交付给上层的数据是序号为 n - 1 的分组) ，则接收方为分组 n 发送一个 ACK，并将该分组中的数据部分交付到上层。
  • 在所有其他情况下，接收方丢弃该分组，并为最近（序列号最大）按序接收的分组重新发送 ACK。
  • 这种方法的优点是接收缓存简单，接收方不需要缓存任何失序分组，需要维护的唯一信息就是下一个按序接收的分组的序号（expectedseqnum）
  • 如果分组 k 已接收并交付给上层，则所有序号比 k 小的分组也已经交付

• 例子：1. 窗口长度为 4
  

• GBN 协议中综合了 TCP 可靠数据传输构件时遇到的所有技术。 这些技术包括使用序号、累积确认、检验和以及超时/重传操作。

• 为什么先要限制窗口长度为 N 呢？为什么不允许这些分组为无限制的数目呢?—— 流量控制是对发送方施加限制的原因之一，还将在学习 TCP 拥塞控制时分析另一个原因。

• 1.3 SR（Selective Repeat）协议

• GBN 本身也有一些情况存在着性能问题，单个分组的差错就能够引起 GBN 重传大量分组，许多分组根本没有必要重传。

• 选择重传（SR）

  • 接收方对每个分组单独进行确认（缓存机制，缓存乱序到达的分组）
  • 发送方只重传那些没有收到 ACK 的分组（为每个分组设置定时器）

• SR 发送方和接收方的窗口：
  

• SR 发送方的事件与动作

  • 从上层收到数据。
    • 当从上层接收到数据后，发送方检查下一个可用于该分组的序号。
    • 如果序号位于发送方的窗口内，则将数据打包并发送；
    • 否则就像在 GBN 中一样，将数据缓存，或返回给上层以便以后传输。
  • 超时。
    • 定时报用来防止丢失分组
    • 每个分组必须拥有其自己的定时器，因为超时发生后只能发送一个分组。
  • 收到 ACK。
    • 如果收到 ACK，倘若该分组序号在窗口内，则发送方将那个被确认的分组标记为已接收
    • 如果该分组的序号等于 send_base ， 则窗口基序号向前移动到具有最小序号的未确认分组处
    • 如果窗口移动了并且有序号落在窗口内的未发送分组，则发送这些分组。

• SR 接收方的事件与动作

  • 序号在[ rcv _base, rcv _base + N - 1]内的分组被正确收到
    • 在此情况下，收到的分组落在接收方的窗口内， 一个选择 ACK 被回送给发送方。
    • 如果该分组以前没收到过，则缓存该分组。
    • 如果该分组的序号等于接收窗口 的基序号 rcv_base ，则该分组以及以前缓存的序号连续的（起始于 rcv_base 的）分组交付给上层。 然后，接收窗口接向前移动分组的编号向上交付这些分组。
  • 序号在[ rcv_base - N， rcv _base - 1 ]内的分组被正确收到
    • 在此情况下，必须产生一个 ACK ，即使该分组是接收方以前已确认过的分组。
  • 其他情况。 忽略该分组。

• 一个例子说明出现丢包时 SR 的操作。 注意，接收方初始时缓存了分组 3 、4、5 ，并在最终收到分组 2 时，才将它们一并交付给上层。
  

• 然而，对于哪些分组已经被正确接收，哪些没有，发送方和接收方并不总是能看到相同的结果。对 SR 协议 而言，这就意味着发送方和接收方的窗口会缺乏同步，并不总是一致。这也许会产生严重的后果：

  • 前提：有 4 个分组序号 0 、1 、2 、3 的有限序号范围且窗口长度为 3
  • 情况a：对前 3 个分组的 ACK 丢失，因此发送方重传这些分组。 因 此，接收方下一步要接收序号为 0 的分组，即第一个发送分组的副本
    
  • 情况b：对前3 个分组的 ACK 都被正确交付，发送方向前移动窗口并发送第 4、5 ，6 个分组，其序号分别为 3 、0 、1。 序号为 3 的分组丢失， 但序号 0 的分组到达(一个包含新数据的分组) 。
    
  • 对于接收方而言，两种情况是等同的。没有办法区分是第一个分组的重传还是第 5 个分组的初次传输。显然，窗口长度比序号空间小 1 时协议无法工作
  • 解决方法：序列号空间必须足够大，以适合整个接收方窗口和整个发送方窗口，而不存在这种重叠情况。对于SR 协议 而言，窗口长度比须小于或等于序号空间大小的一半

2. 可靠级据传输机制及其用途的总结

1. 我们曾假定分组在发送方与接收方之间的信道中不能被重新排序。 这在发送方与接收方由单段物理线路相连的情况下，通常是一个合理的假设。然而，当连接两端的 "信道"是一个网络时，分组重新排序是可能会发生的。
2. 分组重新排序的一个表现就是，一个具有序号或确认号 x 的分组的旧副本可能会出现，即使发送方或接收方的窗口里都没有包含 x。
3. 出现原因就是 信道可被看成基本上是在缓存分组，并在将来任意时刻自然地释放出这些分组
4. 实际应用中采用的方法是，确保一个序号不被重新使用，直到发送方"确信"任何先前发送的序号为 x 的分组都不再在网络中为止。
5. 通过假定一个分组在网络中的"存活"时间不会超过某个固定最大时间量来做到这一点。 在高速网络的 TCP 扩展中，最长的分组寿命被假定为大约 3 分钟