How Chromium Supports WebTransport Over HTTP/3

This article provides an overview of how the Chromium web browser implements WebTransport over HTTP/3 to achieve low-latency, bidirectional communication between clients and servers. It covers the architectural foundation provided by the QUIC protocol, Chromium's multiprocess networking stack, the handling of reliable streams and unreliable datagrams, and the security mechanisms required to establish these high-performance connections.

The QUIC and HTTP/3 Foundation

To support WebTransport, Chromium relies on HTTP/3, which runs over the QUIC protocol rather than TCP. Chromium implements QUIC and HTTP/3 using its in-house library called QUICHE (QUIC, HTTP, Etc.).

Traditional WebSockets rely on TCP, which suffers from head-of-line blocking—if a single packet is lost, the entire connection stalls until that packet is retransmitted. By building WebTransport on top of HTTP/3 and QUIC, Chromium utilizes UDP to send data. QUIC handles encryption, congestion control, and stream multiplexing at the transport layer, allowing Chromium to process multiple data streams independently without a single dropped packet halting the entire connection.

Chromium's Multiprocess Architecture

Chromium uses a multiprocess architecture to keep the browser secure and stable. Web pages run in restricted "Renderer" processes (powered by the Blink rendering engine), while actual network traffic is handled by a separate "Network Service" process.

To maintain low latency for WebTransport, Chromium minimizes the overhead of moving data between these processes:

  1. Blink API Layer: When a web application instantiates a WebTransport object in JavaScript, Blink creates the corresponding C++ objects to manage the session.
  2. Mojo IPC: Chromium uses its Inter-Process Communication (IPC) system, called Mojo, to link the Renderer process directly to the Network Service.
  3. Data Pipes: Instead of copying data multiple times between processes, Chromium establishes high-performance Mojo data pipes. These shared-memory buffers allow WebTransport streams and datagrams to flow directly from the JavaScript execution environment to the network socket with minimal CPU overhead.

Establishing the Connection

When a client initiates a WebTransport session, Chromium's Network Service executes a specific handshake over HTTP/3:

  • TLS 1.3 Handshake: Chromium establishes a secure QUIC connection using TLS 1.3, which often completes in a single round-trip (1-RTT) or even zero round-trips (0-RTT) if the client has connected to the server previously.
  • Settings Exchange: The browser and server exchange HTTP/3 SETTINGS frames to confirm that both endpoints support WebTransport and QUIC datagrams.
  • Extended CONNECT: Chromium sends an HTTP/3 extended CONNECT request. This request includes a :protocol pseudo-header set to webtransport, alongside the target URL and the Origin header for security verification.
  • Session Readiness: Once the server replies with a 200 OK status, the WebTransport session is established, and Chromium resolves the ready promise in the JavaScript API.

Bidirectional Messaging: Streams and Datagrams

Chromium translates the high-level JavaScript WebTransport API into low-level QUIC frames using two distinct messaging mechanisms:

Reliable Streams

WebTransport supports both unidirectional and bidirectional streams. In the Renderer process, Chromium exposes these as standard JavaScript ReadableStream and WritableStream objects. Under the hood, the Network Service maps each of these streams to a native HTTP/3 QUIC stream.

Because QUIC manages packet loss per stream, Chromium can guarantee that data sent over a WebTransport stream arrives in order and intact, while completely avoiding head-of-line blocking across different streams. Backpressure is managed automatically: if the network is congested, the Mojo data pipe fills up, signaling the JavaScript WritableStream to pause sending data.

Unreliable Datagrams

For ultra-low-latency needs—such as real-time gaming, live telemetry, or media streaming—Chromium implements WebTransport datagrams using the QUIC DATAGRAM extension.

When a developer writes to the datagrams.writable stream, Chromium packages the data into a QUIC DATAGRAM frame and transmits it immediately over UDP. If a datagram is lost in transit, Chromium's QUIC stack does not attempt to retransmit it. It simply drops the packet and continues processing new incoming and outgoing datagrams, ensuring the lowest possible latency.

Security and Congestion Control

Because WebTransport operates over UDP, Chromium enforces strict rules to prevent the browser from being used in Distributed Denial of Service (DDoS) attacks or unauthorized data scraping:

  • Mandatory Encryption: All WebTransport traffic in Chromium is encrypted via TLS 1.3. Plaintext connections are not supported.
  • Custom Certificate Verification: For developers using ephemeral servers (like game servers) where standard Certificate Authorities are impractical, Chromium supports the serverCertificateHashes option. This allows the browser to authenticate a connection by matching the server's TLS certificate against a known SHA-256 hash, provided the certificate's validity period is 14 days or less.
  • Congestion Control: Even when sending unreliable datagrams, Chromium does not allow web apps to flood the network. All WebTransport traffic is governed by QUICHE's congestion controller (typically using algorithms like Cubic or BBR). If the network capacity drops, Chromium automatically throttles the rate at which datagrams and stream packets are sent.