摘要

  • 2026 年 8 月 24 日，IESG 批准 draft-ietf-masque-connect-udp-listen 第 16 版作为 Proposed Standard。证据冻结时，文档仍是 RFC Editor 队列中的 Internet-Draft；公告称 Google Quiche 与 quic-go 已实现互操作。
  • 新机制让一条 HTTP 请求维持一个稳定的公共 UDP 套接字，同时与多个远端 IP/端口元组通信。公共端点只是可达资源，不是对所有来源的通行许可；协商、上下文登记、目标策略和数据面交付必须分别成立。

同一个端口收到了两个包

浏览器通过 HTTP 代理申请一个可供 WebRTC 使用的 UDP 公共地址。代理绑定 IP 和端口并返回给客户端。ICE 选中的对端发来第一个包；恰好扫描到这个端口的陌生主机也发来一个包。

两个包都到达了套接字，但它们没有获得相同的隧道权利。

这是用来检验边界的假设场景，不是已披露事件。它揭示“Proxying Bound UDP in HTTP”的核心价值：代理可以提供稳定的会合点，却无需把它变成开放中继。远端元组、Context ID、代理的目标限制，以及客户端是否愿意接收未知来源，共同决定下一步。

获批的是什么，尚未发生的又是什么

IESG 公告记录，MASQUE 工作组的第 16 版于 8 月 24 日 17:58 UTC 获批，目标状态为 Proposed Standard。

RFC 9298 规定的普通 CONNECT-UDP 在一条请求中指定一个固定主机和端口，适合 HTTP/3 等客户端—服务器型 UDP。WebRTC 依赖 ICE，往往要向多个候选对端收发数据。分别建立多条普通请求并不能保证它们落到同一代理实例，也不能保证使用同一公共源地址，因而可能破坏 ICE 所依赖的稳定性。

新扩展把公共套接字绑定在一条请求上，再让每个数据报或已登记映射携带不同的远端。公告提到 Quiche 与 quic-go 两种实现能够互通。这是运行代码的有力证据，却不能外推为浏览器已普遍开启、生产环境已经规模化或所有实现都符合要求。

截至 8 月 28 日，Datatracker 仍将其标为活跃 Internet-Draft，IESG 状态是 RFC Ed Queue。IANA 动作正在进行，专家评审通过；RFC Editor 等待引用检查与格式处理。标准批准是事实，RFC 编号和广泛部署则仍需后续证据。

双方都说“是”，绑定才成立

客户端用 Connect-UDP-Bind: ?1 请求扩展，支持它的代理在响应中返回同一个布尔真值。端点只有在既发送又收到该真值后才启用绑定能力；字段若被编码成其他类型，就按没有出现处理。

因此，HTTP 请求成功不自动表示功能已经协商。代理也不能在没有明确信号时，把固定目标请求扩大成多对端公共入口。

请求可以保留一个合法的主机和端口，在绑定不可用时退回普通 CONNECT-UDP；也可以把两个目标变量都设为 *，表示只接受绑定模式。只给其中一个变量使用星号属于格式错误。运行记录应保留这一选择，因为它决定后续 Context ID 0 是否具有固定目标含义。

公共地址首先是一条分配记录

代理接受请求后，至少选取一个公共 IP 和开放端口，将其绑定到这条请求，并通过 Proxy-Public-Address 通知客户端。若只提供一个元组，代理必须在整个隧道生命周期内保持 IP 和端口不变；若提供多个，则建议按地址族保持稳定。由于信息位于 HTTP 响应头，之后发生的地址变化无法用同一字段更新。

稳定性让远端有地方发送，也让 ICE 可以测试候选路径。但它不认证发送者。意定对端、端口扫描器和误投流量都可能触达公共套接字。

日志中的含义必须克制：“已分配公共地址”只证明资源分配，“收到 UDP 包”只证明网络可达。它们都没有证明远端元组已登记、策略允许、代理完成转发、客户端收到，或应用接受了流量。

Context ID 把远端关系变成明确状态

客户端分配偶数 Context ID，代理分配奇数。纯绑定请求中，ID 0 被禁止；若请求包含真实的固定退路目标，0 才保留 RFC 9298 的旧含义。

三个 Capsule 构成生命周期：COMPRESSION_ASSIGN（0x11）提出映射，COMPRESSION_ACK（0x12）确认接收方已经保存，COMPRESSION_CLOSE（0x13）拒绝或关闭映射。

IP 版本为 0 时建立非压缩上下文，每个数据报都携带地址和端口。客户端发往代理时，它们是目标；代理发往客户端时，它们是收到包的来源。IP 版本为 4 或 6 时建立压缩上下文，地址和端口只登记一次，后续数据报以 Context ID 引用共享映射。

约束本身就是权力边界：同一个 ID 不得分配两次，同一个远端元组不能同时有两个 ID，关闭后的 ID 不能重用。乱序到达的旧数据报如果使用已关闭 ID，必须静默丢弃，不能让旧名字唤醒新关系。

协议允许在 ACK 到达前抢先使用 ID，以减少时延。但若分配消息尚未送达或遭拒，这些数据报可以丢失。因此，“已用 ID 发送”是发送方承担风险的动作，不是接收方已经授权的证据。

未知来源的总开关在客户端手里

只有客户端能够申请非压缩上下文，而且同一时间只能打开一个。它的能力很宽：每个收到的数据报都可以携带一个以前未见的来源元组。

客户端可以从一开始就不打开它，也可以随后关闭。此时，代理事实上成为针对陌生来源的防火墙。此前已经建立的压缩映射仍可继续工作，但代理不能在非压缩上下文关闭后新建压缩映射，否则就会绕过客户端刚刚收回的范围。

这意味着缩小授权不必关闭公共端口。公共分配继续存在，已明确建立的对端关系继续存在，未知来源则失去进入隧道的路径。可达、登记和允许是三个状态。

每一个可变目标都要重新过策略

固定目标 CONNECT-UDP 可以在建隧道时检查一次目的地。绑定模式把目标移到数据报或映射里，因此策略判断也必须随之移动。

对于非压缩数据报，代理逐个检查其中的目标地址和端口；对于压缩上下文，则在收到 COMPRESSION_ASSIGN 时检查远端元组并拒绝禁止的目标。企业可以据此保护环回、链路本地、私网、管理网段或特定服务。

标准没有替运营者决定完整策略。它只规定最低限度的执行位置，防止“目标可变”成为绕过访问控制的办法。

TURN 提供了有用的参照。中继地址分配、对端 permission 和 channel binding 是不同状态。两种协议并不相同，但都说明一个原则：得到中继地址不等于得到与任何对端通信的无限权力。

内存与缓冲上限不是附注

每个已接受的 Context ID 都占用内存。受流量控制或拥塞控制影响而无法立即发送的 ACK、CLOSE 会占用响应缓冲。草案要求端点限制同时开放的 Context 数量，也限制待发压缩响应数量；代理达到后一个上限时必须中止请求流。

安全上限若没有可观测性，会表现成随机断线。系统应记录配置额度、当前占用、被拒登记、响应排队、流中止和受影响客户端版本。这样才能区分资源保护在生效，还是实现发生故障。

压缩还会改变有效 MTU。非压缩数据报每次多带地址和端口，压缩数据报则不带；中途切换可能干扰 DPLPMTUD。尽早请求压缩能减少这种变化，但最终仍需以包大小、丢失和路径成功率验证。

一张公共 IP 后面有很多责任主体

RFC 6269 解释了地址共享带来的归因困难、信誉连带和误伤风险。绑定式 UDP 又增加了多个维度：同一代理 IP 可以承载许多端口、隧道、客户端、Context 和远端。

因此，滥用调查不能只保存 IP 和时间。至少要关联公共端口、隧道标识、经认证客户端、Context 状态、远端元组、策略结论和实际转发结果。边缘已丢弃的扫描包不能在报告里变成“用户发送或接收的流量”。

共享地址之所以有用，是因为它是基础设施资源；若把它误当成每条流的身份和授权，反而会摧毁运营共享设施所需的证据。

一个数据报需要怎样的证据链

可靠记录至少包括：

  1. 经认证的请求和隧道身份；
  2. 双向绑定协商结果；
  3. 固定退路或纯绑定模式；
  4. 公共元组及其有效期；
  5. Context ID 的分配方和唯一值；
  6. ASSIGN、ACK、CLOSE 状态；
  7. 压缩或非压缩语义；
  8. 精确的远端来源或目标元组；
  9. 目标策略版本和判定；
  10. Context 与响应缓冲额度；
  11. 接受、丢弃或临时缓冲；
  12. 公共套接字上的实际收发；
  13. 客户端交付与 ICE 或应用结果。

映射建立成功后，路径仍可能丢包，ICE 检查也可能失败。协议状态只允许系统处理；运行结果才证明路径可用。这正是 Running-Code Primacy 的要求：文档定义最小公共规则，本地实现必须用可验证行为承担最终责任。

来源