摘要

  • RFC 3042 允许发送端在连续到来的前两个重复 ACK 上发送此前未发出的数据，前提是接收窗口与在途数据上限都允许。
  • 新数据可能带来更多 ACK 反馈，使连接达到既有的“三个重复 ACK”快速重传门槛；cwnd 本身不得增加。

RFC 3042 描述的小窗口困境，不只是一个报文段丢了。发送端还可能收不到足够的确认，无法触发当时已有的快速重传规则。若拥塞窗口 cwnd 只有三个报文段，其中一个丢失，发送端最多收到两个重复 ACK。于是，在 RFC 所述的条件下，它可能只能等重传计时器到期。

2001 年 1 月，Mark Allman、Hari Balakrishnan 与 Sally Floyd 发布这份标准轨 RFC。它提出 Limited Transmit：若发送端已有此前未发送的数据排队，那么在收到连续的前两个重复 ACK 时，它 SHOULD 各发送一个新报文段。但接收端通告的窗口必须容纳该数据，未确认的数据总量也必须不超过 cwnd + 2 个报文段。关键限制是：这些发送不能让 cwnd 增大。

这不是把拥塞判定取消，而是把发送许可限定在一个很小的临时范围内。Limited Transmit 不会立即重发那个疑似丢失的旧报文，而是发送新的排队数据，尝试维持 ACK 驱动的节奏。如果新报文段及其后续 ACK 都没有丢失，接收端可能再返回一个重复 ACK，使计数达到三个。此时触发的是既有的快速重传；RFC 3042 补充它，并没有取代它。

重复 ACK 不是只有一种解释。它可能意味着接收端看到了序号更靠后的数据，却仍在等待缺口前的数据；也可能是网络报文发生了重排。若第一个重复 ACK 一到就重发旧报文，发送端会对更弱的迹象作出反应。RFC 3042 选择先送新数据，让到达的 ACK 继续推动发送，并认为这种做法对重排更稳健。但这仍是发送端基于反馈所作的推断，不是对丢包位置或物理原因的直接观察。

条件并不宽松：必须有未发送的新数据，接收端通告窗口须有余量，FlightSize 不得超过 cwnd + 2 个报文段。若连接启用了 SACK，RFC 3042 还要求重复 ACK 中出现新的 SACK 信息，才可据此发送新数据；RFC 2018 规定了 SACK 选项。若任一条件不成立，或新报文及其 ACK 再度丢失，Limited Transmit 无法保证避免超时。

后来的 RFC 5681 将前两个重复 ACK 上的新数据发送纳入快速重传/快速恢复的完整步骤，同时保留两段在途上限以及不得改变 cwnd 的要求。这说明该机制如何进入后续规范，却不能证明某个未经测量的现代协议栈实际采用了什么行为。

RFC 3042 的历史意义不在于重写 TCP 拥塞控制，而在于一个边界修补：当小窗口产生不了足够反馈时，允许有限的新流量把反馈时钟继续走下去，却不把这份临时许可变成更大的拥塞窗口。第三个重复 ACK、对旧数据的重传、随后推进序号空间的累积 ACK，属于不同状态转换。它们都不能单独证明物理丢失原因或应用层已完成接收。

参考来源