摘要

  • 乱序是到达次序偏离发送次序；重排则是主动扣住已经到达的帧，等待缺口补齐或被判定丢失。
  • 二层设备能看见序号、缺口和等待时间，却通常看不见每个 TCP、QUIC 或应用上下文是否真的需要这次等待。
  • Wi-Fi 的分组序号还承担防重放作用。允许合法迟到帧越过当前最高序号，需要同步调整安全窗口，不能只缩短缓冲计时器。
  • RACK、QUIC、ROHC 与 ESP 都提供有边界的乱序处理机制；协议名称不等于具体实现已经具备相同能力。
  • 草案 00 只是拟议中的 RFC 3819 指南更新，不是 RFC、部署证明或普遍性能结论。

同一个小序号，两种完全不同的来历

接收端已经看到了序号 108，随后收到序号 103。若 103 是攻击者复制的旧帧，丢弃是正确的；若它是无线链路在多次重传后才送达的真实帧，丢弃又可能破坏可靠性。二者在“比最高序号小”这一观察上完全相同，权威含义却相反。

传统的按序交付把这道难题藏在缓冲区里：先扣住 104 至 108，等 103 到达，再一起向上交付。这样，简单的“只接受更大序号”规则可以继续工作。代价是所有被扣住帧的时间。

draft-ietf-intarea-reordering-00 要求人们正视这笔交换。让端点直接看到有界乱序，可能减少队头阻塞；但安全、压缩与重组状态必须能够表达这种乱序。删掉缓冲而保留旧的证据规则，并不是现代化，而是把一个显式等待换成隐式丢包。

原序得到恢复，不等于业务得到改善

草案对“乱序”和“重排”作了清楚区分。前者描述事实：接收顺序改变。后者描述控制动作：把乱序序列恢复为发送顺序。

重排需要内存、上下文键、缺口认定与超时。它还可能把不同四层连接绑在一个二层序列上。缺失帧属于大文件传输，后面的帧却可能是另一个连接的控制响应。二层只知道它们的链路序号，无法自动知道谁更怕乱序、谁更怕等待。

因此，“恢复原序成功”最多是一个中间回执。要证明收益，还需保留另一条链：如果立即释放，端点会如何判断丢失，是否会误重传，应用何时收到数据，用户结果是否改善。没有这一组对照，绿色排序状态只是漂亮的局部事实。

旧式丢失推断已经发生变化

早期 TCP 常把三个重复 ACK 当作丢失信号。乱序会造成误判，触发多余重传和不必要的拥塞窗口收缩。RFC 8985 的 RACK 更依赖时间与 ACK 关系；RFC 9002 也为 QUIC 规定时间阈值和分组阈值，并允许根据观测调整。

这并不意味着所有端点都已经安全。能力必须落到具体版本、配置和运行轨迹。某个设备“支持 TCP”无法证明启用了 RACK；某条 QUIC 连接也可能采用保守阈值。子网若要把解释权交还端点，应先获得可以更新的能力证据，而不是永久相信一次产品标签。

三类链路，三种等待理由

蜂窝系统里，并行 HARQ 进程、RLC 重传与 Dual Connectivity 的路径时差都可能制造乱序。重排位置随系统与模式而变化。是否等待，不能脱离承载、重传模式与定时器。

Wi-Fi 会按流量标识符维护重排上下文。草案引用的一个场景中，七个其他站点竞争信道时，重排引入的额外延迟超过 P90 的 75 毫秒和 P99 的 400 毫秒。这只是被引用场景，不是所有 Wi-Fi 的常数，也不是 BTW 的测量。

DOCSIS 的信道绑定因成员容量和时延不同而产生错位。下行序列、上下行分段重组与完整帧的交付政策又是不同层次。把分段重新拼成一帧是必要的字节工作；为了更早的完整帧而扣住其他已经完整的帧，是另一个政策决定。

有界容忍必须带参数

RFC 4303 的 ESP 防重放窗口允许一定范围内的乱序，但窗口之外的真实分组仍会被拒绝。RFC 4224 讨论 ROHC 在乱序信道上的实现，RFC 5225 的 ROHCv2 改进了容忍度；这些文档都不能替代对实际配置与上下文状态的核验。

NAT 与分片也说明“标准要求”和“现场行为”之间可能有缝。规范要求处理某类乱序分片，不证明每台中间盒都实现正确。网络不能因为担心未知旧设备就永远扣住所有流量，也不能因为新规范存在就宣布未知风险已经消失。

合理做法是把未知写进决策：哪些端点经过验证，哪些上下文受安全窗口限制，哪些流量暂时保留重排，以及何时重新测试。

草案真正提出的规则

草案没有主张“永不重排”。它说，子网应避免制造不必要的乱序；如果乱序是多链路条带化或链路层重传带来容量、可靠性收益时不可避免的副产品，通常应把它暴露给端点。只有明确证据表明收益超过额外延迟和抖动，子网重排才应启用。

这项规则把举证责任放在等待者身上。二层设备确定知道自己扣住了本可立即转发的帧，却不知道端点会不会受害。知道成本而不知道收益的一方，不应凭默认设置永久花掉别人的时间预算。

状态边界

草案 00 发布于 2026 年 8 月 27 日，计划于 2027 年 2 月 28 日到期，预期状态为 Informational。若获批准，它将更新 RFC 3819 第 15 节；目前没有 IANA 请求，也没有因此自动改变 IEEE、3GPP 或 CableLabs 标准。

它是仍在推进的 Internet-Draft，不是 RFC。

本文没有验证任何具名厂商、运营商或网络部署。草案仍可能修改、替换或到期。文章分析的是控制权与证据边界，不是尚未被证明的采用结果。