摘要

  • RFC 3465 提出 Appropriate Byte Counting：拥塞窗口按每个 ACK 覆盖的“此前尚未确认字节”增长，而不是按收到多少条 ACK 消息固定加码，从而同时约束延迟 ACK 与 ACK division 带来的扭曲。
  • 字节证据也不能无限授权。慢启动用 L 限制单个 ACK 带来的增长，L 不得超过两个 SMSS；重传超时后的慢启动必须降为一个 SMSS，因为累计 ACK 可能包含早先已经到达的数据。

回执数量并不是进度单位

传统 TCP 窗口增长把每次 ACK 到达当作一次机会。若接收方对每个报文段都发送 ACK，且 ACK 从不丢失，这个近似很整齐。可是一旦接收方把两个完整报文段合并确认，发送方便少了一半增长机会；若一条 ACK 在回程丢失，即使下一条累计 ACK 证明相同字节已经抵达，前一次机会也永远消失。

2003 年 2 月以实验性 RFC 发布的 RFC 3465 改写了这套记账方式。其纯文本、RFC Editor 条目、Datatracker 页面、历史、引用、后续引用和勘误构成公开记录。它修改 RFC 2581 的窗口增长逻辑；后者后来由标准轨的 RFC 5681 取代。

RFC 1122 所允许的延迟确认，展示了少发 ACK 的一端。ACK 计数把“少一条消息”误作“少一份进展”，窗口可能以大约一半速度打开。ACK division 则利用相反方向：接收方对一个报文段的连续小片段分别发送 ACK。若每条消息都获得固定 cwnd 增量，一份真实数据进度便能铸造多份发送信用。

发送端建立字节账本

Appropriate Byte Counting 在拥塞避免阶段维护 bytes_acked。每条 ACK 只加入它覆盖的、此前尚未确认的字节。当累计值达到当前 cwnd，发送端从账本减去这一窗口量，再把 cwnd 增加一个发送端最大报文段尺寸 SMSS。目标仍是每个往返时间大约增长一个报文段，但结果不再依赖进展被装进多少条 ACK。

慢启动采用另一条规则：窗口可以按一条 ACK 新确认的字节增长，但不得超过 L。当 L=1*SMSS，它不比旧规则更激进，RFC 3465 建议所有 TCP 栈采用这种保守 ABC。文档允许用 L=2*SMSS 做实验，以抵消“每两个报文段一个 ACK”的影响，但明确禁止超过两个 SMSS。

上限还抑制大累计 ACK 或 stretch ACK 一次释放过量数据。即使限制为两个 SMSS，ABC 也可能放大单次 ACK 后的微突发，并让慢启动更接近每轮翻倍。RFC 报告的有限模拟在一些情形下出现更多丢包，因此它请求进一步实验，没有宣称普遍部署、性能必然提高或公平性已经证明。文档建议同时使用 RFC 2018 的选择确认。RFC 2861 则从另一侧处理应用受限连接积累未使用窗口的问题。

超时之后，新确认不全是新容量

假设较早的一个报文段丢失，后续报文段已在接收端等待。RTO 到期后，发送端补发缺口，随后一条累计 ACK 可能越过多个报文段。对发送端的确认状态而言，这些字节确实都是“新确认”；但从当前往返时间的路径探测看，并非所有数据都刚刚离开网络。

因此，RFC 3465 要求 RTO 后以慢启动恢复时必须使用 L=1*SMSS。RFC 2988 以及后来取代它的 RFC 6298提供重传计时背景。累计 ACK 没有说谎，只是它的时间范围大于当前一次容量探测。

相邻机制的权限不同。RFC 3042 的 Limited Transmit 在第三个重复 ACK 之前、满足约束时发送新数据，却不定义 ABC 账本。RFC 3449 研究不对称路径、ACK 过滤与重建，却不把发送信用从消息数迁移到字节数。RFC 2525 的实现问题目录说明为何必须观察真实行为，但不证明 ABC 的部署情况。

Heng Lu 后来的现实分层方法可把四张收据拆开：看见的 ACK 消息、新确认字节、算法准入的窗口信用、实际发出的报文段。其运行代码优先原则要求检查累加器、上限、恢复状态和真实突发。这些是后来的编辑分析工具，并非对 RFC 作者私人意图的推断。

RFC 3465 没有把每个已确认字节都宣布为新鲜容量。它先让账本不再容易被 ACK 数量操纵，又限制这份账本能够授权什么。回执可以拆分或合并，底层进展不应因此增殖。

来源