摘要
- RFC 9768 把 TCP 接收端定位为“通用的机械反射器”:负责计数与反馈,不替数据发送端选择拥塞响应。
- 三位 ACE 报文计数器是不可缺的粗粒度通道;TCP 选项里的三个 24 位字节计数器更丰富,却更容易受选项空间和中间盒影响。
- 运维结论必须保存握手、计数单位、ACK 缺口、回绕假设、两路对账与发送端动作,不能把 CE 增量直接写成队列诊断。
一张需要重建的回执
假设发送端先看到 ACE 为六,随后几份 ACK 消失,下一份 ACE 为一。按模八计算,最小增量是三;但如果缺口足够长,期间也可能多转了一圈。延迟确认改变采样节奏,ACK 过滤删去中间状态,乱序又会改变观察顺序。接收端返回了证据,却没有返回一段无歧义的历史。
这正是 RFC 9768 所处理的边界。传统 TCP ECN 每个往返最多传回一次拥塞指示,无法说明这一轮究竟有多少报文被标成 CE。2026 年 4 月发布的 Standards Track RFC 9768 更新了 RFC 3168 的 TCP 协商与反馈,用 AccECN 返回更细的计数。
它没有规定新的拥塞控制算法。接收端读取到达报文的 IP ECN 字段,按规则计数并反复反射当前状态;数据发送端知道自己原先发出了 ECT(0)、ECT(1) 还是 Not-ECT,因此由它验证反馈、重建增量并选择动作。接收端可以长期保持简单,未来的发送端算法也无须要求对端理解自己的控制逻辑。
三位 ACE:始终在场,但不保证完整
AccECN 复用三个 TCP ECN 标志位,形成三位 AccECN Counter。ACE 携带接收端 CE 报文计数器的低三位,并在后续 ACK 中重复当前状态。单个 ACK 丢失不一定抹掉信号,因为后一份 ACK 仍能显示累计变化。
代价是频繁回绕。三位只有八种状态,连续缺失的 ACK 可能掩盖一整圈甚至多圈。RFC 因而约束接收端的反馈频率,并根据尚未确认的数据给出更紧的建议。当更丰富的 TCP 选项不可用时,发送端只能采用保守的“可能已回绕”解释,而不是假装知道唯一答案。
ACE 的计量对象也容易被误读。它统计通过 TCP 可接受性检查的 CE 报文,包括控制报文和重传,但不含 SYN。它不是应用唯一字节数,也不是去重后的交付量。若把 ACE 增量直接和业务字节一一对应,重传就会制造虚假的矛盾。
三本 24 位字节账
AccECN 选项提供 CE、ECT(0)、ECT(1) 三个有效载荷字节计数器的低 24 位。它们不计算 TCP/IP 头和选项,但会再次计算重传所携带的有效载荷,因为账本记录的是“收到多少”,而不是应用层去重结果。
24 位使普通 ACK 缺口内出现不可见整圈回绕几乎不现实,因而更适合按标记比例响应的发送端。可是它们住在 TCP 选项空间:SACK 与之竞争,中间盒可能删除陌生选项,代理可能把一条连接拆成两段,GRO/LRO 可能在软件看到之前合并到达。选项也可能在连接中途从可用变成不可用。
当最小 AccECN 选项与两个 SACK 块不能同时容纳时,SACK 优先。丢包恢复证据比额外精度更紧迫。于是协议形成有意的双层结构:ACE 粗而坚韧,字节账细而有条件;后者补充前者,绝不取代前者。
握手也是证据
AE、CWR、ECE 在三次握手中的组合用于协商 AccECN。老旧端点可以退回经典 ECN 或不使用 ECN;某些被反射或无效的组合则提示路径有故障。初始 SYN 的选项空间太紧,因此 AccECN 选项不会放在 SYN 上,而是在 SYN/ACK 与第一份 ACK 上试探。
这意味着“AccECN 协商成功”和“24 位选项可持续通过”是两件事。资产清单只留一个启用布尔值,会抹去真正的降级边界。
计数器初值被故意设成非零,有助于无状态握手,也能暴露设备把相关位清零的行为。但实现不得要求唯一的精确初值,否则会把未来可用的状态提前锁死。乱序甚至可能让握手后的第一份 ACE 合法地表现为零,简单的“见零即失败”会产生误报。
路径会改写证词
ECN 字段可能被漂白或单向篡改,TCP 选项可能被剥离,ACK 可能被过滤。接收端看不到发送端原先写入了什么,因此不应自行诊断矛盾。发送端掌握自己的发送历史,最适合把 ACE、字节计数与原始 codepoint 对账。
如果 CE 字节计数上升,而报文计数在任何合理解释下都无法对应,且重传、单位差异、ACK 丢失与回绕都不能解释,发送端可在该半连接上停用 ECT。这是局部安全决策,不是对中间盒、队列或运营方的判决。
方向性不能省略。TCP 可双向传数据,某个方向的代理、改写或选项通过能力可能完全不同。合规记录应按半连接保存握手位、发出与收到的 ECN、ACE 序列与模增量、三个字节账的基线与变化、选项形态、ACK 丢失/延迟/乱序、SACK 压力、重传、offload、代理、对账结论、ECT 停用与发送端算法。
队列遥测、吞吐量和应用时延必须作为独立证据附上。CE 说明报文到达时带着 Congestion Experienced,不说明队列长度、标记阈值、设备身份、运营者责任或用户影响。DCTCP、L4S 与传统 TCP 对同一序列可能采取不同响应,AccECN 并未替它们作选择。
验证也应主动制造不确定性:丢单个与成组 ACK,隐藏整圈 ACE,乱序第一份 ACK,中途剥离选项,用 SACK 挤占空间,单向改写 ECN,启用聚合,并注入不可接受报文。正确结果不是永远获得完美数字,而是明确降级、尽量保留 ACE,并拒绝用缺失证据制造确定性。
来源
- RFC 9768:更准确的 TCP ECN 反馈
- RFC 9768 的 RFC Editor 记录
- RFC 9768 纯文本
- RFC 9768 XML 源文件
- RFC 3168:IP ECN
- RFC 7560:增强 ECN 反馈需求
- RFC 7141:字节与报文拥塞通知
- RFC 8311:放宽 ECN 实验限制
- RFC 8257:DCTCP
- RFC 9330:L4S 架构
- RFC 5681:TCP 拥塞控制
- RFC 9438:CUBIC
- RFC 9293:TCP
- RFC 2018:SACK
- RFC 2883:SACK 扩展
- RFC 3540:ECN Nonce
- RFC 5961:增强 TCP 鲁棒性
- RFC 9000:QUIC
- RFC 2119:规范性关键词
- RFC 8174:规范性关键词的大小写
会员简报
档案背景详情
使用相应会员等级登录,即可解锁完整简报与来源注释。
仅限 Strategic Circle
Strategic Circle
所有读者均可浏览。加入并登录后可解锁档案简报。
加入 Strategic Circle仅限 Leadership Alliance
Leadership Alliance
符合条件的 IP 资产所有者和管理层可登录查看 Leadership Alliance 简报。
加入 Leadership Alliance
