连续ARQ协议：提升网络传输效率的核心机制

1. 为什么我们需要连续ARQ协议？

在计算机网络的数据链路层中，错误控制是保证可靠传输的核心机制。想象一下你正在给朋友发一长串短信，如果每次发送后都要等待对方回复"收到"才能发下一条，这种"发一条等一次"的方式效率有多低下？这就是最基本的停止等待协议（Stop-and-Wait ARQ）的工作方式。

我在实际网络调试中发现，当网络延迟较高时（比如跨洋通信），这种简单协议的吞吐量会急剧下降。有次在调试中美服务器间的数据传输时，RTT（往返时间）高达300ms，即使信道带宽有100Mbps，实际有效吞吐量却不到1Mbps——99%的时间信道都处于空闲状态！

连续ARQ协议正是为了解决这个根本性效率问题而诞生的。它允许发送方在未收到确认的情况下连续发送多个数据帧，就像快递员可以一次带多个包裹出门，而不必每送一个就回站点报到一次。根据实现方式的不同，连续ARQ又分为回退N帧（Go-Back-N）和选择重传（Selective Repeat）两种主要变体。

关键区别：停止等待协议每次只能有一个未确认帧在空中传输，而连续ARQ通过滑动窗口机制允许同时存在多个传输中的帧。

2. 连续ARQ的核心工作机制

2.1 滑动窗口：协议的心脏

滑动窗口是连续ARQ的灵魂所在。发送窗口（Sender Window）和接收窗口（Receiver Window）就像两个协同工作的闸门：

• 发送窗口大小（Ws）决定了能连续发送的未确认帧最大数量
• 接收窗口大小（Wr）决定了接收方能缓存的乱序帧数量

在Go-Back-N中，Wr固定为1，意味着接收方只能按顺序接受帧。任何乱序到达的帧都会被直接丢弃，导致发送方必须回退重传整个窗口。而Selective Repeat允许Wr>1，接收方可以缓存乱序帧，只需请求重传特定丢失帧。

我在实验室用Wireshark抓包分析时，曾看到这样的序列：

code复制发送方: 帧1 | 帧2 | 帧3 | 帧4 | 帧5  
接收方: ACK1 | 帧2丢失 | ACK3(被丢弃) | 超时后重传帧2-5

这就是典型的Go-Back-N行为——尽管帧3到达了，但因为帧2丢失，整个窗口都要回退。

2.2 序列号空间的数学约束

序列号位数（n）与窗口大小存在严格数学关系：

• Go-Back-N要求 Ws ≤ 2ⁿ - 1
• Selective Repeat要求 Ws + Wr ≤ 2ⁿ

这是因为序列号空间必须足够大，才能避免"前一轮"和"后一轮"帧的序列号混淆。有次我配置了一个n=3位（序列号0-7）的Selective Repeat实现，当把Ws和Wr都设为4时，就出现了严重的歧义错误——新帧和重传帧的序列号完全无法区分。

3. Go-Back-N vs Selective Repeat实战对比

3.1 性能差异的真实测试数据

我在Linux环境下用tc命令模拟了不同丢包率的网络环境，测试结果令人深思：

可以看到在高丢包环境下，Selective Repeat的优势更加明显。但代价是实现复杂度更高——接收方需要维护帧缓存队列，发送方要支持选择性重传。

3.2 开发中的典型实现陷阱

在实现Selective Repeat时，我曾踩过几个坑：

1. 定时器管理：每个帧都需要独立的超时定时器，而不是整个窗口共用一个。初期我错误地使用单一计时器，导致性能反而比Go-Back-N还差。

2. 窗口滑动条件：只有收到窗口最前端帧的ACK才能滑动窗口。有次错误设计为收到任何ACK都滑动，结果导致窗口失去同步。

3. 缓冲区溢出：忘记限制重传队列大小，在极端网络条件下内存暴涨。后来我增加了这样的保护逻辑：

c复制while (retrans_queue.size() > MAX_QUEUE) {
    wait_for_ack(); 
    // 等待部分ACK释放队列空间
}

4. 现代网络中的连续ARQ变体

4.1 TCP的混合方案

虽然TCP不是严格意义上的连续ARQ，但它吸取了两者的精华：

• 类似Selective Repeat：通过SACK（Selective ACK）选项实现部分重传
• 类似Go-Back-N：快速重传机制在收到三个重复ACK时立即重传

通过ss -i命令查看Linux TCP连接时，可以看到这样的信息：

code复制skmem:(r0,rb12582912,t0,tb12582912,f0,w0,o0,bl0)

其中rb和tb分别是接收和发送缓冲区大小，直接影响窗口尺寸。

4.2 QUIC协议的革新

新一代QUIC协议在UDP基础上实现了更灵活的ARQ机制：

• 每个数据流独立的重传逻辑
• 前向纠错（FEC）与ARQ的协同
• 包号（Packet Number）永远递增，避免序列号回绕问题

我在测试HTTP/3时抓到的QUIC包显示：

code复制Packet Number: 15 (retransmission)
Frame Type: STREAM
Stream ID: 3
Offset: 6144
Length: 1024

这种设计使得重传可以精确到特定流的特定数据段。

5. 调试连续ARQ的实用技巧

5.1 Wireshark过滤技巧

这些显示过滤器特别有用：

code复制tcp.analysis.retransmission  # 显示TCP重传
tcp.analysis.duplicate_ack   # 重复ACK
tcp.window_size < 1024       # 小窗口问题

5.2 Linux内核参数调优

对于高延迟网络，可以调整：

bash复制sysctl -w net.ipv4.tcp_window_scaling=1  # 启用窗口缩放
sysctl -w net.ipv4.tcp_sack=1            # 启用SACK
sysctl -w net.ipv4.tcp_fack=1            # 启用FACK

5.3 模拟测试环境搭建

使用tc和netem工具模拟网络条件：

bash复制# 添加100ms延迟+10%丢包
tc qdisc add dev eth0 root netem delay 100ms loss 10%

# 限制带宽为10Mbps
tc qdisc change dev eth0 root tbf rate 10mbit burst 32kbit latency 400ms

6. 从理论到实践的关键跨越

理解连续ARQ协议最难的部分不是算法本身，而是现实世界中的各种边界条件。有次我们的系统在连续运行48天后突然出现通信故障，最终发现是32位序列号回绕（wrap-around）问题。解决方案是在比较序列号时使用这样的技巧：

c复制// 安全比较序列号a和b，考虑回绕情况
#define SEQ_LT(a,b) ((int32_t)((a)-(b)) < 0)  
#define SEQ_LEQ(a,b) ((int32_t)((a)-(b)) <= 0)

另一个常见误区是忽视MTU的影响。我曾经花了三天追踪一个"随机"丢包问题，最后发现是路径中某个节点的MTU比我们测试帧小100字节，导致IP分片被某些防火墙丢弃。现在我的检查清单里永远包括：

1. 端到端MTU一致性检查（使用ping -M do -s）
2. 确认DF（Don't Fragment）标志位设置
3. 检查所有中间设备的ICMP不可达消息是否被过滤