TCP PRR RFC 6937：比例速率缩减、FlightSize 调步与低延迟 VPN

在高速加密传输通道与企业级虚拟专用网络中，传输控制协议 (TCP) 承担着承载上层数据的关键职责。当数据报文穿透多跳公共互联网路由、移动蜂窝基站或存在物理衰减的 Wi-Fi 链路时，偶发性丢包难以避免。传输层应对报文丢失的算法逻辑，直接决定了终端应用是感知到一次平稳的微小延迟，还是遭遇连接彻底冻结并伴随严重的缓冲膨胀 (Bufferbloat)。

在过去近二十年中，网络栈普遍依赖 RFC 3517 与 RFC 5681 所定义的传统快速恢复 (Fast Recovery) 机制。这类旧机制存在明显的结构性缺陷：一旦检测到丢包，发送端便会陷入数个往返时延的彻底静默，随后又突然注入大批突发报文。IETF 颁布的 RFC 6937 标准确立了比例速率缩减 (Proportional Rate Reduction, PRR) 算法，通过在整个恢复周期内以动态比例平滑分配发送节拍，消除了人为造成的传输停滞。

管道气泡困境：传统快速恢复机制为何导致高速 TCP 停滞

在传统 TCP 拥塞控制模型中，接收端连续反馈三个重复确认 (Duplicate ACK) 即意味着网络通路无法承载当前的拥塞窗口 (CWND)。协议栈通过将 CWND 折半（或乘以系数）来设立新的慢启动阈值 (ssthresh)。尽管降低发包速率是缓解中间路由器队列压力的必要手段，但旧算法粗暴的实现方式带来了严重的副作用。

根据 RFC 3517 规范，发送方持续追踪在途未确认数据量 (FlightSize)。当丢包发生时，当前 FlightSize 往往显著超出折半后的 ssthresh：

检测到丢包事件：
  初始状态：CWND = 40 个报文，FlightSize = 40 个报文
  目标状态：ssthresh = 20 个报文

传统快速恢复动作：
  发送端彻底停止发送任何新报文，等待在途数据自然耗尽。
  静默持续时间：约半个完整往返时延 (0.5 * RTT)。

这种完全停滞的静默期在网络管道中形成了一个明显的“管道气泡”(Pipeline Bubble)。在长达半个 RTT 的时间里，发送端没有任何数据输出，瓶颈路由器的排队缓存被瞬间抽空。而一旦 FlightSize 衰减至 ssthresh 之下，发送端又会瞬间倾泻出一大批连续紧挨着的报文。这种突发流量会重新填满并溢出刚排空的路由器队列，引发次生连续丢包并导致严重的超时重传 (RTO)。在加密网络隧道中，这种停顿会导致音视频通话画面冻结、游戏指令出现数百毫秒的严重跳跃。

RFC 6937 数学模型解析：比例速率缩减 (PRR) 核心算法

RFC 6937 用持续的比例调步完全取代了停滞断流机制。PRR 不再静止等待 FlightSize 跌落，而是在每次收到包含新数据的选择性确认 (SACK) 时，允许发送端发出按比例折算的数据报文，在整个丢包恢复期内平稳收敛至 ssthresh。

PRR 算法在状态机中维护两项核心度量：

• prr_delivered：自进入恢复期以来，通过 SACK 确认为成功送达的新数据总量。
• prr_out：自进入恢复期以来，发送端已注入网络的新报文或重传报文总量。

在每次处理确认应答时，PRR 依据比例缩减公式计算允许发出的字节配额：

Target_Ratio = ssthresh / RecoverFS
sndcnt = ceil(prr_delivered * Target_Ratio) - prr_out

其中 RecoverFS 代表刚捕获丢包瞬间的初始在途数据量。若 ssthresh 被设定为 RecoverFS 的一半，则目标比率 Target_Ratio = 0.5。这意味着对端每成功确认接收 2 个字节，本端便立即平滑发射 1 个字节的数据。数据传输从未中断，队列以确定性的斜率稳步排空，管道始终保持饱满通畅。

边界动态分析：对比 PRR-CRB 与 PRR-SSRB 双运行模式

虽然理想比例公式适用于绝大多数标准网络场景，但真实世界中往往伴随着确认包到达不均、重传包二次丢失以及乱序送达等恶劣工况。为了保证全场景下的鲁棒性，RFC 6937 设计了两种互补的边界模式：保守速率边界 (CRB) 与慢启动缩减边界 (SSRB)。

+-------------------------------------------------------------+
|                  TCP 协议栈处理收到之 ACK 报文               |
+-------------------------------------------------------------+
                               |
                               v
               [条件判断：FlightSize > ssthresh?]
                /                                     是                         否
              /                                        v                             v
+---------------------------+  +------------------------------+
|     标准 PRR 或 CRB 模式   |  |        PRR-SSRB 提速模式     |
| sndcnt = min(PRR, Deliv)  |  | sndcnt = min(Deliv+1, Target)|
+---------------------------+  +------------------------------+

针对严重丢包与乱序场景的保守速率边界 (CRB)

在面临严重丢包或 ACK 滞留时，在途数据量 FlightSize 可能会长期居高不下。此时若继续激进发包，将加剧网络拥塞。PRR-CRB 作为严格的安全限速锁介入：

sndcnt = min(sndcnt, Delivered_Data)

PRR-CRB 强制约束发送字节不得超过本轮 ACK 所明示确认交付的数据量。通过将发包速率严格锚定在对端排空的物理吞吐量上，CRB 杜绝了发端自发引起的排队恶化，有效平抑乱序震荡。

针对低延迟交互式业务的慢启动缩减边界 (SSRB)

与严重丢包相反，某些偶发性丢包可能导致 FlightSize 骤降至远低于 ssthresh 的水平（例如突发丢包或移动基站切换）。传统算法在面对过小的窗口时往往采取逐包探测，导致吞吐恢复极为迟缓。

PRR-SSRB 模式感知到 FlightSize < ssthresh 时，允许适度的受控慢启动加速：

sndcnt = min(prr_delivered - prr_out + ssthresh - FlightSize, Max_Burst)

SSRB 允许发送端在每确认 1 个报文时发射最多 2 个新报文，以平滑的步调快速回填 FlightSize 直至追平 ssthresh。这对于交互式终端、音视频会议和游戏网络连接至关重要。

FlightSize 与 CWND 同步机制：消除突发激增与尾部丢包

传统快速恢复往往直接在恢复期内粗暴改写 CWND，导致退出恢复状态重返拥塞避免模式时，瞬间释放出庞大的突发流量。RFC 6937 将发包限额 sndcnt 的推导与底层 CWND 变量解耦：

通过在整个恢复期内对 FlightSize 实施连续跟踪，PRR 能够确保在恢复终止时，在途数据量刚好与 ssthresh 完美重合。这完全消除了退出恢复时的突发风险，从根本上防止了尾部丢包。

现代 Linux 网络栈中 SACK、FACK 与 PRR 的协同机制

在现代 Linux 内核中，PRR 已被确立为所有拥塞控制算法底层的统一丢包恢复基石。RFC 6937 严重依赖选择性确认 (SACK, RFC 2018 / RFC 6675) 来对每次到达的确认报文进行字节级精确定位。

当开启前向确认 (FACK) 配合 SACK 时，内核能够构建序列号空洞的精确分布图，帮助 PRR 区分单个孤立丢包与大规模报文损失。PRR 直接依据新确认的连续块尺寸更新 prr_delivered，为公平队列 (sch_fq) 调度器提供高度精确的调步时间间隔指示。

封装陷阱：WireGuard 与 IPsec 加密隧道内的 PRR 行为演化

将 PRR 部署在虚拟专用网络中时，内部传输流与外部封装层之间会产生复杂的耦合现象。用户应用程序的数据在穿透 WireGuard、IPsec 或 OpenVPN 时，原始 TCP 报文均被封装在外部 UDP 或 ESP 结构中。

外层 MTU 分片与瞬态丢包放大效应

若隧道路径 MTU 探测 (PMTUD) 出现配置异常，或中间网络限制了最大传输单元，内部 TCP 报文可能触发外层 IP 分片。一旦外层分片丢失，整个内层 TCP 报文便随之报废：

• 外层 2% 的偶发分片丢失，可能被成倍放大为内层 4% 至 8% 的 TCP 报文损失。
• 传统算法在面对这种放大效应时，会快速陷入连续超时重传的瘫痪状态。
• PRR 通过保持均匀节拍发包，防止隧道网关外层缓冲区发生拥塞溢出，有效遏制了分片丢失。

与 BBR、CUBIC 及 Reno 拥塞控制引擎的耦合协同

PRR 充当着拥塞控制算法下方稳健的恢复执行层：

• CUBIC：内核默认将 CUBIC 与 PRR 深度绑定。当 CUBIC 检测到拥塞将窗口下调 30% 时，PRR 自动以 Target_Ratio = 0.7 平缓推进发包，实现平滑减速。
• BBR：尽管 BBR 主要基于瓶颈带宽建模，但其现代版本在排空和探测阶段也借鉴了 PRR 比例平滑原则以避免造成瞬时队列堆积。
• Reno：对于采用经典丢包反馈的 Reno，PRR 能够消除传统折半带来的严重网络卡顿。

基准测试指标：延迟分布特征与队列排空效率实测

在跨国广域网与高延迟加密隧道环境下，多项基准测试验证了 PRR 相较于传统方案的显著优势：

通过维持连续的“数据包时钟”，PRR 彻底解决了历史上困扰加密网络隧道的管道饥饿难题。

RiceGuard 平滑调步架构：面向全球用户的低抖动多路径传输

VPNRice 将 PRR 算法的核心精髓深度集成至自研的 RiceGuard 高性能网络架构中。RiceGuard 边缘网关通过 Anycast 骨干节点承载着全球用户海量并发连接。

为确保实时在线游戏、高码率流媒体与跨国远程桌面的绝对流畅，RiceGuard 在多个层面优化了丢失恢复逻辑：

1. 内核级 PRR 调步注入：所有 RiceGuard 节点均运行深度调优的 Linux 内核，全面激活 PRR 与公平排队 (fq) 硬件调度，确保偶发丢包绝不阻断骨干管道。
2. 隧道缓冲区与 MSS 联动：在加密隧道边界自动计算精确的 MSS 钳制策略，从根本上防止外层分片对 PRR 字节统计造成的失真影响。
3. 持续 ACK 驱动机制：通过在丢包恢复期全程维持比例发包，RiceGuard 消除了一般网络服务中常见的卡顿与等待，保持亚毫秒级的交互敏捷度。

这一架构确保了移动蜂窝网络切换或公共 Wi-Fi 抖动不会恶化用户的长连接传输质量。

生产环境调优指南：内核核心参数与加密隧道缓冲优化

系统工程师与网络运维专家可在 Linux 生产网关上通过以下标准配置检验并调优 PRR 性能：

• 确认内核 PRR 支持：验证当前内核版本已内置 PRR 支持（Linux 3.2 及以上默认开启）。通过 /proc/sys/net/ipv4/tcp_congestion_control 确认，并确保激活 SACK (net.ipv4.tcp_sack = 1)。
• 启用公平排队调步 (FQ)：部署 FQ 排队规则以强制执行硬件级单报文微观平滑调步：sysctl -w net.core.default_qdisc = fq。
• 配置 MTU 边界钳制：在隧道虚拟网卡上配置精确的 TCP MSS 钳制 (iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu) 杜绝外层分片。
• 监控恢复指标流：使用 nstat -az TcpPrr* 与 ss -tie 实时追踪内核中 prr_delivered 与 prr_out 计数器，分析丢包恢复的动态轨迹。
• 抑制套接字写缓冲：合理设定套接字最大写缓冲空间 (net.ipv4.tcp_wmem)，杜绝过度在途堆积，防范进入恢复期前的不必要队列膨胀。