计算机网络学习（五）传输层 Ⅱ

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

1.可靠数据传输原理

1.1 可靠数据传输原理概述

• 何为可靠？——不错、不丢、不乱
• 可靠数据传输协议 （reliable data transfer protocol，rdt）
  • 框架：
    
  • 为上层实体提供的服务抽象是（如图a）：数据可以通过一条可靠的信道进行传输。 借助于可靠信道，传输数据比特就不会受到损坏 (由 0 变为 1 ，或者相反)或丢失，而且所有数据都是按照其发送顺序迸行交付。 这恰好就是 TCP 向调用它的因特网应用所提供的服务模型。
  • 由于可靠数据传输协议的下层协议也许是不可靠的（如图b），因此这是一项困难的任务。 例如， TCP 是 在不可靠的( IP) 端到端网络层之上实现的可靠数据传输协议。
  • 可靠数据传输协议基本结构：接口
    • rdt_send()：被上层应用调用，将数据交给 rdt 以发送给对方
    • udt_send()：被 rdt 调用，在不可靠信道上向接收方传输数据
    • rdt_rcv()：当数据包到达接收方信道时被调用
    • deliver_data()：被 rdt 调用，向上层应用交付数据
  • 在本节中，我们仅考虑单向数据传输 ( unidirectional data transfer) 的情况，即数据传 输是从发送端到接收端的。 可靠的双向数据传输 (bidirectional data transfer) (即全双工数据传输)情况从概念上讲不会更难，但解释起来更为单调乏味。

1.2 rdt 1.0：可靠信道的可靠数据传输

• 从最简单的情况开始考虑，即底层信道是完全可靠的。 我们称该协议为 rdt1. 0
• 底层信道是完全可靠：
  • 不会发生错误
  • 不会丢弃分组
• 发送方和接收方的**有限状态机( Finite-State Machine, FSM)**是独立的：
  
• 在这个简单的协议中，一个单元数据与一个分组没差别。 而且，所有分组是从发送方流向接收方；有了完全可靠的信道，接收端就不需要提供任何反馈信息给发送方。

1.3 rdt 2.0：有比特差错信道的可靠数据传输

• 在分组的传输、传播或缓存的过程中，这种比特差错通常会出现在网络的物理部件中
• 我们眼下还将继续假定所有发送的分组(虽然有些比特可能受损)将按其发送的顺序被接收
• 如何检测错误？——利用校验和检测位错误
• 如何从错误中恢复？——基于重传机制的可靠数据传输协议：自动重传请求( Automatic Repeat reQuest, ARQ) 协议 ，具体的机制：
  • 确认机制（Acknowledgements，ACK）：接收方显示地告诉发送方分组已经正确接收
  • NAK：接收方显示地告诉发送方分组有错误
  • 发送方收到NAK后，重传分组
• 发送方和接收方的FSM:
  
• 注意，发送方将不会发送一块新数据除非发送方确信接收方已正确接收当前分组。像 rdt 2.0 这样的协议被称为停—等( slop-and-waü) 协议。
• rdt 2.0 也并非完美，它存在一个致命的缺陷。 那就是 ACK 或 NAK 分组也可能受损！，怎么解决？—— rdt 2.1

1.4 rdt 2.1：接收方，对应 ACK/NAK 受损

• 如果一个 ACK 或 NAK 分组受损，则发送方无法知道接收方是否正确接收了上一块发送的数据，解决办法？
  • 为 ACK/NAK 增加校验和，当发送方收到含糊不清的 ACK 或 NAK 分组时，只需重传当前数据分组即可。
  • 然而，这种方法在发送方到接收方的信道中引人了冗余分组问题。
  • 冗余分组的根本困难在于接收方不知道它上次所发送的 ACK 或 NAK 是否被发送方正确地收到。因此它无法事先知道接收到的分组是新的还是一次重传 ! 解决办法？—— 序列号
• 序列号（sequence number）：在数据分组中添加一新字段，让发送方对其数据分组编号，即将发送数据分组的序号放在该字段。
  • 接收方只需要检查序号即可确定收到的分组是再一次重传
  • 几乎所有现有的数据传输协议中，包括 TCP，都采用了这种方法
  • 对于停等协议这种简单情况， 1 比特序号就足够了：因为它可让接收方知道发送方是杏正在重传前一个发送分组（接收到的分组序号与最近收到的分组序号相同），或是一个新分组（序号变化了，用模 2 运算"前向"移动）
  • 因为目前我们假定信道不丢失分组。ACK 和 NAK 分组本身不需要指明它们要确认的分组序号。 发送方知道所接收到的 ACK 和 NAK 分组（无论是否是含糊不清的）是为响应其最近发送的数据分组而生成的
• rdt 2.1 的发送方 FSM：
  
• rdt 2.1 的接收方 FSM：（corrupt：已变换的; 有缺陷的; 有错误的）
  

1.5 rdt 2.2：无 NAK 确认消息

• 真的需要两种确认消息（ACK+NAK）吗？—— rdt 2.2
  • 不发送 NAK ，而是对上次正确接收的分组发送一个 ACK（在 ACK 消息中显示地加入被确认分组在序列号）
  • 发送方接收到对同一个分组的两个 ACK ，就知道接收方没有正确接收到跟在被确认两次的分组后面的分组
  • 发送方收到重复的 ACK 后，同样重传当前分组
• rdt2. 1 和 rdt2.2 之间的细微变化在于，接收方此时必须包括由一个 ACK 报文所确认的分组序号，发送方和接收方的FSM片段如下：
  

1.6 rdt 3.0：有比特差错的丢包信道的可靠数据传输

现在假定除了比特受损外，底层信道还会丢包，这在今天的计算机网络(包括因特 网)中并不罕见。那么，怎样检测丢包以及发生丢包后该做些什么？

• 在 rdt 2.2 中已经研发的技术，如使用检验和、序号、 ACK 分组和重传等，使我们能给出后一个问题的答案，那么如何检测丢包呢？
• 让发送方负责检测和恢复丢包工作，当分组或者接收方对该分组的 ACK 发生了丢失时，发送方都收不到应当到来的接收方的响应。
• 发送方等待合理的时间（需要倒计时定时器，countdown timer），每发送一个分组(包括第一次分组和重传分组)时，便启动一个定时器。如果到时间了也没收到 ACK，则重传。
  • 注意，如果分组或 ACK 只是经过一个大的延迟而非丢失，发送方可能会重传该分组， 这就在发送方到接收方的信道中引人了冗余数据分组。幸运 的是，由 rdt 2.2 协议已经有足够的功能(即序号)来处理冗余分组情况。
• rdt 3.0 发送方的FSM（接收方略）：
  
• 因为分组序号在 0 和 1 之间交替，因此 rdt 3.0 有时被称为比特交替协议（alternating- bit protocol） 。