摘要

  • 窄反向路径中的 ACK 排队、丢失或压缩可以控制宽正向链路的 TCP 进度，因此下行物理容量不是应用吞吐收据。
  • ACK filtering、decimation、reconstruction 与 pacing 分别改变反馈负载、时间形状和 sender actuation；它们不能互相替代，也不能证明应用完成。

优化前，上行队列里塞满 ACK。优化后，队列空了许多，图表立刻变绿。发送端却开始每次冲出更大的数据簇，正向链路在短时间内溢出。

这不是优化失败的简单故事，而是证据迁移。ACK Filtering 利用累计确认的性质，删除部分旧 ACK，让较新的 ACK 代表更大进度。反向 packet 数减少，上行资源得到释放；但 sender 收到 stretch ACK 后，可以一次开放更多发送窗口。

RFC 3449 于 2002 年 12 月以 BCP 69 发布，系统讨论 path asymmetry 对 TCP 的影响。它没有把所有方法列为推荐。相反，文档用 REC、EXP、NOT REC 区分成熟度与适用边界。它最值得保留的并不是某一项历史参数，而是反馈链不能被压缩成单向速率。

TCP 的时钟从反方向回来

TCP receiver 接收数据后发出累计 ACK。ACK 到达 sender，既报告序列进度，也推动 sliding window、congestion-window growth 与 loss recovery。它不证明上层应用已存储或处理数据。

在理想 self-clocking 中，正向 bottleneck 拉开的数据间隔，经 receiver 生成 ACK，再返回 sender，形成新的发送节拍。反向 bottleneck 会改写这个节拍。ACK 仍可能语法正确、累计值正确，时间证据却已经不同。

因此链路分析不能只问“下行多少 Mbps”。它要同时记录正反 route、capacity、MAC 每包成本、queue、cross traffic 和 receiver ACK policy。

深队列让 ACK 变慢

若反向 queue 足够深，ACK 不一定丢失。它们排队后以更大间隔离开，sender 看到 ACK dilation，并按窄上行的速度放出新数据。正向链路可能空闲，却没有正向 loss。

持续排队还会抬高 RTT，拖慢窗口增长，使 retransmission timer 面对更大变化。仅凭 downstream utilization 与 round-trip latency，仍无法把因果定位到反向 ACK queue；必须有方向性观测点。

RFC 3449 用 normalized bandwidth ratio k 说明机制。10 Mbps 下行、50 Kbps 上行、1000-byte 数据与 40-byte ACK，在示例中得到 k = 8。这是历史示例，不是今天任何接入服务的实测值。

浅队列让 ACK 消失

若反向 buffer 小，ACK 会被丢弃。累计 ACK 允许后来的一条确认覆盖此前多个数据段，所以“所有 bytes 最终被确认”完全可能成立。

但是 recovery evidence 已减少。sender 收不到足够 duplicate ACK 或 SACK，Fast Retransmit 与 Fast Recovery 可能推迟。按 ACK 次数增长窗口的实现也会放慢。一个幸存 ACK 确认很多 bytes 时，又可能触发大 burst。

于是 byte progress 与 control progress 必须分别记账。累计性保存了正确性的一部分，却没有保存原始时序与每次 receiver feedback。

ACK compression 把等待变成冲击

双向 traffic 共用窄上行时，大 data packet 会挡在 ACK 前面。一组 ACK 等待后同时释放，sender 收到比 receiver 发出时更紧密的 cluster，这就是 ACK compression。

sender 随 cluster 发出集中数据，可能打满正向 queue。此前看起来利用不足的下行突然出现 burst loss。反向 queue 不只是延迟了消息，也改变了正向 actuation。

相反，ACK dilation 拉大间隔。两种现象都说明 sender arrival 不是 receiver emission 的透明副本。事故记录要同时保存 receiver 发出、bottleneck 前后和 sender 收到的时间线。

filtering 的条件比名称重要

ACK Filtering 在反向瓶颈之前识别并移除部分累计 ACK。RFC 3449 把它列为 experimental，而不是普遍推荐；只有与 burst mitigation 结合时，才对明显 asymmetry 或双向 traffic 路径具有条件价值。SACK、ECN、IPsec 等组合仍有额外问题。

ACK Decimation 用 queue 与 drop policy 粗略控制 ACK 速率。它无需解析不可见 header 时可能有吸引力，却会更粗暴地损失 recovery evidence。RFC 3449 建议可能时优先 filtering，并同样要求抑制 burst。

“ACK 数量下降”不能自动写成“拥塞下降”。它可能来自 receiver policy、主动 filtering、queue drop 或测量遗漏。控制面要记录谁删了哪类 ACK、依据什么状态、何时回滚。

reconstruction 创造了新的发言者

ACK Reconstruction 在 bottleneck 之后插入替代 ACK，试图恢复平滑 sender clock。新 ACK 并非 receiver 的新观察，而是中间代理根据 soft state 合成的时间信号。

RFC 3449 把它列为 not recommended，并指出 packet amplification 风险：攻击者若能注入合适的 stretch ACK，reconstructor 可能生成更多 traffic。endpoint 验证、rate bound 与 delayed-ACK factor 都成为安全边界。

一旦 intermediary 代 receiver 表达时序，系统必须记录它的 identity、state generation、rate limit 和失效行为。平滑图表不等于真实 receiver feedback 已恢复。

pacing 改变动作，不增加证据

TCP Sender Pacing 不在 ACK 到达后立刻释放全部可发送报文，而是按估计速率摊开。它可以降低 stretch ACK 引发的 burst，但需要 sender 修改和 rate prediction。RFC 3449 把它视为 experimental。

Pacing 没有创造更多 receiver evidence。它只改变 sender 如何使用已有证据。Byte Counting 也改变窗口增长方式；unlimited byte counting 会让大累计 ACK 打开过大窗口。后来 Appropriate Byte Counting 增加约束，却仍不能证明应用结果。

因此 pacing 后 queue 更平稳，证明的是 actuation 改变，不是反向 path 不再丢 ACK，也不是 loss recovery 已改善。

每个小 packet 可能付同样的介质成本

在某些 radio、cable 或 bandwidth-on-demand MAC 中，发送前的 contention、grant、guard time、turnaround 对每个 packet 收费。40-byte ACK 的资源成本可能接近更大 packet。

Header compression 减少 ACK bits，但引入 compression context 与 loss sensitivity。header 被加密或封装后，中间设备可能无法使用它；高 asymmetry 下也未必改善。保护 header 限制 middlebox，不是 encryption 故障，而是权限边界。

优先 ACK 也能饿死数据

ACKs-first scheduling 可以缩短反馈等待，却可能在没有 ACK volume control 时让上行 data starvation。RFC 3449 因此不推荐把它作为 Internet 通用办法。

Fair queueing 能隔离 flow，避免 ACK 永久困在大 packet 后，同时不给 ACK 无限优先权。它仍需在真实 workload 下验证。只测 download 的方案，可能把 upstream application 的损失排除在成功定义之外。

十二张收据

先保存正反 route 和观察窗口，再记录两向 capacity、MAC 事件成本、reverse cross traffic、queue policy 与 buffer depth。随后是 receiver ACK policy 与原始 emission timing。

任何 loss、filtering、decimation、compression、reconstruction 或 scheduling 都要留下 provenance。sender 侧保存 ACK spacing、cumulative progress、duplicate/SACK、cwnd、pacing 和 burst distribution。

正向 loss 与 recovery 单独记录。transport goodput 连同 offered load 与 fairness。其后才是 authenticated application completion 和用户结果。最后通过 rollback 与 alternate path 重现因果。

一个 throughput 绿灯可以对自己的测试成立，同时仍然没有说明是谁设定了 sender clock。

证据边界

RFC 3449 没有证明任何当前运营商、接入网络、卫星、cable、radio、TCP stack、congestion controller 或 incident 的行为。k = 8 是文档示例，不是 live measurement。CUBIC 等后续算法改变窗口增长，也没有消除 ACK 与 recovery evidence。

Heng Lu 的 minimum initial specification 与 running-code primacy 是公开分析视角。它们要求把 mitigation 保持在必要范围，由本地根据运行证据采用，不把某一种 access architecture 变成 universal transport rule。它们不提供部署数据。

来源