TCP Early Retransmit RFC 5827：消除小窗口 RTO 停顿与优化 VPN 延迟

传输控制协议（TCP）的可靠性建立在能够准确区分网络数据包乱序与真实丢包的检测机制之上。经典拥塞控制核心算法快速重传（Fast Retransmit，RFC 5681）建立在一个基本假设上：网络传输管道中持续传输着充沛的数据流，足以驱动接收端产生源源不断的确认应答（ACK）。

在大文件传输等管道充盈的大窗口场景中，快速重传运行良好：三个连续的重复确认（Duplicate ACK，简称 DupACK）足以明确指示某个分段发生单点丢失，并在无需中断数据流的情况下立即触发重传。然而，在以突发短报文、轻量交互流以及受限于小拥塞窗口为特征的现代网络应用中，这一假设往往不再成立。

当一条 TCP 连接在网络中的在途数据包不足四个时，接收端回传的重复确认在物理上无法达到三个的固定阈值。整个传输管道陷入长时间死锁，直至粗粒度的重传超时计时器（Retransmission Timeout，RTO）耗尽—这通常会带来数百毫秒乃至整整一秒的严重延迟停顿。

互联网工程任务组（IETF）正式发布了 RFC 5827 规范，即 TCP 与 SCTP 的 Early Retransmit（早期重传）机制，旨在彻底消除这一延迟悬崖。通过在飞行数据量较小时动态下调重复确认的触发阈值，Early Retransmit 为延迟极其敏感的加密 VPN 与代理通道赋予了即时丢包恢复能力。

[标准快速重传机制：在途传输至少需要 4 个数据包]
发送端 ──[P1]──[P2]──[P3]──[P4]──> 接收端（P1 在中途发生丢包）
发送端 <──[Ack 1]──[DupAck 1]──[DupAck 2]──[DupAck 3]──（集齐 3 个 DupACK 立即重传 P1）

[未开启 RFC 5827 时的小窗口死锁：在途仅有 2 个数据包]
发送端 ──[P1]──[P2]──────────────> 接收端（P1 在中途发生丢包）
发送端 <──[Ack 1]──[DupAck 1]────（仅能产生 1 个 DupACK！无法触发快速重传）
        └─── 管道停顿冻结 ─────────> [被迫等待 200ms 至 1000ms 的 RTO 计时器超时！]

[RFC 5827 Early Retransmit 机制：动态确认阈值自适应]
发送端 ──[P1]──[P2]──────────────> 接收端（P1 在中途发生丢包）
发送端 <──[Ack 1]──[DupAck 1]────（FlightSize < 4*SMSS -> 阈值智能降至 1）
发送端 ──[即刻重传 P1]───────────>（毫秒级恢复！彻底杜绝 RTO 停顿）

小窗口困境：当快速重传在交互式流中失效

快速重传算法的设计初衷，是基于互联网上的分段乱序通常较为轻微、极少超出三个分段间距的工程观察。设定三个重复确认的硬性门槛，能够有效防止发送端因多路径路由或链路层并行传输带来的轻度乱序而发生不必要的虚假重传。

这项启发式策略保障了高吞吐批量传输的稳定性，但在交互式低并发场景中暴露出了结构性缺陷。

为何标准 TCP 快速重传强制要求三个重复 ACK

根据 RFC 5681 拥塞控制规范，每当接收端接收到序列号乱序到达的数据分段时，必须立即回传一个重复 ACK。该应答包携带接收端此前已按序连续接收的最高确认序号。

若要让发送端收集满三个重复 ACK，在丢失分段之后，链路上必须至少有三个后续数据包成功送达接收端：

$$\text{在途数据包总数下限} = 1\ (\text{丢失分段}) + 3\ (\text{后续到达分段}) = 4\ \text{个分段}$$

当发送端的拥塞窗口（$\text{CWND}$）或当前已发送但尚未确认的在途字节总量（$\text{FlightSize}$）小于 $4 \times \text{SMSS}$（发送端最大报文段长度）时，接收端无论如何也无法产生三个重复 ACK。在耗尽所有接收到的乱序包后，接收端最多只能产生一至两个应答。

重传超时机制对突发与低并发流量造成的延迟惩罚

一旦重复 ACK 数量无法达到三个，标准 TCP 栈便进入僵死等待状态。连接传输暂停，内核完全依赖按照 RFC 6298 计算的重传计时器（$RTO$）：

$$RTO = \text{SRTT} + \max(G, 4 \times \text{RTTVAR})$$

在主流生产环境中，Linux 内核为 $RTO$ 设定了 $200\text{ ms}$ 的硬性下限，而在较早期的网络实现中该值甚至高达 $1000\text{ ms}$。

对于依赖低延迟的实时交互流—例如 SSH 终端字符回显、API 远程过程调用、WebRTC 实时控制信令、DNS 加密查询或多人在线竞技数据流—长达 $200\text{ ms}$ 到 $1000\text{ ms}$ 的突发停顿会导致灾难性的体验崩溃。用户可直观感受到界面卡顿冻结，并在 VPN 隧道内引发明显的时延抖动与缓冲膨胀。

RFC 5827 Early Retransmit 的架构与协议机制

RFC 5827 通过引入动态门限，允许发送端在探测到当前在途容量不足以产生三个 DupACK 时，自适应调低触发重传的门槛，从而根除这一痛点。

基于在途数据量的动态确认阈值自适应调整

当发送端接收到新的确认包时，会实时评估当前网络中未确认的数据总量。若在途数据处于低水位区间，Early Retransmit 算法立即动态重算重传门槛：

1. 在途容量评估： 若 $\text{FlightSize} < 4 \times \text{SMSS}$，发送端判定接收端已不可能生成三个重复 ACK。
2. 动态调整阈值： 将所需的重复确认触发阈值（$ER\text{_threshold}$）设置为剩余在途分段所能激发的最大重复确认数量： $$ER\text{_threshold} = \left\lfloor \frac{\text{FlightSize} - 1}{\text{SMSS}} \right\rfloor$$
   • 当 $\text{FlightSize} = 3 \times \text{SMSS}$ 时，设置 $ER\text{_threshold} = 2$。
   • 当 $\text{FlightSize} = 2 \times \text{SMSS}$ 时，设置 $ER\text{_threshold} = 1$。
3. 无挂起新数据前提： Early Retransmit 仅在发送套接字缓冲区中没有新的待发数据时激活。若应用程序持续提交了新数据，发送端将优先依照 Limited Transmit（RFC 3042）发送新分段，尝试通过常规方式凑足三个 DupACK 恢复。

基于分段与基于字节的 Early Retransmit 实现对比

RFC 5827 规范定义了两种针对不同协议栈能力的实现方案：

• 基于分段的 Early Retransmit： 面向未协商选择性确认（SACK）选项的 TCP 连接。发送端单纯统计在途分段的数量，当收到的重复 ACK 数达到剩余分段数时触发重传。
• 基于字节的 Early Retransmit： 面向启用了 SACK（RFC 2018）的高性能现代 TCP 栈。发送端依据 SACK 块中反馈的精确字节区间进行严谨判定。一旦 SACK 明确指示缺失序列号之后的所有已发在途字节均已完整到达对端，发送端便毫无歧义地立即发起早期重传。

现代 Linux 内核普遍采用了基于字节的实现方案，因为当前全球网络连接中 SACK 的协商比例已超过 99%。

与 SACK 的深度协同及误重传防御体系

降低重复确认的触发门槛，客观上放大了将网络乱序误判为丢包的潜在概率。如果某个数据包仅因路由器多核队列调度延迟了数毫秒，降至 1 的阈值可能导致不必要的重复带宽消耗。

RFC 5827 构建了完备的防御逻辑，有效兼顾了响应速度与传输稳健性。

利用选择性确认精准定位缺失的数据序列

在启用 SACK 之后，接收端能够在 TCP 报头选项中附带精确的乱序数据块范围。假设在三包突发传输场景中：

发送端依次发出：分段 1（Seq 1000-2000）、分段 2（Seq 2000-3000）、分段 3（Seq 3000-4000）
分段 1 在传输路径中丢弃。
接收端收到分段 2 -> 响应：Ack 1000，SACK [2000-3000]
接收端收到分段 3 -> 响应：Ack 1000，SACK [2000-4000]

当收到第二个重复 ACK 时，发送端通过 SACK 块清楚获知分段 1 后续的整整 2000 字节均已完好送达。鉴于本次在途总量仅为 3000 字节，发送端可断定网络中已无任何其他在途包。继续干等第三个重复 ACK 没有任何工程价值，Early Retransmit 立即就地重传分段 1。

借助 Early Retransmit 延迟计时器抑制乱序干扰

为了在存在微秒级微乱序的复杂链路中防止误触发，现代 Linux 实现为 Early Retransmit 引入了一个微型延迟计时器。

当重复 ACK 满足自适应阈值条件时，内核并不立刻发出重传报文，而是启动一个基于平滑往返时间的短暂防乱序计时器：

$$\text{ER_Delay} = \frac{\text{SRTT}}{4}$$

若乱序分段随后抵达对端，且弥合数据空洞的 ACK 确认包在 $\text{ER_Delay}$ 结束前返抵发送端，内核便自动取消重传。若计时器超时仍未收到确认，则确认该包真实丢失，立即执行重传。该混合机制在彻底阻断 RTO 超时的同时，保留了对乱序波动的免疫力。

加密网络隧道环境下的延迟与吞吐量动态

将数据流封装于 WireGuard、IPsec ESP 或 OpenVPN 等加密隧道中，会显著重塑传输层的动力学特征。外层额外追加的 IP、UDP 以及安全载荷头部会压缩有效最大报文分段长度（MSS），并增大潜在的分片概率。

消除 VPN 封装连接中的 RTO 尾部延迟尖峰

在蜂窝基站移动切换、公共无线 Wi-Fi 以及跨洋长途骨干网上，数据丢包往往以短促、分散的形式突发出现。

在未开启早期重传的普通连接中，一旦小窗口内发生单包丢失，用户端会遭遇明显的画面卡死。更为严重的是，RTO 超时强制将拥塞窗口重置为 1 个报文段（$\text{CWND} = 1$），使连接退化至慢启动阶段，导致带宽恢复过程极其缓慢。

RFC 5827 成功将连接维持在快速恢复状态，仅使窗口减半而非归零，保障了隧道吞吐量的平稳输出。

企业级内核架构：RiceGuard 主动传输栈调优实践

诸多常见 VPN 客户端仅将底层操作系统网络栈视作不可调控的黑盒，任由加密报文遵循针对局域网千兆有线环境预设的内核默认参数传输。

VPNRice 旗下的 RiceGuard 核心传输引擎对服务端边缘网关与客户端传输栈实施了全链路精细化定制优化：

[应用程序高交互流]
   (SSH / HTTPS / API / 竞技互动)
              │
              ▼  (突发性小窗口在途传输)
[RiceGuard TCP 加速引擎层]
   ├── 强制启用 RFC 5827 字节级 Early Retransmit
   ├── 协同 SACK 救援传输机制与 DSACK 异常检测
   ├── 自适应 ER Delay Timer（SRTT/4 乱序防护）
   └── 深度适配 BBRv3 与 CUBIC 平滑步调控制
              │
              ▼  (根除小窗口丢包引发的 RTO 悬崖)
[加密安全传输隧道]
   (WireGuard / IPsec ESP / ChaCha20-Poly1305)

1. 全面推行 RFC 5827 规范： RiceGuard 节点全量启用基于字节的早期重传与自适应延迟机制，彻底杜绝轻量交互流跌入 200 毫秒 RTO 深渊。
2. 选择性确认协议协同： RiceGuard 全面对齐隧道内外层报文对 RFC 2018 SACK 及 RFC 2883 重复 SACK（DSACK）的支持，确保内核能够精细区分报文丢失与网络多径重传。
3. 主动报文步调与队列优化： 将 Early Retransmit 与公平队列（FQ/CoDel）紧密结合，有效熨平突发短报文在无线基站队列中的聚集效应，大幅压低越区切换时的丢包概率。

诊断审计与验证：利用套接字统计指标监控 Early Retransmit

系统管理员与网络工程师可以通过 Linux 原生内核接口，直接审计网关与终端节点上 RFC 5827 的生效状态。

查询主机当前的 Early Retransmit sysctl 内核控制参数：

# 查看系统当前的 TCP Early Retransmit 配置值
sysctl net.ipv4.tcp_early_retrans

# 参数释义：
# 0：禁用
# 1：启用基于分段的 Early Retransmit
# 2：启用基于字节的 Early Retransmit
# 3：启用基于字节且携带自适应延迟计时器的 Early Retransmit（现代 Linux 推荐模式）

若需启用最推荐的带延迟计时器字节级早期重传模式，可执行以下命令：

# 配置 RFC 5827 并开启自适应防乱序延迟控制
sudo sysctl -w net.ipv4.tcp_early_retrans=3

若要实时分析活跃 TCP 连接并验证早期重传机制是否已投入工作，可借助 ss 工具获取套接字内部指标：

# 检查目标连接的内部 TCP 传输指标与重传统计
ss -ti dst 198.51.100.1

在输出详情中重点观察 early_retrans 计数器以及 retrans 比例。该数值的增长配合极低的 RTO 超时计数，充分验证了传输栈正在实时拦截并就地修复微窗口下的丢包，稳固支撑着高品质的在线交互体验。

获取 VPNRice。