从停等协议到可靠传输：手把手图解RDT 1.0到3.0的演进之路
在分布式系统的世界里，数据就像穿越崇山峻岭的信使，而可靠数据传输协议（RDT）就是确保这些信使安全抵达目的地的护卫队。想象一下，当你点击发送按钮的那一刻，你的数据包将经历怎样的冒险旅程？本文将带你深入RDT协议的演进历程，通过状态机和数据流图解，揭示从理想信道到现实网络的可靠性保障机制。
1. 可靠数据传输的基础概念
可靠数据传输协议（Reliable Data Transfer Protocol）是计算机网络运输层的核心技术之一，它确保数据能够完整、有序地从发送方传递到接收方。就像快递服务需要签收确认一样，RDT通过各种确认机制保证每个数据包都能被正确接收。
在协议设计中，我们主要面临三类挑战：
- 比特差错：数据在传输过程中某些比特位可能发生反转（0变1或1变0）
- 丢包：数据包或确认包在传输过程中完全丢失
- 乱序：数据包到达顺序与发送顺序不一致
早期的RDT协议采用停等机制（Stop-and-Wait），即发送方每发送一个数据包后必须等待确认，才能发送下一个。这种简单但低效的方式，为我们理解可靠传输提供了绝佳的教学模型。
2. RDT 1.0：理想信道的乌托邦
2.1 基本假设与设计
RDT 1.0建立在完美信道的假设上：
假设条件： 1. 信道不会丢失数据包 2. 传输过程不会产生比特差错 3. 数据包按发送顺序到达在这种理想情况下，协议设计极其简单。发送方和接收方各自只需维护一个状态：
发送方状态机：
等待上层调用 → 发送数据 → 等待上层调用接收方状态机：
等待下层调用 → 接收数据 → 等待下层调用2.2 数据流动图解
数据流动过程可以用以下伪代码表示：
# 发送方 def rdt_send(data): packet = make_pkt(data) # 封装数据包 udt_send(packet) # 通过不可靠信道发送 # 接收方 def rdt_rcv(packet): data = extract(packet) # 提取数据 deliver_data(data) # 交付给上层注意：这里的udt_send表示通过"不可靠数据传输"发送，但实际上在RDT 1.0中我们假设信道完全可靠
虽然RDT 1.0在实际中几乎无用武之地，但它确立了协议的基本框架，为后续版本演进奠定了基础。
3. RDT 2.0：应对比特差错的首次尝试
3.1 引入确认机制
当考虑比特差错时，RDT 2.0引入了ARQ协议（Automatic Repeat Request）的核心机制：
- ACK（肯定确认）：接收方正确接收数据后发送
- NAK（否定确认）：接收方检测到比特差错时发送
- 重传：发送方收到NAK后重新发送数据包
状态机复杂度显著增加：
发送方状态：
等待上层调用 → 发送数据 → 等待ACK/NAK ↑_______________|3.2 校验和计算示例
比特差错通过校验和检测，以下是简化的16位校验和计算过程：
def compute_checksum(data): total = 0 for word in data: total += word if total > 0xFFFF: # 处理溢出 total = (total & 0xFFFF) + 1 return ~total & 0xFFFF # 取反接收方验证时，将所有数据（包括校验和）相加，正确结果应为0xFFFF。
3.3 协议缺陷分析
尽管RDT 2.0能处理数据包的比特差错，但它存在一个致命缺陷：ACK/NAK本身也可能出错。当确认信号受损时，发送方无法确定接收方实际接收状态，导致协议失效。
4. RDT 2.1：序列号解决确认歧义
4.1 引入序列号机制
RDT 2.1通过1位序列号（0和1交替）解决了确认歧义问题：
- 每个数据包携带序列号
- ACK也包含对应序列号
- 接收方缓存最近正确接收的数据包
发送方状态机新增逻辑：
if 收到ACK(seq): if seq == 当前序列号: 发送下一个数据包 else: 重传当前数据包4.2 接收方处理冗余分组
接收方需要处理三种情况：
- 数据包正确且序列号匹配：交付数据，发送ACK
- 数据包正确但序列号不匹配：丢弃（冗余），发送ACK
- 数据包错误：丢弃，不响应
这种设计确保即使ACK/NAK受损，发送方也能通过序列号判断是否需要重传。
5. RDT 2.2：优化确认机制
5.1 去除NAK的设计
RDT 2.2进一步优化，完全取消了NAK：
- 对正确接收的数据：发送带序列号的ACK
- 对错误或冗余数据：发送上一个正确接收数据的ACK
发送方逻辑调整：
if 收到ACK(seq): if seq == 期待序列号: 发送新数据 else: 重传当前数据这种设计减少了报文类型，简化了协议实现，同时保持了相同的可靠性。
6. RDT 3.0：应对丢包的终极方案
6.1 引入定时器机制
现实网络中最大的挑战是丢包。RDT 3.0通过超时重传解决这个问题：
- 发送数据后启动定时器
- 超时未收到ACK则重传
- 接收方处理逻辑与RDT 2.2相同
发送方伪代码示例：
def rdt_send(data): packet = make_pkt(seq, data, checksum) udt_send(packet) start_timer() wait_for_ack() def handle_timeout(): udt_send(last_packet) # 重传 start_timer()6.2 定时器时长设置
定时器时长是关键参数，需要考虑：
- 典型RTT（往返时间）：从发送到收到ACK的平均时间
- RTT波动范围：网络延迟的变化程度
- 过早超时：会导致不必要的重传
- 过晚超时：降低传输效率
在实际实现中，通常采用指数退避算法动态调整超时时间。
6.3 协议性能分析
虽然RDT 3.0实现了可靠传输，但停等机制导致效率低下：
传输效率 = (数据包大小 / (数据包大小 + 2*RTT*带宽))例如在1Gbps链路、100ms RTT下传输1KB数据，效率仅为0.04%。这促使了后续滑动窗口协议的发展。
7. 状态机设计与协议实现
7.1 发送方完整状态机
RDT 3.0发送方状态机可以用以下表格表示：
| 当前状态 | 事件 | 动作 | 下一状态 |
|---|---|---|---|
| 等待上层调用 | rdt_send(data) | 发送分组，启动定时器 | 等待ACK0 |
| 等待ACK0 | 超时 | 重传分组，重启定时器 | 等待ACK0 |
| 等待ACK0 | 收到ACK(0) | 停止定时器 | 等待上层调用 |
| 等待ACK0 | 收到ACK(1) | 无动作 | 等待ACK0 |
| ...（ACK1对称状态）... | ... | ... | ... |
7.2 接收方状态机设计
接收方状态机同样基于序列号：
| 当前状态 | 事件 | 动作 | 下一状态 |
|---|---|---|---|
| 等待0 | 收到分组(0)且正确 | 交付数据，发送ACK(0) | 等待1 |
| 等待0 | 收到分组(1)且正确 | 发送ACK(1) | 等待0 |
| 等待0 | 收到分组错误 | 发送ACK(1) | 等待0 |
| 等待1 | ...（对称逻辑）... | ... | ... |
这种状态机设计确保了协议在各种异常情况下的可靠性。
8. 从理论到实践的思考
在实际网络编程中，虽然现代协议如TCP已经实现了更高效的可靠传输，但理解RDT的演进过程仍然价值非凡。它揭示了可靠传输的核心问题和解法，是理解复杂协议的钥匙。
几个值得注意的实现细节：
- 校验和算法的选择直接影响差错检测能力
- 定时器管理是性能优化的关键点
- 序列号空间决定了协议的最大未确认分组数
- 缓冲区管理影响内存使用和吞吐量
通过Wireshark等工具观察TCP报文，你会发现许多RDT 3.0的影子，只是TCP通过滑动窗口和拥塞控制将其扩展到了更高性能的水平。
