摘要

  • RFC 3360 记录了部分防火墙和负载均衡器因不认识 ECN setup SYN 中的 ECE、CWR 位而返回 TCP RST，把中间盒的不兼容伪装成端点拒绝。
  • 清除两位后重试可以恢复普通 TCP，却无法证明第一条 RST 的生成者、对端的 ECN 能力、中间盒的策略原因，或扩展路径已经修复。

监控面板显示“第二次尝试成功”。第一条 SYN 带 ECE 与 CWR，收到 RST；第二条 SYN 清除两位，服务器返回 SYN-ACK，应用请求完成。值班人员把事件归类为瞬时连接错误。

从可用性指标看，这次自动恢复是成功。从协议能力看，它可能是一场没有被记录的失败。

RFC 3360 于 2002 年 8 月以 BCP 60 发布，题为 Inappropriate TCP Resets Considered Harmful。它讨论的具体故障是：防火墙或负载均衡器看到 TCP 首部原保留字段中的新用法，就向发送方返回 RST。ECN 恰好把 ECE 与 CWR 分配在这些位置。中间盒因此替未必收到报文的服务器发出了具有“连接被拒绝”效果的控制信号。

这不是今日部署率报告。文中的测量属于 2000 至 2002 年的历史样本，也不能证明某家当前厂商或运营商仍有同样行为。真正值得保留的是它揭示的控制结构：fallback 可以让最终交易成功，同时把基础能力的失败从组织视野中删除。

RST 的价值来自含义收敛

TCP RST 不是通用错误容器。RFC 793 把它用于显然不属于当前连接的报文、到达不存在连接的请求等状态冲突；接收者据此终止连接并通知应用。RFC 9293 后来整合 TCP 规范，仍为 reset 的生成、验证和状态转换设置具体规则。

当一个信号导致连接立即结束，它就必须让接收者知道自己在响应什么。若 RST 同时可能表示端口不存在、端点重启、队列已满、防火墙不认识扩展位、策略禁止某个功能，发送方只能通过猜测和重试恢复语义。

RFC 3360 并未否定站点制定安全策略的权力。RFC 2979 也承认防火墙可以拒绝本地认定为不合法的访问。问题在于，本地策略是否以可识别的方式表达。防火墙可以说“不允许这种功能”，却不应让接收方误以为“远端 TCP 已判断这个连接不存在”。

文中还划出另一条边界：对一个被封锁端口的连接请求返回 reset，可能与 TCP 的连接状态含义一致。这里受到批评的是同一中间盒允许普通 TCP，却仅因某个标准定义的扩展报文形状而冒用 RST。

两个位把隐藏的否决权照了出来

RFC 3168 的 ECN 协商在 SYN 中同时设置 ECE 与 CWR。支持 ECN 的对端以 ECE 置位、CWR 清零的 SYN-ACK 回应；不支持 ECN 的普通 TCP 实现应该忽略陌生位并发送普通 SYN-ACK。这样，能力采用是端点之间的选择，而不是路径上每台设备都必须理解 ECN。

现实破坏了这个设计假设。一些中间盒没有忽略新位，而是重置或丢弃连接。RFC 3360 给出的 2002 年 3 月样本是：12,364 个被测网站中，203 个路径对 ECN setup SYN 返回 reset，420 个路径丢弃它。这个数不能外推到今天，但足以证明路径中的第三方可以阻止两个端点完成原本属于它们的协商。

单侧抓包无法自动回答“谁说了不”。RST 的源地址、端口、ACK 与时序可以符合预期，却没有密码学来源证明。中间盒可以构造语法正确的返回报文。若没有中间盒前后的观测点、可复现的旁路测试、设备规则与日志，把它写成“服务器拒绝 ECN”就是把推断当事实。

fallback 花掉的是错误信息

RFC 3168 与 RFC 3360 描述了一种可选兼容路径：ECN setup SYN 收到 RST 后，以清除 ECE 与 CWR 的普通 SYN 重试。普通 SYN 成功，连接可以在不使用 ECN 的情况下建立；普通 SYN 再次收到 reset，才按通常方式终止。

它把第一条 RST 从“最终决定”变成了这一分支里的“待确认信号”。代价至少有四层。

第一，第一条 RST 可能本来就是有效端点决定，客户端却主动忽略一次。第二，普通 SYN 成功只证明降级路径可用，不能证明服务器不支持 ECN。第三，第一条 SYN 可能只是普通丢包；超时后清除能力位会把随机损失误判成扩展不兼容。第四，自动重试可能增加数秒延迟，却让上层只看到最终成功。

这正是静默兼容的治理悖论。它减轻用户当下痛苦，同时削弱发现和修复中间盒的激励。RFC 3360 记录了部分实现者拒绝采用 workaround 的理由：错误设备因此被默认接受，ECN 在本来正常的环境中也可能被关闭，而且 reset 本身的含义继续被侵蚀。

RFC 7413 的 TCP Fast Open 后来再次碰到类似问题。未知 TCP option 或携带数据的 SYN 可能被丢弃，于是实现回退到普通三次握手。交易完成率可以很高，能力路径的失败率却被隐藏。只看“页面最终打开”的 SLO，会系统性漏掉协议僵化。

语法有效不等于发言有权

RFC 5961 为抵御盲 reset 攻击，加强了已建立连接中的 RST 验证。窗口内但序列号不精确匹配的 reset 不再立即断开，而是触发 challenge ACK，让真正对端用新的 reset 确认。

这提高的是接收条件，不是含义来源。初始 SYN 阶段收到一条能正确 ACK 的 RST，仍可能由路径设备生成。RFC 5961 自身也讨论了中间盒异常：它可能清除状态后重发旧 reset，形成 ACK/RST 循环，或因自己的流表已删除而丢弃 challenge ACK。

序列号证明一条报文符合某种状态机条件；它不能证明生成者拥有表达该端点状态的权限。安全系统若能制造合格语法，却没有明确策略收据，就拥有“看起来像服务器”的控制力。

私有兼容规则如何变成公共协议上限

RFC 3360 的长线警告不是 ECN 单项故障，而是 TCP 演化可能被冻结。标准把保留位分配给新功能并不足够；如果大量已部署设备拒绝这些值，新功能即使获得 IETF 标准地位，也无法穿越真实路径。

RFC 6709 与 RFC 9170 后来把机制概括得更清楚：扩展点只有被持续实现、变化和使用，才保持可用。长期不变的字段会诱导设备把“我见过的值”误写成“协议允许的全部值”。错误存在越久，修复成本越高，依赖 workaround 的软件越多。

RFC 8701 在 TLS 中采用 GREASE，故意提供永远不会被真正选择的保留值，让不容忍尽早暴露。它不是 TCP 的万能答案，也没有证明所有 greasing 都有效。它说明的原则是：扩展性必须被主动检验，失败必须有可见反馈。

这也呼应 docs/heng-lu-note.md 的最小初始规范、未来决策本地化和自愿采用。路径运营者当然可以不采用某项能力，也可以因具体风险拒绝流量。但本地决定应保持本地、可解释、可复核。若它通过冒用端点 RST 生效，一个中间盒就把自己的未知或偏好变成了两个端点无法审查的事实。

一次降级连接需要九张收据

第一张保存原始 SYN：标志位、option、地址、时间与预期能力。第二张标出观测位置，区分客户端出口、中间盒两侧与服务器入口。第三张验证 RST 的 ACK、序列与路径特征，同时明确这些只能提供线索，不能构成来源认证。

第四张绑定策略：若设备故意拒绝，记录规则所有者、软件版本、规则版本、批准理由、创建日期与退出条件。第五张记录 fallback 的触发：RST、超时还是人工试验。第六张证明普通 SYN 是否沿相同路径到达同一目标。

第七张验证能力协商，而不是只看连接建立。第八张验证传输数据在协商模式下通过。第九张由应用探针证明最终结果，并保留它与传输证据的区别。

修复也要重复完整链条。配置差异或固件升级不是修复结果；扩展 SYN 穿过目标路径、到达对端、收到符合对端能力的回应、传输数据并产生外部结果，才足以关闭问题。多路径环境还要检查替代出口，因为“有一条路成功”可以与“另一条路仍僵化”同时为真。

证据边界

本资料包没有证明所有 ECN setup SYN 的 RST 都不适当，也没有要求防火墙放行一切未知位。它没有当前部署率、厂商排名或真实事故证据。

普通连接成功不证明 ECN 不必要或服务器不支持 ECN。ECN 握手成功也不证明后续路由器发生拥塞标记、接收方反馈、发送方降窗或应用获益。这些属于后续层次。

可以确定的边界更窄：fallback 解决了用户眼前的连接，却可能把协议能力失败变成不可见的运营债务。最终成功不能替代失败路径的记录。

来源