摘要

  • RFC 10055 汇总 Chromium 在 Apple、Linux 和 Windows 上使用 UDP ECN 的实验接口；它是说明性文档，并不要求平台采用统一 API。
  • 应用只有在正确启用套接字接收、读取每个数据报的辅助数据并按平台解释其格式后，才能把 ECN 标记交给传输层。

包头里有拥塞标记，不代表应用看到了它。RFC 10055 聚焦的就是这段常被协议图略过的路径：IP 层留下信号，操作系统内核通过套接字把信号交给 UDP 应用，而应用再决定是否反馈给发送端。

这份 RFC 记录了 Chromium 在 Apple、Linux 和 Windows 上让 UDP 承载 ECN 的实验经验。它属于 IETF Informational 文档，不是要求操作系统统一实现的标准，也明确提醒读者，平台行为可能更新，当前细节应以平台文档为准。

ECN 使用 IP 字段中的两位表示拥塞状态。RFC 3168 定义了这套机制，RFC 9330 的 L4S 架构进一步依赖更频繁的显式信号。QUIC 运行在 UDP 上；RFC 9000 要求端点验证路径上的 ECN 计数，在发现异常时禁用该路径的 ECN。要完成验证，传输层必须先能观察到到达的数据包标记。

RFC 10055 把接收分为两个动作：让套接字报告标记，再通过 recvmsg() 读取随数据报抵达的辅助控制消息。在 Linux、Apple 和 FreeBSD 上，IPv4 接收通常启用 IP_RECVTOS，IPv6 启用 IPV6_RECVTCLASS。Linux 的双栈 IPv6 套接字还有一个容易漏掉的条件：若它还接收 IPv4 数据报，就必须额外启用 IP_RECVTOS。该 RFC 的 Apple 与 FreeBSD 路径不要求这一步。

Windows 的路径不同。文档推荐 WSASetRecvIPEcn()，并通过 WSARecvMsg 返回控制数据；不过，RFC 10055 还列出双栈和 IPv4 映射 IPv6 地址的特殊情况。一个只检查“套接字是 IPv6”的能力判断并不充分，调用者需要核对地址形式、双栈配置以及实际收到的控制消息。

返回的数据也不具有统一形状。Linux、Apple 和 FreeBSD 可能交付完整的 DS 字节，其中同时包含 DSCP 与 ECN 两部分；Windows 的 IP_ECN 和 IPV6_ECN 控制消息则只包含 ECN codepoint。若代码在每个平台都用相同掩码切位，可能把完整字段误当成单独标记，或反过来。

发送端还有不同控制粒度。Apple、FreeBSD、Linux 可以为套接字设置持续标记；服务器若用一个套接字承载能力各异的连接，则逐包设置可能更合适。RFC 10055 的 Windows 快照没有按套接字设置标记的办法。另一个风险来自 IP_TOS、IPV6_TCLASS：在部分平台上，它们修改的是含 DSCP 与 ECN 的组合字段。只想改 ECN 的代码可能覆盖另一个组件设定的服务类别；并发修改时还需要同步保护。

这些差异关系到观测能否成立。应用必须区分“路径没有打标”与“套接字没开启接收”“控制消息没取到”或“字节被解析错”。RFC 10055 还指出，平台之间 ECN 支持不一致可能帮助对端识别主机操作系统，带来隐私影响，但它没有给出这种指纹的发生率或成功率。

因此，可靠的能力证明不能只存一个“ECN enabled”布尔值。它应按系统版本、IP 家族和双栈模式记录接收选项是否成功、控制消息类型与长度、解析出的标记、DSCP 是否保持以及传输层计数是否通过验证。收到 CE 只是接口链条中的一张回执，并不能证明发送端已经调整拥塞控制，更不能单独证明体验有所改善。

共同要求可以很窄：逐包准确暴露 ECN，同时不破坏相邻的 DSCP 配置。平台仍可保留自己的 API；真正需要统一的是可测试、可观察的接口契约。

来源