WebTransport：为什么实时 AI 应用不一定应该使用 WebSocket？
TL;DR
解释 WebTransport 的可靠流、双向流和 Datagram，比较它与 SSE、WebSocket、WebRTC 的适用场景和安全边界。
WebSocket 适合通用双向消息，但复杂实时 AI 应用还可能需要可靠流、双向流和可以丢弃的临时数据。本文解释 WebTransport 的 session、stream 和 datagram，比较它与 SSE、WebSocket、WebRTC 的边界，并讨论鉴权与部署。
当网页只需要把一段文字逐字显示出来，SSE 或 WebSocket 往往已经够用。但一旦应用同时传输语音、模型事件、工具结果、状态更新和临时数据，单一的有序通道就会开始暴露问题：一条消息卡住，后面的消息也可能只能排队等待。
WebTransport 提供了另一种浏览器到服务器的通信模型。它建立在 HTTP/3 或 HTTP/2 之上，同时提供可靠流、双向流和 Datagram，让应用可以按数据的重要程度选择不同的传输方式。
先给结论：WebTransport 是“多种可靠程度的实时通道”
W3C 的 WebTransport 规范定义了浏览器和服务器之间的 ECMAScript API。一个 WebTransport session 可以创建单向流、双向流，也可以发送和接收 datagram；当前规范仍处于 Candidate Recommendation 阶段，底层协议和 API 都可能继续变化。W3C WebTransport 规范
这和 WebSocket 的重要区别是：WebSocket 更像一条持续的、有序的消息管道；WebTransport 更像一组可以并行使用的传输通道。
为什么 AI 应用会需要不止一条通道
一个语音 Agent 的一次会话里，可能同时有这些数据：
- 麦克风上传的音频帧；
- 模型返回的音频帧；
- 文字转写的中间结果；
- 工具调用的进度事件；
- 最终答案和可点击的操作；
- 心跳、取消和重连信息。
这些数据的重要性和容错要求不同。最终订单金额必须可靠送达；一个过时的波形进度点丢掉了，通常没有必要重传。如果所有数据都放在同一条严格有序的管道里，低价值的数据也可能拖住高价值的数据。
WebTransport 允许应用把它们拆开：
需要强调的是：Datagram 的“可以丢”不是 WebTransport 自动替你做出的业务决定。应用必须自己判断哪些数据过期后没有价值，哪些数据即使晚到也必须补偿。
用一个实时 AI 场景理解它
假设用户在浏览器里和语音助手对话。助手正在调用天气服务，并且不断生成语音。可以这样划分：
- 用户意图、工具参数和确认结果走可靠双向流；
- 语音片段走可靠流，避免播放出现无法恢复的断裂；
- 当前音量、波形和延迟指标走 Datagram，旧数据被新数据覆盖也没关系；
- 取消请求可以通过控制流立即发送，而不是排在大量音频数据后面。
这类划分比“所有内容都塞进 JSON 消息”更清晰，但也把更多设计责任交给应用：消息 framing、序列号、重放、取消、超时和重连都需要明确约定。
它和 WebRTC、WebSocket、SSE 怎么选
| 技术 | 强项 | 更适合的场景 |
|---|---|---|
| SSE | 服务端向客户端推送文本事件 | 简单的模型文本流、通知 |
| WebSocket | 双向、成熟、生态广 | 通用实时消息和协作功能 |
| WebRTC | 媒体、点对点、低延迟 | 音视频通话和实时媒体 |
| WebTransport | 多流、Datagram、HTTP 生态 | 复杂实时协议和高频状态同步 |
WebTransport 不是“更现代所以总是更好”。如果应用只需要服务端逐字返回一段文本，SSE 更容易部署；如果需要大量浏览器之间直接传输音视频，WebRTC 仍然更贴合问题。只有当你确实需要多种流语义和可丢弃数据时，WebTransport 的复杂度才值得付出。
HTTP/3 是常见底层，但不是唯一底层
很多介绍会把 WebTransport 和 QUIC、HTTP/3 直接画等号。更准确的说法是：WebTransport session 可以运行在 HTTP/3 或 HTTP/2 之上。HTTP/3 通过 QUIC 提供多路传输能力，HTTP/2 则提供另一条兼容路径。规范中的 session 定义
因此，部署时不能只在浏览器里写好 JavaScript，还要检查：
- 服务器是否支持相应的 WebTransport 协议；
- 反向代理和负载均衡是否会正确转发；
- 中间网络是否允许所需的连接方式；
- 是否设计了不支持 WebTransport 时的回退路径。
身份认证不能照搬普通 HTTP 请求
WebTransport 使用 TLS 保护通信，但它并不自动替代应用层身份系统。W3C 规范的安全章节指出，WebTransport over HTTP 不会自动发送普通 HTTP 请求中的 Cookie，也不提供传统 HTTP 认证和缓存失效机制。WebTransport 安全考虑
这意味着应用需要明确设计会话绑定方式，例如在建立连接时使用一次性令牌，或者通过已认证页面获取短期连接凭证。令牌不能长期放在 URL 中，更不能把“连接已经加密”误当成“用户已经被授权”。
现在该不该使用
截至目前，WebTransport 仍是正在演进的标准。它适合需要实时交互、多个数据通道和不同可靠性等级的产品原型，也适合作为音频 Agent、多人协作或实时仿真系统的研究方向。
如果业务只是普通聊天流，优先把协议、重试和鉴权做简单，往往比换成 WebTransport 更有价值。
一句话总结：WebSocket 给你一条实时管道，WebTransport 让你拥有一组可以分别管理的实时通道。
