WebTransport

Low-latency applications outgrew the single ordered stream WebSocket provides. WebTransport runs client-server messaging over HTTP/3, offering multiple independent streams and unreliable datagrams on one session, so a game update or a live video frame skips the queue behind a lost packet instead of waiting on retransmission.

Table of Contents

Usage

A WebTransport session starts with an extended CONNECT request over HTTP/3: the :protocol pseudo-header carries webtransport, the QUIC connection needs the SETTINGS entry advertising WebTransport support from both endpoints, and a 200 response opens the session. From there the session multiplexes three kinds of traffic:

  • Bidirectional streams: reliable, ordered byte streams either side opens, each independent of the others, so loss on one stream stalls nothing else.
  • Unidirectional streams: the same reliability in one direction, fitting server pushes of state snapshots or client uploads.
  • Datagrams: unreliable, unordered messages with no retransmission, riding QUIC datagram frames, fitting position updates, live audio, and any payload where a late message has no value.

The session inherits QUIC's transport security: TLS 1.3, connection migration, and stream-level flow control. Where the network blocks QUIC, the HTTP/2 mapping tunnels the same model over TCP with reliability emulated, trading away the independent-loss behavior.

In the browser, the WebTransport JavaScript API exposes the session:

const wt = new WebTransport("https://example.re:4433/session");
await wt.ready;
const stream = await wt.createBidirectionalStream();
wt.datagrams.writable.getWriter().write(update);

WebTransport and WebSocket

WebSocket delivers one reliable, ordered message pipe over TCP, so a single lost packet delays every message behind the loss. WebTransport removes the shared queue with independent streams, adds datagrams for traffic where retransmission hurts more than loss, and drops the masking and framing overhead of the WebSocket wire format. WebSocket keeps the edge in reach: universal browser support, plain TCP middlebox compatibility, and a simpler server ecosystem. Services needing broad compatibility run both, preferring WebTransport where the connection supports HTTP/3.

Example

The extended CONNECT exchange opening a session. The request names the protocol and the path scopes the session endpoint.

:method = CONNECT
:protocol = webtransport
:scheme = https
:authority = example.re:4433
:path = /session

:status = 200

After the 200, streams and datagrams tied to the session flow inside the same HTTP/3 connection.

See also

Last updated: September 21, 2026