【计算机网络笔记】传输层——可靠数据传输原理之Rdt协议

系列文章目录

什么是计算机网络？
什么是网络协议？
计算机网络的结构
数据交换之电路交换
数据交换之报文交换和分组交换
分组交换 vs 电路交换
计算机网络性能（1）——速率、带宽、延迟
计算机网络性能（2）——时延带宽积、丢包率、吞吐量/率
计算机网络体系结构概念
OSI参考模型基本概念
OSI参考模型中非端-端层（物理层、数据链路层、网络层）功能介绍
OSI参考模型中端-端层（传输层、会话层、表示层、应用层）功能介绍
TCP/IP参考模型基本概念，包括五层参考模型
网络应用的体系结构
网络应用进程通信
网络应用对传输服务的需求
Web应用之HTTP协议（涉及HTTP连接类型和HTTP消息格式）
Cookie技术
Web缓存/代理服务器技术
传输层服务概述、传输层 vs. 网络层
传输层——多路复用和多路分用
传输层——UDP简介

---

---

文章较长，有4013字，建议收藏后慢慢品读

---

可靠数据传输原理

可靠数据传输是计算机网络的核心问题之一。

可靠指的是数据在传输的过程中不出错（比如不会发生某一位翻转的情况）、数据不丢失、分组的顺序不乱。

可靠数据传输依靠可靠数据传输协议。

我们需要认识到哪些因素导致信道的不可靠传输，才能解决问题。

我们将用Rdt这个缩写代替可靠数据传输。

可靠数据传输协议基本结构：接口。

下面来介绍可靠数据传输协议。我们循序渐进地来设计可靠数据传输协议的发送方和接收方。并且只考虑单向数据传输，但控制信息双向流动。此外，我们利用有限状态机(Finite State Machine, FSM)刻画传输协议。

• 用圆圈代表当前所处的状态，中间的箭头代表状态间的转换，箭头上有文字并且划有横线，横线上方写的是引起状态变迁的事件（event），横线下方写的是进行状态转换过程中要采取的活动（action）。

---

Rdt1.0：可靠信道

Rdt1.0研究在可靠信道上进行可靠数据传输。这是理想的状态。也就是说不会发生错误，也不会丢弃分组。

因为是可靠信道，所以发送方和接收方之间不需要进行控制信息的交换。发送方只需要发出去就好了，它知道数据会被可靠地传输。这样他俩之间没有交互信息，所以发送方和接收方的FSM独立。

发送方就一个状态，当上层调用rdt_send函数传来数据这个事件发生后，要采取一个活动，也就是创建packet分组然后调用信道上的udt_send将分组发出去。发出去之后由于确信分组会百分百正确地交付，所以就回到这个状态继续等待。

接收方也就一个状态，即等待下层的调用（rdt_rcv(packet)），然后提取数据交给上层，接着又回到等待状态。

---

Rdt2.0：产生位错误的信道

从2.0开始研究更贴近实际的情况，也就是不可靠信道上的可靠数据传输协议。

Rdt2.0研究这样的信道：可能产生位错误（比如0变1,1变0）的信道并且只可能产生这个错误。

要解决的问题：接收方首先需要判断数据是否出错，如果错了，需要重新传输数据。作为发送方，它是不知道分组在传输过程中是否出错的，需要接收方来告知。

• 辨别数据是否出现位错误：利用校验和检测位错误
• 从错误中恢复：
  • 引入确认机制(Acknowledgements, ACK)：接收方显式地告诉发送方是否已正确接收分组。如果正确接收，就是ACK；如果分组有错误就是NAK。
  • 发送方收到NAK后，重传分组。

基于这种ACK机制、NAK机制和重传机制的rdt协议称为ARQ(Automatic Repeat reQuest)协议。

总结Rdt2.0中引入的新机制：

• 差错检测
• 接收方反馈控制消息: ACK/NAK
• 重传

发送方现在有2个状态，一个是等待上层调用，一个是等待接收方控制消息。这种协议是停 —等协议。

接收方的状态只有一个：

Rdt2.1：应对ACK/NAK破坏

为什么要改进？也就是说Rdt 2.0有什么缺陷？要是控制消息出错怎么办？因为ACK和NAK在传给发送方的时候也是有可能出现位错误的，那么这个时候发送方就识别不了控制信息，就会发生死锁。

可能的解决方案：

• 为ACK/NAK增加校验和，检错并纠错。难度很高。
• 添加额外的控制消息。无法从根本上解决问题。因为这个额外的控制消息在传输过程中仍然可能会坏掉。
• 如果ACK/NAK坏掉，发送方重传。这是普遍使用的方法。但是这样可能会产生重复分组。所以需要采用一种机制解决分组重复的问题。

那怎么解决重复分组的问题？采用常用的解决方法：发送方给每个分组增加序列号。如果是重复的就丢弃。

所以Rdt2.1中解决了ACK/NAK被破坏的问题。

发送方的状态机状态变多了一倍：

接收方的状态机状态也多了一倍：

相比于Rdt2.0，Rdt2.1有了这些改进：

• 发送方：

  • 为每个分组增加了序列号，并且只要两个序列号(0, 1)就够用了
  • 需校验ACK/NAK消息是否发生错误
  • 状态数量翻倍，因为状态必须“记住” “当前”的分组序列号

• 接收方：

  • 需判断分组是否是重复
  • 注意：接收方无法知道ACK/NAK 是否被发送方正确收到

Rdt2.2：无NAK消息协议

我们真的需要两种确认消息(ACK + NAK)吗？
我们可以定义一种没有NAK消息的协议。

• 与rdt 2.1功能相同，但是只使用ACK
• 如何实现？
  • 接收方通过ACK告知最后一个被正确接收的分组
  • 在ACK消息中显式地加入被确认分组的序列号
  • 发送方收到重复ACK之后，采取与收到NAK消息相同的动作，也就是重传当前分组。

Rdt3.0

在Rdt2.0系列我们假设信道只可能发生位错误，那如果可可能丢失分组，怎么办？

“校验和 + 序列号 + ACK + 重传”不够用了。

处理的方法比较简单：发送方等待一个合理的时间

• 等待了一个合理的时间之后如果没收到ACK，就重传
• 需要定时器

但是停-等操作这个机制让Rdt协议的性能很差。还需要改进。这需要打破停-等协议。