Why architecture matters here
WebTransport architecture matters because it fills a real gap. WebSocket over TCP suffers from head-of-line blocking; multiple messages on the same connection queue behind slow ones. WebRTC solves this but is complex — its stack is designed for peer-to-peer. WebTransport gives you WebRTC's transport benefits with WebSocket's simplicity.
Cost is proportional to HTTP/3 adoption. Deployments that already run HTTP/3 add WebTransport almost for free.
Reliability comes from QUIC's connection migration and stream independence. Mobile users on flaky links see materially better UX.
The architecture: every piece explained
Walk the diagram top to bottom.
Browser. WebTransport API in JavaScript. new WebTransport(url) opens a session.
QUIC transport. Under the hood, HTTP/3 over UDP. All of QUIC's benefits: multiplexed streams, 0-RTT, connection migration.
Server. HTTP/3-capable endpoint that accepts WebTransport sessions via CONNECT UDP.
Reliable streams. Ordered bidirectional streams. Similar to WebSocket but multiple per session, no head-of-line blocking.
Unreliable datagrams. Per-message; not retransmitted; small; low latency. For game state, media, telemetry.
Session per URL. One WebTransport session over one HTTP/3 connection. Client can multiplex many streams and datagrams.
Origin auth. Standard HTTP cookies + JWT. Server checks on session accept.
Connection migration. IP change (WiFi → cellular) doesn't drop; session continues.
vs WebSocket. Multiple streams + datagrams + HTTP/3 benefits.
vs WebRTC. Simpler client-server; no ICE/STUN/TURN complexity.
End-to-end session flow
Trace a session. Browser: new WebTransport("https://game.example.com/wt"). Opens HTTP/3 connection, sends CONNECT UDP request.
Server accepts. Session established. Client opens 3 bidirectional streams: state updates, chat, admin.
Simultaneously sends datagrams for player position updates — 60 per second, tiny payloads, no retransmit.
Packet loss: one datagram lost. Not retransmitted; game state extrapolates. Streams unaffected — chat continues.
User moves from WiFi to cellular. QUIC migration: session continues with new IP. No re-handshake, no reconnect logic.
User closes tab. Session ends. Server cleans up.
Compare WebSocket: single connection, no unreliable messages, no migration. Would need reconnect + resync logic.
Compare WebRTC: could do the above but requires ICE candidates, TURN servers for restrictive NATs, more complexity.