传输层——可靠数据传输概述

可靠数据传输原理

可靠数据传输原理的实现问题不仅出现在运输层，也会出现在链路层和应用层，如果要确定所有网络中最为重要的“前十个”问题排名的话，可靠数据传输原理将是名列榜首的候选者。

• 什么是可靠？不错、不丢、不乱
  下图是可靠数据传输的框架。为上层实体提供的服务抽象是：数据可以通过一条可靠的信道进行传输。借助可靠信道，传输数据比特就不会受到损坏或丢失，而且所有的数据都是按照其发送顺序进行交付的。
  
  image

实现这种服务抽象是可靠数据传输协议的责任。由于可靠数据传输协议的下层可能是不可靠的，因此只是一项困难的任务。然而，就我们而言，我们可以将较低层直接视为不可靠的点对点信道。

• 本次的讨论中渐进地设计可靠数据传输协议的发送方和接收方
• 只考虑单向数据传输，但是控制信息能够双向流动
• 利用状态机（FSM）刻画传输协议，FSM中的箭头指示了协议从一个状态变迁到另一个状态。引起变迁的时间显示在表示变迁的横线上方，事件发生时所采取的工作显示在横线下方；

构造可靠数据传输协议

rdt1.0:可靠信道上的可靠数据传输协议

• 底层信道完全可靠：不会发生错误（bit error），不会丢失分组，并且不会乱序；
• 发送方和接收方的FSM独立，不用进行数据交换

发送方FSM

image

接收方FSM

image

rdt2.0:产生位错误的信道

• 传输的过程中可能会产生位错误（比特位翻转）；
• 在该信道中仅有产生位错误这一种情况

此时我们底层信道不可靠，可能产生位错误，因此在接收方要判断是否产生错误，如果有错误需要进行恢复。在进行的恢复的过程中仅有接收方是无法解决的。

• 辨别分组中是否有错误：利用校验和检测位错误
• 如何从错误中恢复？
  • 确认机制（ACK）：接收方显示的告知发送方分组已正确接收；
  • NAK：接收方显示的告知发送方分组有错误
  • 发送发收到NAK后，重传分组

基于上述重传机制的rdt协议称为ARQ协议。因此通过与rdt1.0对比，rdt2.0中引入的新的机制主要有以下一些：

• 差错检测
• 接收方反馈信息： ACK/NAK
• 重传

下面是设计出的rdt2.0:FSM规约
发送方:

image

由于发送之后要处于一个等待对方控制消息的状态，因此这样的协议也称为停—等协议。
接收方:

image

rdt2.1:发送方应对ACK/NAK破坏

• rdt2.0存在缺陷：如果ACK/NAK消息发送错误、被破坏：

  • 为ACK/NAK增加校验和，检错并纠错：难度高；
  • 添加额外控制消息:额外控制信息可能坏掉；
  • 如果ACK/NAK坏掉，发送方重传：不能简单重传，可能产生重复分组

• 如何解决重复分组的问题？

  • 序列号：发送方给每个分组增加序列号
  • 接收方丢弃重复分组

发送方：

image

接收方：

image

rdt2.2：无NAK消息协议

与rdt2.1的功能相同，但是只使用ACK
实现方案：

• 接收方通过ACK告知最后一个被正确接收的分组；
• 在ACK消息中显示地加入被确认分组的序列号
• 发送方在接收到重复ACK之后，采取与收到NAK消息相同的动作：重传当前分组
  发送方：
  
  image
  
  接收方：
  
  image

rdt3.0: 信道既可能发生错误，也可能丢失分组

方法：发送方等待"合理"的时间

• 如果没有收到ACK,重传
• 但是此时又会有新的问题，合理的时间很确定，可能会有这样的情况：如果分组或者ACK只是延迟，并没有丢失。因此重传就会引起重复的问题，就需要之前的序列号的方案来解决。
  因此，在rdt3.0中我们需要增加定时器
  发送方：
  
  image
  
  此时对应于下面的几种情况：
  
  image

在这里插入图片描述

流水线可靠数据传输协议

上面设计出来的rdt3.0虽然能够正确的工作，但是性能很差。（关于性能具体的分析示例见《计算机网络——自顶向下方法》第六版P145）此时设计的协议限制了物理资源的利用，因此协议必须要和硬件资源匹配，在计算机科学中称为软硬件协同设计。
解决性能问题的一个简单方法就是不采用停等方式运行，允许发送发发送多个分组无需等待确认。如下图所示，如果发送方可以在等待确认之前就发送三个报文，其利用率基本上也会提高三倍。因为许多从发送方向接收方属性的分组被看成是填充到一条流水线中，故这种技术也被称为流水线。

image

流水线技术也将对可靠数据传输协议带来如下影响：

• 必须增加序号范围， 因为在每个传输中的分组（不计算重传的）必须有一个唯一的序号，而且也有许多在传输中未确认的报文；
• 协议的发送方和接收方也许必须缓存多个分组。发送方最低限度应当能缓冲哪些已发送但是没有确认的分组，接收方或许也需要缓存哪些已经已正确接收的分组；
• 所需的序号范围和对缓冲的要求取决于数据传输协议如何处理丢失、损坏及延迟过大的分组

要想实现流水线机制，需要滑动窗口协议(Sliding-window protocol)

• 窗口:允许使用的序列号范围；窗口尺寸为N:最多有N个等待确认的消息
• 滑动窗口：随着协议的运行，窗口在序列号空间内向前滑动
• 滑动窗口协议：回退N步(Go-Back-N, GBN）和选择重传（Select Repeat，SR)。