可靠性数据传输原理

可靠指数据在传输过程中不错，不丢，不乱

运输层要为应用层提供一种服务：数据可以通过一条可靠的信道进行传输，在该信道中传输的数据不会受到损坏或者丢失, 实现这种服务的是可靠数据传输协议。

要实现这种服务并不简单，因为无法保证在运输层下的各层可以实现可靠传输，可靠数据传输协议的实现方式要在运输层下的各层都不可靠的前提下进行。

可靠数据传输协议：

1. 可靠数据传输对应用层、传输层、链路层都很重要
2. 信道的不可靠特性决定了可靠数据传输协议(rdt)的复杂性

RDT协议

• rdt在应用层，传输层和数据链路层都很重要。
• 信道的不可靠特点决定了可靠数据传输协议（rdt）的复杂性。
• rdt的下层协议是不可靠的，可能是出错的，丢失的，乱序的，rdt应该如何凭借自己的努力来保证可靠性呢？在下层提供的服务不可靠的情况下，向上层提供可靠的服务。

状态机：用来描述某一件事物的状态。

Rdt1.0

我们做出一个假设：我们假设信道是可靠的

• 下层的信道是完全可靠的
  • 没有比特出错
  • 没有分组丢失

那么此时就只有一种状态，发送方等待接收方的数据发送回来，发送方等待接收方的数据发送过去。因为数据是可靠的，这样就已经足够了。

Rdt2.0：具有比特差错的信道

我们开始假设了一些简单的不可靠的行为了：

例如下层的信道可能会出现比特翻转的情况。

这个情况其实很好解决，我们使用一个校验和，用校验和来检测就可以了。但是事情其实没有这么简单，我们引入了校验和之后，我的发送方如果知道是否发生了比特翻转呢？而且如果发生了比特翻转，我们如何从差错中恢复呢？

因此我们引入了确认应答机制。

ACK代表肯定确认（“OK”），NAK代表否定确认（“请重复一遍”）。

当收到ACK的时候就可以继续发送报文了，当收到NAK的时候代表数据损坏了，我们需要重新发送，基于这样重传机制的可靠数据传输协议称为自动重传请求协议（ARQ）。

因此Rdt2.0的状态机就会有些复杂了。

rdt2.0的致命缺陷 -> rdt2.1

我们的rdt2.0做出的假设是，只有发送过去的报文会损坏，但是没有考虑到一点，有没有可能，我ACK/NAK报文也损耗了，或者没有发送过去呢？

这当然有可能！！！

那我一个报文发送过去了，对方不给我任何回应，或者给了我一个我看不懂的回应，那么我现在应该怎么做呢？不重传可能会死锁或者出错。重传可能会出现数据的重复和冗余。

因此我们需要引入新的机制来解决这个问题了：

处理重复：

• 发送方在每个分组中加入序号
• 如果ACK/NAK出错，发送方重传当前分组
• 接收方丢弃（不发给上层）重复发呢组

停等阶段，发送方发送一个分组，然后等待接收方的应答

发送方状态机：

接收方状态机：

当然，这个状态机看看就行了，没有必要在这个状态机上面过多的纠缠，我们需要的是理清里面的逻辑就可以了。

我们来看一下rdt2.1是如何运行的：

rdt2.2：无NAK的协议

• 功能同rdt2.1，但只使用ACK（ack要编号）
• 接收方对最后正确接收的分组发ACK，以替代NAK
  • 接收方必须显式的包含被正确接收分组的序号
• 当收到重复的ACK（如：再次收到ack0）时，发送方与收到NAK采取相同的动作：重传当前分组
• 为后面的一次发送多个数据单位做一个准备
  • 一次能够发送多个
  • 每一个的应答都有：ACK，NACK：麻烦
  • 使用对前一个数据单位的ACK，代替本数据单位的NAK
  • 确认信息减少一半，协议处理简单

我们把ACK用序号排好，当前一个回复报文的ACK表示的是上一次报文的序号，也就是序号不对应的话，那么我们就认为是失败了，NAK。

如图：

rdt3.0：具有比特差错和分组丢失的信道

新的假设：下层信道可能会丢失分组（数据或ACK）

• 会死锁
• 机制还不够处理这种状况：
  • 校验和
  • 序列号
  • ACK
  • 重传

方法：发送方等待ACK一段合理的时间：

• 发送端超时重传：如果到时候没有收到ACK -> 重传
• 问题：如果分组（或ACK）只是被延迟了：
  • 重传将会导致数据重复，但是利用序列号已经可以处理这个问题了
  • 接收方必须指名被正确接收的序列号
• 需要一个倒计时定时器

链路层的timeout时间确定的

传输层timeout时间是适应式的

我们来看一下rdt3.0是怎么运行的：

以上就是RDT协议的所有内容，关于RDT3.0的性能问题我们会作为滑动窗口协议的引子来讲解。