WebRTC 数据通道建立了 6 个网络往返才通，其中两个从第一天起就是白等的——Edge 154 用一个新协议把它们消掉了

一个语音 Agent 从用户点下「开始对话」到听见第一句话，中间有整整 6 个网络往返在排队。其中有两个往返，是 SCTP 的握手——而这两个往返,在 WebRTC 里从第一天起就是多余的。

这就是 SNAP 要解决的问题。全称 SCTP Negotiation Acceleration Protocol（SCTP 协商加速协议），已经被 Edge 154 列进 web platform release notes，Chrome 的 origin trial 覆盖 M151–156，Field Trial 名 WebRtcSctpSnap。

先把结论放在最前面：SNAP 把 WebRTC 数据通道的建立时间砍掉最多两个网络往返，方式是把 SCTP 的初始化参数提前塞进 SDP 的 offer/answer 里交换。对你手上的代码，几乎是零改动——它发生在你 createDataChannel() 之前的那一层。

要理解它为什么能成立，得先看 SCTP 的握手在防什么。SCTP 建立关联用的是标准的四步握手：INIT、INIT-ACK、COOKIE-ECHO、COOKIE-ACK，正好两个往返。那个”cookie”是防 SYN 洪泛的——半开连接会占住服务器的状态，所以协议要求先发一个带鉴权 cookie 的往返，确认对方的地址是真的，再真正建立连接。

问题是，WebRTC 里的 SCTP 并不直接跑在 IP 上。它是封装在 DTLS 之上的（RFC 8261）。而 DTLS 本身已经完成了对端身份验证、建立了加密通道——也就是说，SCTP 那个防半开攻击的 cookie 往返，防的是一个 DTLS 已经防过一遍的攻击。两个往返，全程在做无用功。

SNAP 的做法是把 SCTP 的 INIT 参数（初始传输序列号、各种扩展协商项）搬出网络往返，放进 SDP offer/answer 里。双方在任何一个 SCTP 包发出之前，就已经知道了对方的初始化参数。握手被”消掉”了，两个往返直接归零。

这不是空想。OpenAI 对语音场景做过实测：在丢包敏感的环境下,这个指标（到数据通道可用时间的 P95）最高降低了约 6 倍。为什么降幅能到 6 倍而不是”少两个 RTT”那么线性？因为握手本身对丢包高度敏感——每丢一个包就是一次 RTO 重传。把两个往返彻底去掉，等于把这部分重传超时的尾部风险一起扔了。P95 这种尾部指标，收益往往比平均值大得多。

哪些场景能吃到这个收益，哪些吃不到，边界很清楚：关键要看数据通道是不是卡在用户等待的路径上。

• 语音 Agent：数据通道承载控制信令或转写文本，人在等机器开口，每一毫秒都是感知延迟
• 云游戏/远程桌面：输入事件就走数据通道，建立慢了就是开头那一下卡
• 实时竞价、拍卖、交易：第一条消息有硬性时限
• 纯 P2P 文件传输/同步：没有媒体，整个感知延迟就是建立时间

反过来，如果你的页面开了数据通道但没有任何东西在等它（比如后台预热连接），少两个往返你也感受不到。

现状要说清楚，别指望它明天全量可用：

• 规范侧：draft-hancke-tsvwg-snap-00 于 2025-12-30 发布，2026-07-03 过期，等工作组采纳前会先修订。它是 WARP（WebRTC Abridged Roundtrip Protocol）的一部分。
• 浏览器侧：Chrome/Edge 在 origin trial（M151–156），默认关闭。Firefox、Safari 目前无信号。
• 服务端侧：代码早已进 libWebRTC（field trial 后面），Pion 也已实现。但浏览器对 SFU 的部署里，媒体服务器同样得支持，才能真正省下这两个往返。

顺便提一下 WARP 这个更大的盘子，能帮你看清坐标系。WARP 的目标是把 WebRTC 建立从 6 个往返压到 2 个，分三步：DTLS 1.3 把加密握手从 2 个往返降到 1 个（Chrome 已默认开启）；SNAP 消掉 SCTP 那 2 个往返；SPED 把 DTLS 记录塞进 ICE 已经在发的 STUN 绑定请求里，让加密握手和连通性检查并行。三件叠加，才是”1 个信令往返 + 1 个媒体往返”。

所以你现在可以做的下一步很具体：

第一，如果你在做语音 Agent 或实时互动产品，去 Chrome/Edge 的 origin trial 注册页面把你的域名登记上，把 WebRtcSctpSnap 打开，在真实弱网环境（不是 localhost）跑一遍你的首包延迟，拿到的是你自己场景里的真实数字，而不是我这里的 P95 参考值。

第二，加特性检测和优雅降级。origin trial 随时可能变化或下线，代码里不要假设它一定在。

第三，盯住你的 SFU/媒体服务器有没有跟进 SNAP 和 SPED。客户端开了、服务端没开，这两个往返一分都省不下来——这是最容易白忙一场的地方。