摘要：WebTransport 是一种依托于 HTTP/3 与 QUIC 协议的当代网络传输技术，设计目的是为 Web 应用赋予高效、低延迟的双向通信之能。它于 UDP 协议之上构筑起可靠的传输层，成功化解了传统 TCP 所存在的队头阻塞之难题，对多路复用的数据流以
WebTransport
WebTransport 是一种依托于 HTTP/3 与 QUIC 协议的当代网络传输技术，设计目的是为 Web 应用赋予高效、低延迟的双向通信之能。它于 UDP 协议之上构筑起可靠的传输层，成功化解了传统 TCP 所存在的队头阻塞之难题，对多路复用的数据流以及不可靠的数据报传输予以支持。WebTransport 的核心优势体现于能够同步处置多个独立的双向流与单向流，每一个流均可单独设定可靠性，正因如此，它尤为契合实时性需求颇高的场景，诸如在线游戏、视频直播以及物联网设备控制等。相较于 WebSocket，WebTransport 提供了更为精细的流控制，与此同时，继承了 QUIC 协议的加密和连接迁移之特性，有力保障了数据传输的安全性与稳定性。
一张老图，HTTP/2有问题，需辟谣
WebTransport 的主要功能包括：可靠的有序流传输、低延迟的不可靠数据报传输以及灵活的双向通信机制。开发者能够凭借简洁的 JavaScript API 来创建与管理多个数据通道，例如发送实时游戏数据或者接收媒体流。鉴于基于 HTTP/3，WebTransport 天然具备 TLS 加密功能，并且能够于网络环境发生变化时维系连接，比如从 WiFi 切换至移动网络。此外，其多流复用的特性准许不同优先级的数据并行传输，规避单一数据流的拥塞对整体性能造成影响。这种设计致使它在高并发和实时交互的场景中表现卓异，成为 WebRTC 和 WebSocket 的有力补充。
需要辟谣的是，上面那张老图，暗示了 WebTransport 也有基于 HTTP/2 的实现，实际上并没有。
WebTransport 的标准化实现并未基于 HTTP/2，而是完全依赖 HTTP/3 和 QUIC 协议。虽然早期曾有技术探索尝试在HTTP/2上模拟类似功能（如内网穿透工具 Pangolin 通过 HTTP/2 多路复用实现客户端与服务端的通信），但由于 HTTP/2 底层仍基于 TCP 协议，其固有的队头阻塞问题、连接迁移能力缺失以及无法支持原生数据报（Datagram）等缺陷，使得这种实现无法满足 WebTransport 对低延迟、多流并行和可靠性可配置的核心需求。
此外，HTTP/2 缺乏 QUIC 协议的 0-RTT 快速握手和网络切换时的连接保持能力，而这两者正是WebTransport实现高效实时通信的关键特性。因此，IETF 和 W3C 在制定 WebTransport 标准时，明确将其设计为 HTTP/3 的扩展，充分利用 QUIC 在 UDP 层提供的多路复用、流独立性和混合传输模式（可靠流与不可靠数据报）。任何基于 HTTP/2 的类似方案，本质上只能通过多个 TCP 流模拟有限并发，无法突破 TCP 协议层的根本限制。
另外，你可能还见过这张图：
另一张老图，多了早期草案QuicTransport
在 WebTransport 标准化进程中，QuicTransport 曾作为早期草案的命名出现，主要用于探索基于 QUIC 的直接传输能力。然而，随着 HTTP/3 的成熟，IETF 和 W3C 将 WebTransport 设计为 HTTP/3 的扩展框架，统一了接口规范。因此，QuicTransport 已不再作为独立协议存在，而是融入 WebTransport 的实现中。
从浏览器服务端到客户端的反向通信角度看，目前还有两个常用方案。以下是对三个方案的对比。
特性WebTransportWebSocketHTTP SSE底层协议HTTP/3 + QUIC（基于 UDP）HTTP 升级（基于 TCP）HTTP（基于 TCP）通信模式双向（客户端↔服务端）双向（客户端↔服务端）单向（服务端→客户端）数据流类型支持可靠流（有序）、不可靠数据报、多路复用单一可靠文本/二进制流单向下行文本流（UTF-8）连接开销低（QUIC 减少握手次数，支持 0-RTT）中等（需 HTTP 升级握手）低（普通 HTTP 请求，长连接）延迟极低（基于 UDP，无队头阻塞）较低（依赖 TCP，可能受队头阻塞影响）较高（需频繁 HTTP 请求或长轮询）可靠性可配置（可靠流或不可靠数据报）可靠传输可靠传输多路复用✔️（多个独立流数据并行传输）❌（单流通信）❌（单流通信）早期的Web实时通信主要依赖 WebSocket 技术，虽然它解决了HTTP轮询的效率问题，但仍受限于TCP协议固有的队头阻塞问题。随着2015年Google推出QUIC协议，一种基于 UDP 的新型传输协议开始进入人们的视野。QUIC 协议的多路复用、0-RTT 握手等特性为WebTransport的出现奠定了技术基础。2018年，HTTP/3 标准开始制定，正式将 QUIC 协议引入Web领域，这直接促成了 WebTransport 概念的提出。
2020年成为WebTransport发展的关键转折点。W3C成立了专门的工作组，开始制定WebTransport的标准规范。与此同时，Chromium团队率先在Chrome浏览器中实现了实验性支持。这一时期的技术讨论主要围绕如何将QUIC协议的特性更好地暴露给Web开发者，同时保持与现有Web安全模型的兼容性。IETF 也同步开展了相关协议的标准化工作，确保底层传输协议的可靠性。
2022年至2023年，WebTransport技术进入快速发展期。主流浏览器厂商相继宣布支持，其中Chrome和Firefox率先实现了稳定版本的支持。云服务提供商如Cloudflare开始提供基于HTTP/3的基础设施支持，使得WebTransport的部署成为可能。这一时期还涌现了大量实践案例，特别是在实时游戏、低延迟视频传输等领域，WebTransport展现出了明显优于WebSocket的性能优势。
进入2024年，WebTransport技术已趋于成熟。最新数据显示，全球超过85%的浏览器已支持该技术。W3C的标准制定工作也进入最后阶段，预计将在年内发布正式推荐标准。与此同时，开发者社区围绕WebTransport构建的工具链和框架日益丰富，大大降低了使用门槛。一些创新应用场景，如元宇宙中的实时交互、物联网设备控制等，正在推动WebTransport向更广阔的应用领域发展。
尽管 WebTransport 具备显著的优势，然而其普及依旧面临若干挑战。当下，浏览器的支持程度有限，主要聚焦于 Chrome 和 Firefox，而 Safari 等浏览器仍处于开发进程之中。服务器端同样需要专门的 HTTP/3 和 QUIC 支持，这给传统基础设施提出了升级的需求。不过，伴随云计算和 CDN 服务商逐步实现适配，WebTransport 有望于未来成为 Web 实时通信的标准解决方案之一，为下一代互联网应用赋予更强劲的数据传输能力。
浏览器兼容
截图源于：WebTransport - Web APIs | MDN 。这里还有更多可选功能的兼容情况。但简单总结一下就是两点：
Firefox都支持。除了Apple的生态，主要WebTransport的主要功能在别的地方都支持。也就是说，如果是没有（iOS）移动端、以及没有苹果MacOS的应用场景，比如企业内的一些to B应用，可以用 WebTransport。但凡需要to C，基本上就不能用，或至少要准备降级方案，需要先等 Apple 的支持。
除了浏览器兼容性，WebTransport 技术仍面临一些其它挑战，如企业级部署的复杂性、与传统系统的兼容性等问题。但随着 HTTP/3 的普及和边缘计算的发展，WebTransport 有望成为下一代 Web 实时通信的基础设施。其独特的多流复用、可配置可靠性等特性，将为 We b应用带来更接近原生应用的网络性能体验。
来源：界世看眼睁
