GlossaryHTTP/3

HTTP/3

HTTP/3 is the third major version of the protocol web browsers use to fetch pages and files, and it runs on QUIC over UDP instead of TCP. HTTP/3 connects faster and handles packet loss better, especially on mobile networks. For video, HLS and DASH segments can be delivered over HTTP/3 without changing the streaming format itself.

Why it matters

Every video segment travels over HTTP, so a faster transport helps every viewer at once. HTTP/3 reduces startup delay and buffering on mobile and congested networks, which protects watch time. It is usually a CDN setting rather than an engineering project, making it a low-cost improvement.

How it works

  1. The browser or app learns that a server supports HTTP/3, often from a header on an earlier response.
  2. It opens a QUIC connection over UDP, with encryption built into the handshake.
  3. Requests for playlists and video segments travel as independent streams in that connection.
  4. If UDP is blocked, the client falls back to HTTP/2 or HTTP/1.1 over TCP automatically.

HTTP/3 vs HTTP/2: what is the difference?

HTTP/3 runs on QUIC over UDP, while HTTP/2 runs on TCP. Both let many requests share one connection, but under HTTP/2 one lost packet stalls every request on that connection. HTTP/3 keeps requests independent and sets up connections faster. It helps most on mobile and lossy networks and less on stable wired connections.

Does HTTP/3 reduce buffering?

It can, especially on mobile networks with packet loss. HTTP/3 avoids the stalls TCP causes when packets go missing, and recovers faster when phones switch networks. It will not fix buffering caused by bitrates that are too high or a slow origin server, so it works best alongside a well-tuned bitrate ladder and CDN.

Where it's used

Short video apps, live sports streamers and global event platforms turn on HTTP/3 at their CDN to start videos faster and reduce buffering on crowded or patchy mobile networks.

By the numbers