WebTransport: The Future of Real-Time in Browsers

Online shooter. 20 players, positions updated 20 times per second. WebSocket: one TCP packet lost - all 400 messages/sec freeze until retransmit. Spike of 100-300ms. In a shooter that means death. WebTransport datagrams: a drop means the next position arrives in 50ms. That is the difference.

• **Google Meet**: experiments with WebTransport to reduce video jitter. QUIC allows independent transmission of audio and video streams without mutual blocking
• **Cloudflare Workers**: WebTransport support since 2023. Edge servers with HTTP/3 + WebTransport for global low-latency real-time
• **Unity WebGL**: considering WebTransport as a replacement for WebSocket in browser games. Datagrams for positions, reliable streams for game events

WebTransport: QUIC Instead of TCP for Browsers

2022. Chrome and Firefox ship WebTransport - a browser API over HTTP/3 (QUIC). QUIC runs over UDP but with TCP reliability and TLS 1.3 built in. The key: QUIC eliminates head-of-line blocking that plagues WebSocket (over TCP): a lost packet only blocks its own stream, not all streams.

WebTransport provides two modes: datagrams (UDP semantics: fast, no guarantee) and streams (TCP semantics: reliable, ordered). N independent streams can be opened - a lost packet in one does not block others. This is impossible in WebSocket: one TCP connection, one packet queue.

QUIC parallel: HTTP/2 multiplexing solved head-of-line blocking at the HTTP level - multiple requests over one TCP connection. But if a TCP packet is lost, buffering blocks ALL HTTP/2 streams. QUIC solves this at the transport level: each QUIC stream is independent. WebTransport is HTTP/2 multiplexing, fixed.

Datagrams: Unreliable Delivery for Real-Time

Datagrams are UDP semantics in the browser. No delivery guarantee, no ordering, no retransmission. For real-time data this is a feature: a stale player position from 50ms ago is not needed - a new one arrives in 50ms. Retransmit would create a latency spike; a datagram simply gets dropped. This is a game-changer for games, voice, and video.

MTU limitation: datagrams are bounded by the QUIC packet size (~1,200 bytes). Use streams for larger data. Practice: player positions (20-50 bytes) -> datagrams. Map download (MB) -> stream. WebRTC DataChannel also supports unreliable mode, but WebTransport is simpler to configure (no ICE/STUN/TURN).

Streams: Multiplexing Without Head-of-Line Blocking

WebTransport streams are reliable and ordered, like TCP, but independent. Each stream is a separate QUIC stream. A lost packet in the 'chat' stream does not block the 'game events' stream. This solves the main WebSocket problem: one TCP connection = one queue = head-of-line blocking for everything.

WebTransport vs WebSocket: When to Choose Which

WebTransport does not kill WebSocket - they target different tasks. WebSocket: broad support (all browsers since 2011), simplicity, ideal for chats and notifications where latency is not critical. WebTransport: cutting-edge (Chrome 97+, Firefox 114+, Safari experimental), requires HTTP/3 server, more complex to configure, but no head-of-line blocking.

Production status: WebTransport is used in Zoom Web Client (for jitter reduction), Google Meet, and experimentally in online games. Cloudflare supports WebTransport on Workers. Main barrier: HTTP/3 server infrastructure is more complex than HTTP/2, and browser support is not yet complete. Forecast: WebTransport will become the standard for browser real-time within 2-3 years.

Related Topics

WebTransport is the next step in the evolution of browser real-time protocols:

• WebSocket Protocol — WebSocket is the primary analog. WebTransport solves its head-of-line blocking problem
• Approach Comparison — WebTransport occupies a place in the matrix: reliability vs latency vs browser support
• Pub/Sub Pattern — WebTransport streams and datagrams implement pub/sub and streaming patterns in a new way

Key Ideas

• **WebTransport = QUIC in the browser**: over HTTP/3, TLS 1.3 built in. Eliminates TCP head-of-line blocking.
• **Datagrams**: unreliable, unordered. UDP semantics for game positions, voice, video - dropping is better than retransmit.
• **Independent streams**: N streams in one connection. A lost packet in stream A does not block stream B.
• **WebSocket vs WebTransport**: WebSocket - 99% of browsers, simple, for chat. WebTransport - Chrome/Firefox, needs HTTP/3, for games/video.
• **Status 2024**: production in Google Meet, Cloudflare. Safari experimental. Standard within 2-3 years.

Вопросы для размышления

• WebTransport requires an HTTP/3 server. How to assess the cost of infrastructure migration (nginx -> caddy/quiche) for a specific project?
• Datagrams are limited by MTU (~1,200 bytes). How to design game position messages for 60 players within this constraint?
• WebRTC also supports unreliable DataChannel. When to choose WebRTC and when WebTransport for a browser game?

Связанные уроки

• rt-15 — MQTT is the other end of the spectrum: IoT vs browser real-time
• rt-04 — WebSocket is the primary analog for comparison
• rt-17 — WebTransport implements pub/sub and streaming patterns with QUIC
• net-03-physical — QUIC over UDP - understanding the network stack is helpful
• rt-06 — WebTransport extends the protocol comparison as a new-generation candidate
• net-24-http2-http3