HTTP/3 and QUIC

HTTP/3 uses QUIC over UDP to carry multiplexed HTTP communication, with transport behavior designed for modern network conditions. Its stream-based design avoids some head-of-line blocking effects associated with HTTP/2 over TCP and supports connection migration.

HTTP/3 is the HTTP version that maps HTTP semantics onto QUIC rather than TCP. QUIC runs over UDP but provides transport features such as reliable delivery, congestion control, ordered delivery within streams, and connection management above UDP.

A QUIC connection can contain many independent streams. Loss affecting one stream does not require unrelated streams to wait for the missing TCP segment, which reduces transport-level head-of-line blocking compared with HTTP/2 over a single TCP connection. HTTP/3 therefore retains HTTP/2-style multiplexing while changing the underlying transport.

QUIC also integrates TLS 1.3 into its connection establishment. This reduces the number of protocol layers involved in setup and provides encrypted transport by default. QUIC can identify a connection independently of a particular network path, allowing a connection to survive changes such as moving between Wi-Fi and cellular networks.

For frontend performance, HTTP/3 can be beneficial on networks with packet loss, changing paths, or high latency. However, it is not automatically faster for every request: performance depends on network conditions, server support, congestion, caching, request patterns, and client behavior.

Key points

Interview questions

What role does TLS play in QUIC?

QUIC incorporates TLS 1.3 into its connection establishment rather than layering a separate TLS record protocol over an established transport connection. TLS authenticates the endpoints and establishes encryption keys. QUIC uses the resulting cryptographic state as part of its transport handshake. This makes encrypted transport a fundamental part of QUIC connections.

What is HTTP/3, and how does it differ from HTTP/2?

HTTP/3 is an HTTP protocol that uses QUIC as its transport instead of TCP. QUIC runs over UDP but provides reliable delivery, congestion control, encryption, and multiple independent streams. HTTP/2 also multiplexes requests, but its streams share TCP's ordered byte stream. Because QUIC manages streams independently, packet loss on one stream does not necessarily stall unrelated streams.

Why can HTTP/3 perform better on lossy networks?

In HTTP/2 over TCP, a lost TCP segment can prevent later bytes from being delivered to the application even when those bytes belong to different HTTP streams. QUIC tracks streams independently, so loss affecting one stream does not inherently block delivery of data from other streams. This can reduce latency amplification caused by packet loss. The actual performance improvement still depends on network and workload characteristics.

Why is QUIC built on UDP instead of defining a new transport protocol directly?

UDP provides a widely deployed datagram mechanism that avoids requiring a new IP transport protocol to be accepted throughout the Internet. QUIC can then implement its own transport behavior in user space. It adds reliability, congestion control, stream multiplexing, encryption, and connection management above UDP. This also lets QUIC evolve without being constrained by the deployment model of TCP.

How can QUIC support connection migration?

QUIC uses connection identifiers rather than relying solely on a TCP-style four-tuple to identify a connection. A client can therefore change its network path while retaining the logical QUIC connection, subject to protocol validation and network conditions. This is useful when a device moves between interfaces such as Wi-Fi and cellular. It can avoid forcing the application to recreate its connection after every path change.