Skip to content

WebTransport- An Introduction

  • In this post, I will introduce WebTransport and explain it in comparison with existing alternatives. As a relatively new protocol, it offers useful capabilities for modern real-time applications, along with its own set of trade-offs.

  • Every machine on the internet is identified by an IP address, and data is exchanged over the IP layer using transport protocols. WebTransport is built on top of this transport layer as explained below.

  • A good understanding of WebTransport requires familiarity with the QUIC protocol, since WebTransport is built on top of QUIC.

1. Background

  • Above the IP layer, the two foundational transport protocols are TCP and UDP.

  • These two protocols represent fundamentally different trade-offs in how data is delivered: TCP prioritizes reliability and ordered delivery, while UDP prioritizes low latency and minimal overhead.

  • In practice, the choice between them depends on application requirements such as reliability, latency sensitivity, and real-time behavior.

  • Above the transport layer(TCP/UDP) there are other protocols that are for application needs such as Http, ftp etc.

  • WebTransport is a modern web API designed for real-time communication. It is not a replacement for TCP or UDP, but instead builds on top of UDP through QUIC, enabling more flexible transport semantics for web applications.

flowchart TD

A["WebTransport API"]
B["QUIC (Streams + Datagrams)"]
C["UDP"]
D["IP Layer"]
E["Network"]

A --> B
B --> C
C --> D
D --> E

2. QUIC is enhanced-UDP

  • UDP is a fast transport protocol, but not reliable; TCP on the other hand is reliable but slow.

  • UDP (unlike TCP) does not establish connections, does not guarantee delivery, and does not enforce ordering.

  • This makes UDP extremely fast and efficient for real-time use cases. There is no head-of-line blocking, no retransmission delay, and no connection setup overhead. Applications can send data immediately with minimal protocol interference.

  • However, this simplicity comes at a cost: UDP is completely unreliable. Packets can be lost, duplicated, or delivered out of order,

  • To solve this, QUIC was introduced. It preserves the performance advantages of UDP while adding back the essential features required for modern internet applications, such as reliability, congestion control, and built-in security.

Feature TCP UDP QUIC
Reliability Reliable (retransmits lost data) Unreliable (no guarantees) Reliable (per-stream reliability)
Ordering Strict global ordering No ordering Ordering per stream (no global blocking)
Encryption Optional (via TLS layer) Not built-in Built-in (TLS 1.3 integrated)
Implementation location Kernel space Kernel space User space (typically over UDP)
Typical use cases Web pages, APIs, databases Gaming, voice, streaming HTTP/3, WebTransport, modern real-time web apps

3. What is WebTransport

  • HTTP is the core web protocol used by the browser. Traditionally, it runs over TCP (as in HTTP/1.1 and HTTP/2), while newer versions like HTTP/3 run over QUIC.

  • Inside the browser, there are APIs that expose modern networking capabilities built on top of QUIC, which itself runs over UDP.

  • WebTransport is not a protocol that applications use directly. Instead, it is a browser API that exposes QUIC’s transport features such as streams and datagrams to web applications.

flowchart TD

A["Web App"] --> B["WebTransport API"]
B --> C[QUIC]
C --> D[UDP]

C --> E[Streams]
C --> F[Datagrams]

---linux

4. WebTransport client and server

  • Client: WebTransport is primarily a browser API. Therefore, browser is the client.
  • Server: must run a WebTransport-compatible server over QUIC

Example: 

new WebTransport("https://example.com")

  • What happens under the hood:
Browser
 → HTTP/3 request
 → QUIC connection (over UDP)
 → WebTransport session starts

flowchart TD

A["Web App (Client)"] --> B["WebTransport API"]

B --> C["HTTP/3 over QUIC"]
C --> D["QUIC over UDP"]

C --> E["WebTransport Session"]

E --> F["Streams (reliable data)"]
E --> G["Datagrams (fast/unreliable data)"]

E --> H["WebTransport Server"]

5. WebTransport client and server

  • WebTransport is useful when we need:
- Multiple independent streams (like many WebSockets in one connection)
- Datagrams (unreliable, fast messages) like UDP
- Low latency over QUIC (better under bad networks than TCP)
  • Practical use-cases:
- Multiplayer games (real-time action)
- Live dashboards / trading systems

6. Some examples of WebTransport servers

  • A WebTransport server is one that speaks HTTP/3 + QUIC + WebTransport session semantics

  • Some examples:

  • Cloudflare WebTransport (production-grade example)

  • Go QUIC servers (quic-go)
  • MOQ (Media over QUIC)

7. Where WebSockets actually fit w.r.t. WebTransport

  • When websockets were created (~2010 era): 

    - browsers needed real-time communication
- HTTP was request/response only
- no streaming, no push

  • So WebSockets solved: 

    - persistent connection
- bidirectional messaging
- low latency vs polling

  • Because they sit on TCP (unlike WebTransport which sits on top of QUIC->UDP) 

    - Head-of-line blocking issue
- Single stream only
- No datagrams
- TCP limitation (kernel-level, strict ordering, slow)

  • The web moved from TCP-era thinking → QUIC-era networking 

    - HTTP/3 -> QUIC -> UDP
- Multiple streams
- Datagrams (huge deal)

Reference(s)

QUIC protocol