Why HTTP/3 Matters: Understanding QUIC’s Leap Over TCP

On June 6, IETF QUIC and HTTP working group member Robin Marx announced that after five years of effort, HTTP/3 has been standardized as RFC 9114, marking the third major version of the Hypertext Transfer Protocol. At the same time, HTTP/2 was updated to RFC 9113, and the common HTTP semantics and caching concepts in HTTP/1.1 were reinforced in RFC 9110‑9112.

HTTP/3 adopts Google’s long‑standing UDP‑based QUIC protocol, originally called HTTP‑over‑QUIC, which was renamed to HTTP/3 by the IETF in 2018. Today, Cloudflare, Google Chrome, and Firefox Nightly all indicate support for HTTP/3.

HTTP/1.1 transmits messages using space‑separated text fields. Although human‑readable, this format leads to parsing complexity and excessive tolerance for variant behavior. HTTP/1.1 lacks a multiplexing layer, so multiple TCP connections are often used in parallel, which negatively impacts congestion control and network efficiency.

HTTP/2 introduced binary frames and a multiplexing layer, improving latency without changing the transport layer. However, because HTTP/2’s multiplexing is invisible to TCP’s loss‑recovery mechanisms, lost or reordered packets cause all active streams to pause, even if a particular stream was not directly affected.

To solve the head‑of‑line blocking issue in HTTP/2, HTTP/3 no longer relies on TCP but uses Google’s open‑source UDP‑based protocol QUIC, extending HTTP/2’s multiplexing with streams and enhancing blocking control and header compression.

QUIC is a general‑purpose transport protocol similar to TCP, but beyond HTTP and web page loading it can be used for scenarios such as DNS, SSH, SMB, RTP, and more.

According to Marx, QUIC improves TCP in four main ways: deep integration with TLS, support for multiple independent byte streams, use of connection IDs, and a frame‑based architecture. QUIC runs over UDP (supported by most network devices), is almost fully encrypted by default, and employs a flexible frame mechanism.