从停等协议到ARQ：手把手图解RDT协议如何一步步实现可靠数据传输（附状态机详解）
从停等协议到ARQ：手把手图解RDT协议如何一步步实现可靠数据传输（附状态机详解）
在计算机网络的运输层中，可靠数据传输（Reliable Data Transfer，RDT）协议是确保数据完整、有序传输的核心机制。想象一下，当你在线传输一份重要文件时，如何确保每个比特都准确无误地到达目的地？这正是RDT协议要解决的根本问题。本文将采用图解+状态机推演的方式，带您从零开始构建可靠传输系统，特别适合计算机网络初学者和需要夯实底层原理的开发者。
1. 可靠传输的基础框架
任何可靠传输系统都建立在三个核心机制上：
- 差错检测：通过校验和（checksum）或循环冗余校验（CRC）识别数据损坏
- 接收方反馈：使用ACK（确认应答）和NAK（否定应答）机制
- 重传机制：当检测到错误或超时时触发数据重发
提示：可靠传输协议的设计遵循"逐步完善"原则，每个版本只解决一个核心问题
我们先定义协议中的基本角色：
发送方(sender) → [不可靠信道] → 接收方(receiver)2. RDT1.0：理想信道的简化模型
2.1 基本假设与状态机
RDT1.0假设信道完全可靠（无差错、不丢包、不重复），此时只需最简单的单向传输：
stateDiagram-v2 [*] --> 发送方等待调用 发送方等待调用 --> 发送数据: rdt_send(data) 发送数据 --> 发送方等待调用: udt_send(packet) [*] --> 接收方等待到达 接收方等待到达 --> 交付数据: rdt_rcv(packet) 交付数据 --> 接收方等待到达: deliver_data(data)2.2 关键操作流程
发送方伪代码示例：
def rdt_send(data): packet = make_pkt(data) # 封装数据包 udt_send(packet) # 通过不可靠信道发送接收方伪代码示例：
def rdt_rcv(packet): data = extract(packet) # 解包数据 deliver_data(data) # 交付给上层应用3. RDT2.0：应对比特差错
3.1 ARQ机制引入
当信道可能出现比特差错时，需要引入**自动重传请求（ARQ）**三要素：
- 差错检测：接收方通过校验和检测错误
- 接收方反馈：发送ACK/NAK控制报文
- 重传：收到NAK时重新发送数据包
3.2 状态机演进
发送方新增"等待ACK/NAK"状态：
stateDiagram-v2 [*] --> 等待上层调用 等待上层调用 --> 等待ACK: 发送数据包 等待ACK --> 等待上层调用: 收到ACK 等待ACK --> 等待ACK: 收到NAK(重传)接收方状态变化：
stateDiagram-v2 [*] --> 等待下层到达 等待下层到达 --> 等待下层到达: 发送ACK(校验通过) 等待下层到达 --> 等待下层到达: 发送NAK(校验失败)3.3 典型问题场景
考虑以下异常情况时序：
- 发送方发送分组0
- 接收方检测到比特错误 → 返回NAK
- 发送方重传分组0
- 接收方正确接收 → 返回ACK
- ACK传输中受损 → 发送方无法区分是ACK还是NAK受损
4. RDT2.1：解决ACK/NAK歧义
4.1 序列号引入
通过1比特序列号（0/1交替）解决两个关键问题：
- 区分原始传输和重传
- 检测重复分组
发送方状态机改进：
stateDiagram-v2 [*] --> 等待上层调用0 等待上层调用0 --> 等待ACK0: 发送seq=0 等待ACK0 --> 等待上层调用1: 收到ACK0 等待ACK0 --> 等待ACK0: 收到NAK/超时(重传) 等待上层调用1 --> 等待ACK1: 发送seq=1 等待ACK1 --> 等待上层调用0: 收到ACK1 等待ACK1 --> 等待ACK1: 收到NAK/超时(重传)4.2 接收方处理逻辑
接收方需要维护预期序列号：
expected_seq = 0 def rdt_rcv(packet): if corrupt(packet): send(NAK) elif get_seq(packet) == expected_seq: deliver_data(extract(packet)) send(ACK) expected_seq = 1 - expected_seq # 切换预期序列号 else: send(ACK) # 对重复分组发送ACK5. RDT2.2：NAK消除优化
5.1 纯ACK方案
通过带序列号的ACK替代NAK：
- 对正确接收的分组n返回ACKn
- 对错误分组返回ACK(n-1)
发送方判断逻辑：
if received_ACK == current_seq: # 成功传输，准备下一分组 current_seq = 1 - current_seq else: # 需要重传 resend_packet()5.2 协议优化对比
| 版本 | 控制报文类型 | 序列号 | 重传触发条件 |
|---|---|---|---|
| 2.0 | ACK/NAK | 无 | NAK或超时 |
| 2.1 | ACK/NAK | 1-bit | NAK或超时 |
| 2.2 | ACK-only | 1-bit | 冗余ACK或超时 |
6. RDT3.0：处理丢包问题
6.1 定时器机制
引入倒计数定时器解决：
- 数据包丢失
- ACK丢失
- 过度延迟
发送方伪代码增强：
def rdt_send(data): packet = make_pkt(next_seq, data, checksum) udt_send(packet) start_timer(next_seq) # 为每个分组启动独立定时器 def timeout(seq): resend_packet(seq) start_timer(seq) # 重启定时器6.2 完整状态变迁
发送方最终状态机：
stateDiagram-v2 [*] --> 等待调用0 等待调用0 --> 等待响应0: 发送seq=0+启动定时器 等待响应0 --> 等待调用1: 收到ACK0 等待响应0 --> 等待响应0: 超时/ACK1(重传) 等待调用1 --> 等待响应1: 发送seq=1+启动定时器 等待响应1 --> 等待调用0: 收到ACK1 等待响应1 --> 等待响应1: 超时/ACK0(重传)6.3 性能优化技巧
- 自适应超时间隔：根据网络状况动态调整
- 选择性重传：只重传真正丢失的分组
- 累计确认：允许单个ACK确认多个分组
在实际项目中，我曾遇到定时器间隔设置不当导致吞吐量下降50%的情况。通过Wireshark抓包分析发现，将默认100ms超时调整为动态计算RTT+4*DevRTT后，性能得到显著提升。