摘要

  • 9 月 30 日更新的 MASQUE 工作组草案规定：进入隧道的以太网帧如果超过 QUIC DATAGRAM 可容纳的实际容量，端点必须丢弃，且不得把该帧改装为 DATAGRAM 胶囊。无论选用何种模式，解封装后的帧若超过出口接口、目标网络或接收端的上限，也必须丢弃；实现宜统计超长帧丢弃次数。
  • 第 14 版说隧道承载原帧的 Frame Check Sequence，即 FCS；第 15 版改为只承载从目的地址到 FCS 前一字节。普通网卡在入口剥离、在出口重新生成 FCS。当前文本仍是接受 IESG 审议的互联网草案，不是已发布 RFC，也不能作为某次生产事故的证据。

运营看板最容易把“隧道已建”显示成一个绿色状态。这只证明 HTTP 建连流程走到了成功响应，无法证明下一帧是否能装进当前传输模式。小帧测试可以一路正常，带标签或尺寸接近边界的帧却被丢弃，而连接仍然保持。第 15 版的价值在于把这种差距落实到两个可定位的容量判断，而不是笼统归入隧道性能。

草案提出用 HTTP 代理转送二层以太网帧。在 HTTP/3 加 QUIC DATAGRAM 模式下，承载单个帧的 DATAGRAM 本身不能被拆分。可用空间不是网卡标称 MTU，也不是 QUIC DATAGRAM 的总上限；还得扣掉 HTTP Datagram 的封装开销。若到来的帧超出余量，端点必须丢弃它。新文本特别说明，不能因这一帧装不下，就悄悄改成通过 DATAGRAM 胶囊发送。路径 MTU 探测可以帮助运行中的接口调整 MTU，但不能倒过来证明此前被拒的帧已经送达。

胶囊仍是另一种正当模式。HTTP/1.1、HTTP/2，或不启用 QUIC DATAGRAM 扩展的 HTTP/3，可以经可靠流发送 DATAGRAM 胶囊。一个胶囊能够跨多个 TCP 或 QUIC 包，因此可以承载大于路径单包 MTU 的帧。这是部署时选择的运作方式，不是 DATAGRAM 模式逐帧失败时的自动补救。把两种能力混为一谈，会使运维人员误以为“大帧总有退路”。

帧穿过隧道之后，还要面对出口的物理或虚拟接口。第 15 版新增规则：解封装帧只要超过出口接口、目的网络或者接收端能处理的最大帧尺寸，就必须丢弃；实现应当记录超长帧丢弃计数。入口容量和出口容量不是同一份账。前者关系到传输封装能否装下，后者关系到交付给相邻网络时是否可接受。计数器可以证明发生了哪类拒绝，却不能单独解释应用为何超时，也不能代替端到端测量。

另一个变化关乎“完整帧”的含义。第 14 版把 FCS 包含在代理承载的帧内，并以省去端点重算为理由。第 15 版把 Context ID 为零的载荷止于 FCS 之前，解释说普通网络接口通常在接收时剥去原 FCS、发送时重新生成。这并不意味着底层以太网不再校验错误，也不是宣称 HTTP 隧道必然不安全。它说明该草案没有把原始链路的 FCS 作为跨代理、跨链路不变的证据。未来扩展也许会定义另一种编码，但不能把未定义的扩展当作现行承诺。

草案如今把模拟连接称作点到点以太网链路。若要把它接入更大的广播域，桥接、环路防护和广播流量处理仍由端点或受委托组件承担。VLAN 标签原则上透明转发；端点若解释这些标签，就需要另行约定一致的处理办法。代理可以让不同 VLAN 对应不同 URI，以便分别调度与执行策略。这些选择都有治理价值，但都不把 HTTP 成功响应变成每一帧的交付凭证。

Datatracker 当前显示该稿是 MASQUE 工作组的活跃草案，已送交 IESG，处于 AD Followup，仍有 DISCUSS 待解决。目标是 Proposed Standard，而不是已经完成标准化。公开文本没有提供厂商部署统计、真实丢包率或故障归因。可核实的新闻，是提议中的帧表示和强制丢弃规则发生了变化；需要检验的是运营方能否在自己的记录里区分建连、准入、出口交付三个状态。

来源