摘要

  • IESG 批准一套跨 TCP、QUIC、SCTP、DCCP 与 CUBIC 的共同方法：发送方受应用或接收方限制时，窗口增长不得脱离最近一次减窗以来真正用过的最大飞行量。
  • 合法 ACK 能证明已发送数据到达，不能证明从未投向路径的空闲额度也可以无限扩张。

计数器先到了二十四，路径没有

先看草案刻意简化的算例。初始拥塞窗口是十个报文段，发送方把十个全部发出，然后停顿。假设没有丢包，并且每个报文段各收到一个 ACK，慢启动会把窗口从十提高到二十。

随后，应用又提供四个报文段。它们同样被发送、同样被确认。若不加约束，四个 ACK 会把窗口继续加到二十四。可是，路径在任何一个 RTT 中真正承载的最大飞行量仍然只有十。

ACK 没有造假，它们准确报告了四个真实报文段的到达。错误在于把一轮很小、受限的发送所产生的送达证据，变成了尚未实际使用过的额外容量许可。

这不是一起公开事故。真实系统还要处理延迟确认、按字节计数、节奏控制、流控变化和丢包。这个算例的价值，是把一个权责问题单独暴露出来：哪些证据足以让发送方增加尚未确认、却可以进入网络的数据量？

IESG 批准了什么

IETF 公告时间为 8 月 24 日 17:57 UTC。IESG 将 draft-ietf-ccwg-ratelimited-increase-10 批准为 Proposed Standard。文件来自 Congestion Control 工作组，并更新 DCCP CCID 2、TCP、QUIC、SCTP 与 CUBIC 所依据的五份 RFC。

批准只是一个状态。证据冻结时，Datatracker 仍把第 10 版列为 Active Internet-Draft，处于 RFC Editor queue，且等待作者输入；文件不要求 IANA 动作。RFC 编号、实现发布、默认启用与生产效果，仍是后续且彼此独立的事实。

公告记载工作组取得广泛支持，并有多个实现；其中还说，文件描述的行为自 Linux 3.16 起已经部署。这提供了重要的运行代码历史，但不能证明每一个内核、QUIC 库、设备或服务都使用同一构建、同一判断门和同一组可观测指标。

发送受限，不等于拥塞窗口已用满

拥塞控制可能允许继续发送，实际发送却更少。应用可能暂时没有数据；接收方可能不给 TCP 接收窗口空间，或不给 QUIC 连接和流足够的 credit；节奏器或速率控制器也可能把出发速度压在 cwnd 上限之下。

草案把完全使用发送额度的流称为 cwnd-limited。沿用 RFC 7661 的定义，若一条流使用不超过 cwnd 的一半，便属于 rate-limited，并处在尚未验证的阶段。

这些状态背后是不同的决定者。传输层设定 cwnd，应用决定是否有字节可发，接收方控制公布的额度，节奏器安排出发时刻，路径提供丢包、ECN、时延和送达证据。只记录一个“未充分使用”，会抹掉究竟是哪一层限制了发送。

因此，cwnd 是许可，不是带宽测量。二十个报文段的窗口，只说明在当前算法状态下允许多少未确认数据在途；它不说明链路还有二十个报文段的空余，也不说明接收应用已经准备好，更不保证路径不会改变。

上限跟随真正用过的飞行量

新规则引入 maxFS：从最近一次 cwnd 降低之后，观测到的最大 FlightSize。它起始于初始窗口；每当飞行量更新，就保留当前飞行量与旧最大值中较大的一个。

只要 cwnd 因任何原因下降，maxFS 就必须归零，再由下一次飞行建立新的已执行基线。这一步非常关键：丢包响应、ECN 反应或其他减窗，不仅缩小许可，也终止旧最大值对未来增长的证明力。

当 FlightSize < cwnd 时，发送方仍可处理由 ACK 驱动的增长，但结果不得超过 limit(maxFS)。这个函数问的是：如果把大小等于最大已执行飞行量的一整窗口发出并全部得到确认，底层拥塞控制算法最多会给出多大的窗口？

在 RFC 5681 慢启动中，示例上限是 2 * maxFS；在拥塞避免中，是 maxFS + SMSS。规则没有丢弃送达证据，而是限制这份证据可以授权到哪里。

回到十加四。第一轮后，maxFS 为十，窗口可以到二十。后来的四个 ACK 依然有效，但窗口仍封顶于二十。只有后续真实飞行超过十，maxFS 才会移动，更大的上限才获得新的执行依据。

一条共同规则，替代多种互相冲突的假设

标准 TCP 文本没有为这种情形规定增长上限。DCCP CCID 2 在未受 cwnd 限制的无拥塞阶段也可能继续增长。QUIC 则规定未充分使用时不应增长。SCTP 和 CUBIC 的部分规则同样更保守。

获批文件用一套有界方法替代这种分歧。对 QUIC、SCTP 和 CUBIC，它可能比“完全不增长”更积极；对 TCP 和 DCCP，它阻止小飞行持续制造无界额度。共同点是证据上限，不是所有实现变成相同代码。

以速率为中心的算法，其最大持续速率也不得超过 cwnd 方法本来允许的水平。只要节奏控制改变的是报文间隔，而不是每个 RTT 的在途量，它仍可照常工作。BBR 这类同时使用速率、节奏与窗口的算法，更要求把速率估计、pacing rate、cwnd 和应用受限样本分别观察。

旧证据可能比路径活得更久

草案明确承认自身边界：如果 cwnd 长期没有降低，maxFS 可能保留很久，逐渐不再反映当前端到端路径。移动网络切换、路由改变、隧道改变或队列策略变化，并不一定恰好触发变量重置。

RFC 7661 的 Congestion Window Validation 处理的是相关但不同的问题：窗口大于近期飞行量时如何管理，并用 pipeACK 表示近期获得确认的网络管道规模。Rate-Limited Increase 管增长，CWV 管长期未使用的窗口及其拥塞响应，两者不能互相冒充。

计数器会因此变成系统记忆。旧最大值能避免应用每次暂停后都从头学习容量，这是它的价值；若运营者丢失让这个最大值可信的时间、路径与减窗历史，它就会变成风险。

ACK 安全是必要条件，不是充分证明

拥塞控制依赖接收方正确确认数据。攻击者能否影响发送方，取决于传输协议的认证和保护性质。QUIC 保护的交换面比裸 TCP 更多，TCP 也有序列号与确认合法性检查。

但一个通过认证或合法性检查的 ACK，含义仍然有限。它证明某些已发送字节按协议语义到达，不证明未使用容量、未来 RTT、公平性、稳定路由或应用准备状态。

安全审查应把三个问题拆开：ACK 是否可接受；它确认了哪次真实发送；本地算法据此批准了多大增长。

运行代码要把证据链接到结果

当前 Linux Reno 源码先检查流是否 cwnd-limited，再执行慢启动或加性增长；当前 Linux CUBIC 也在自身更新之前使用同一判断门。这些公开代码支持“实际用满”和“窗口空闲”必须区分的原则。

它们并不代表某个生产集群。构建版本、回移补丁、网卡卸载、拥塞算法选择与传输库均可能不同。Running-Code Primacy 要求本地闭环：实现和配置，应用或接收方限制，飞行量，ACK 处理，上限决策，恢复发送后的真实突发，以及丢包和时延结果。

一次事件至少保留：传输协议与构建、算法状态、应用队列、接收额度、节奏或速率限制、cwnd、FlightSize、maxFS、初始窗口、慢启动门限、确认字节、丢包或 ECN 减窗、计算所得上限、路径身份，以及恢复后的送达结果。

标准给出最小共同规则，并没有把运营判断交给文件。发布描述规则；部署与可观测结果，才证明这份许可是否安全。

来源