摘要

  • RFC 3522 的 Eifel 检测算法保存触发恢复的重传时间戳，再检查恢复期间第一个可接受 ACK 的回显值。更早的值能够说明 ACK 对应原始发送，从而判定恢复并无必要。
  • 判定不会自行恢复拥塞窗口、慢启动阈值、RTO 或业务表现。完整凭证要分别保留原始发送、触发条件、不可覆盖的 RetransmitTS、歧义退出、恢复前状态、响应写入、后续网络事实与应用结果。

自动控制先行动，证据后到。定时器到期或重复 ACK 达到阈值时，TCP 不可能预知稍后返回的确认会替原始报文洗清“丢失”判断。它会重传、收缩窗口，并进入恢复流程。

2003 年 4 月发布的 RFC 3522 属于 Experimental，不是互联网标准。它利用 TCP Timestamps 消除 retransmission ambiguity：普通 ACK 号码只能说明字节已被确认，无法区分是原包还是重传包触发了确认。

这份文档只定义检测。算法中的 (RESP) 是“什么也不做”的占位。诊断成立与状态复原之间，被规范有意留出了一条边界。

第一个可接受 ACK 是事后证人

恢复开始时，发送端把 SpuriousRecovery 设为假，并将首次超时重传或快速重传的 Timestamp Value 保存为 RetransmitTS。同一恢复过程中的后续重传不得覆盖它。

随后等待第一个确认此前未确认数据的 ACK。如果 Timestamp Echo Reply 小于 RetransmitTS，它必然对应时间更早的原始发送。在通过第 5 步的保守检查后，可以宣布恢复属于误触发。

“第一个”具有运行意义。超时误判之后，延迟返回的原包 ACK 可能诱发 go-back-N 式连锁重传；尽早识别可以在更多副本发出之前止损。

但证人不可能早于案件。触发、窗口变化和首个重传都已经发生。审计必须保留这个顺序，而不能把最终分类覆盖到过去状态上。

相同假象并不等于相同原因

路径延迟突然增加，会让 RTO 先于 ACK 到期。报文重排可能制造足够多的重复 ACK。数据包或 ACK 重复，也可能触发同样的快速重传。

Eifel 判断恢复是否不必要，却不唯一判断原因。旧时间戳不能证明发生了重排，不能定位接入网，也不能测量拥塞。

误快速重传通常产生一份无用副本，并把窗口减半。误超时则可能迫使 slow start，并在原包 ACK 陆续返回时制造更多重传。共同的“spurious”标签不能取代各自的影响记录。

RFC 还区分 fast timeout：若报文确实丢失，只是定时器比重复 ACK 更早触发，恢复仍属正当。多等一会儿会改变触发机制，不会抹去真实丢包。

相等不是积极证据

基础算法使用严格“小于”。时间戳时钟较粗或路径很快时，原始发送和重传可能取得相同值。此时规范保守地不认定误恢复。

这可能错过一次优化，却避免用含混证据回滚控制状态。缺少区分能力不能被转换为肯定结论。

凭证应保存两个原值、时钟粒度、比较运算符与所走分支。“已检查 Eifel”不能说明结果是肯定、否定还是无法判断。

ACK 全部丢失会伪装成误恢复

原始报文可能已到接收端，但整批 ACK 都在回程丢失。发送端只能超时重传。从字节角度看副本多余，超时却不可避免；缩小窗口也可能是对 ACK 路径拥塞的合理反应。

重复包到达后，遵循历史时间戳规则的接收端可能回显最后一个按序原包的标记。它小于重传标记，表面上符合误恢复模式。

第 5 步借助 DSACK 能力与 ACK 是否覆盖全部未确认数据来退出，避免轻率反转。因此算法不是一条简单的“小于”规则；拒绝认定的分支也是结果的一部分。

接收端可以伪造漂亮证据

恶意接收端可伪造旧回显值，让真实重传看似多余。安全变体保存所有未完成原始发送的时间戳，并要求回显值精确等于相应原包标记。

更强证明需要更多状态，也更依赖特定 ACK 抵达，对 ACK 丢失和重排更敏感。粗粒度时间戳还让缺失值更容易猜中。

安全性不是“开启 timestamps”这个标签。它取决于发送端保存了什么、粒度如何、对端能知道什么，以及证据缺失时是否拒绝行动。

没保存的状态无法靠诊断重建

RFC 3522 提到可能的响应目标：恢复拥塞状态、阻止后续无用副本、调整重复 ACK 阈值或 RTT/RTO 估算。它本身不执行这些动作。

RFC 4015 后来定义 Eifel response。若要恢复 cwnd 或 ssthresh，发送端必须在缩减前保存原值。判定“刚才错了”不能推导一个已经被覆盖的数字。

一份副本多余，也可能与同一窗口中的真实丢包并存。RFC 3708 的 DSACK 讨论明确了混合情形。为 N+1 洗清重传，不等于 N 没丢。

检测器有权报告自己的分类，却不能自动获得恢复整个控制面的权限。

响应之后仍需证明结果

响应可能写回保存值、发送新数据或调整定时器。需要再次读取实际生效的窗口、阈值与 RTO，并关联后续 ACK、真实丢包、重排和重传。

窗口复原不代表路径容量稳定，更不代表应用完成。TCP 路线图、RACK-TLP、QUIC 与 CUBIC 等后续文本仍把误丢包识别与安全响应分开；它们只是比较语境，不证明 RFC 3522 被采用。

承诺若是字节交付，就保存确认范围；若是延迟，就测量相应区间；若是应用事务，就要求经认证的应用回执。传输时间戳不能继承这些含义。

在误触发之前设计可逆凭证

记录 timestamps 协商与粒度、原始字节范围及标记、触发类型、dupacks 或 timer 输入，以及改变前的拥塞状态。

绑定首次重传并冻结 RetransmitTS。保存可接受 ACK、确认范围、回显值、DSACK 与第 5 步决定，标记采用基础还是安全变体。

响应记录算法版本、保存项、恢复项、保留项与理由。最后关联后续网络事件、字节交付与应用结果。汇总计数适合趋势，不足以重建一次有争议的回滚。

证据边界

本文不指认任何 TCP 实现、操作系统、厂商、运营商、网络、路径、接收端、用户、流、事故或部署，也不声称现实系统的采用率、时间戳使用、丢包、重排、性能、能耗、安全或商业结果。

RFC 3522 被严格视为 2003 年 4 月的 Experimental 文档，而非互联网标准。RFC 4015、5681、5682、6298 与 7323 保留自身范围；RFC 9438、8985 与 9002 仅为后续比较。

Heng Lu 关于权威和 running code 的文章是明确披露的编辑视角，用于区分形式信号、运行状态和可观测结果，不是 IETF 意图来源。

结论很窄：ACK 可以纠正判断，不能直接纠正状态；只有独立响应确实执行并被观测后，才可称为恢复。

来源