HTTPS, SSL & Security
What is HTTP/3?
HTTP/3 is the third major version of the HTTP protocol, the communication standard governing data exchange between browsers and web servers. Standardised in RFC 9114 in June 2022 HTTP/3 represents the most fundamental architectural change in HTTP’s history, replacing the TCP transport layer that HTTP has used since its inception with QUIC, a new transport protocol built on UDP. This transport layer replacement addresses the one significant performance limitation that HTTP/2 could not solve, TCP head-of-line blocking, while preserving and extending all of HTTP/2’s multiplexing, header compression, and performance improvements.
HTTP/3 is not simply an incremental improvement to HTTP/2 in the way that HTTP/2 improved HTTP/1.1. The change from TCP to QUIC is architectural, it affects connection establishment, encryption integration, stream multiplexing, and congestion control at the most fundamental level. The result is a protocol that performs significantly better on the unreliable, high-latency network conditions that characterise mobile connections and networks with packet loss, while matching or exceeding HTTP/2 performance on reliable connections.
Like HTTP/2 HTTP/3 maintains complete semantic compatibility with previous HTTP versions, the same methods, status codes, and headers work identically. The performance improvements are invisible to web applications, a site that works over HTTP/1.1 and HTTP/2 works over HTTP/3 without code changes. The difference is entirely in the protocol transport layer beneath the application.
The TCP limitation HTTP/3 addresses
Understanding why HTTP/2 over TCP still had a performance ceiling, despite its multiplexing capabilities, clarifies the architectural motivation for replacing TCP with QUIC in HTTP/3.
TCP fundamentals: TCP, Transmission Control Protocol, is a reliable, ordered, byte-stream transport protocol. TCP guarantees that all data sent is received in the correct order, lost packets are retransmitted and delivery is acknowledged. This reliability guarantee is what makes TCP suitable for web communication, HTTP data must arrive completely and correctly.
TCP achieves reliability through sequence numbers and acknowledgements. The sender assigns sequence numbers to bytes. The receiver acknowledges received bytes. When the sender detects that a packet was lost, through missing acknowledgements or explicit negative acknowledgements, it retransmits the lost data.
TCP head-of-line blocking: TCP’s ordered delivery guarantee creates a fundamental problem for multiplexed HTTP/2 connections. TCP sees the connection as a single ordered byte stream, it has no concept of the multiple independent HTTP/2 streams being multiplexed within it. When a TCP packet is lost TCP stalls delivery of all subsequent data until the lost packet is retransmitted and received, because TCP guarantees in-order delivery of the byte stream and cannot deliver later data until the gap caused by the lost packet is filled.
From HTTP/2’s perspective this is TCP head-of-line blocking, a lost TCP packet stalls all HTTP/2 streams on the connection even though the streams are independent and later streams may have no dependency on the lost packet’s data. HTTP/2’s multiplexing eliminates HTTP-level head-of-line blocking, one slow stream does not block others within the HTTP layer. But TCP-level head-of-line blocking affects all streams simultaneously whenever any packet is lost.
On reliable connections with low packet loss rates TCP head-of-line blocking is rarely triggered and HTTP/2’s performance is excellent. On mobile networks, congested networks, or high-latency connections where packet loss rates are higher TCP head-of-line blocking can significantly degrade HTTP/2’s performance, particularly compared to the theoretical performance of independent stream multiplexing.
The measurement: research by Google, who developed the QUIC protocol that became the basis for HTTP/3, showed that on connections with 1% packet loss HTTP/2’s performance advantage over HTTP/1.1 was significantly reduced or eliminated by TCP head-of-line blocking. For the significant portion of web traffic on mobile or degraded network connections this was a meaningful limitation.
QUIC, the transport protocol beneath HTTP/3
QUIC is the transport protocol that HTTP/3 is built on, the replacement for TCP in the HTTP/3 architecture. Originally developed by Google as an experimental protocol, deployed in Chrome and Google servers beginning around 2012, QUIC was standardised by the IETF as RFC 9000 in May 2021 alongside the HTTP/3 specification.
QUIC runs on UDP: unlike TCP which is a connection-oriented transport protocol implemented in operating system kernels QUIC is implemented in user space and runs over UDP, User Datagram Protocol. UDP is a simple connectionless protocol that sends datagrams without delivery guarantees, no ordering, no reliability, no congestion control. QUIC implements its own reliability, ordering, congestion control, and flow control on top of UDP rather than inheriting them from TCP.
Running on UDP provides several advantages. QUIC can be updated and deployed independently of the operating system kernel, kernel updates are slow and require system reboots. New QUIC versions and features can be deployed by updating application software. UDP’s lack of connection state in network infrastructure means QUIC connections can survive IP address changes, relevant for mobile users who switch between Wi-Fi and cellular networks.
Stream-level reliability: the most important QUIC innovation for HTTP/3. QUIC implements multiplexed streams at the transport layer with per-stream reliability guarantees. Each QUIC stream is independently reliable, a lost packet affecting stream 3’s data does not block delivery of stream 5’s data. QUIC can deliver stream 5’s data even while retransmitting the lost packet for stream 3.
This per-stream reliability eliminates TCP head-of-line blocking at the transport layer. HTTP/3 streams mapped to QUIC streams are truly independent, a packet loss on one stream has no effect on other streams. The full benefit of HTTP multiplexing is achieved without the TCP head-of-line blocking limitation.
Integrated TLS 1.3: QUIC integrates TLS 1.3 directly into the transport layer, encryption is not a separate layer added on top of the transport as in TLS over TCP. TLS 1.3’s cryptographic handshake is performed simultaneously with QUIC’s connection establishment, the two processes are combined rather than sequential.
This integration reduces connection establishment latency. Standard TLS 1.3 over TCP requires one TCP handshake round trip plus one TLS 1.3 handshake round trip before the first HTTP request can be sent, two round trips total. QUIC with integrated TLS 1.3 completes both in one round trip, the QUIC connection initial packet combines transport and cryptographic handshake.
For 0-RTT connection resumption QUIC enables the client to send application data, HTTP requests, in the first packet of a resumed connection, truly zero additional round trips for reconnections. This is the fastest possible connection establishment for returning visitors.
Connection migration: QUIC connections are identified by a connection ID rather than by the client’s IP address and port as TCP connections are. When a mobile user switches from Wi-Fi to cellular their IP address changes, a TCP connection identified by the old IP address is broken and must be re-established. A QUIC connection identified by a connection ID survives the IP address change, the connection migrates to the new network path transparently. The user experiences no interruption to in-progress downloads or active connections when switching networks.
HTTP/3 features and performance
HTTP/3 inherits all of HTTP/2’s features, multiplexing, header compression, and stream prioritisation, while adding QUIC’s transport improvements.
QPACK, header compression for HTTP/3: HTTP/2 uses HPACK for header compression. HTTP/3 uses QPACK, an adaptation of HPACK designed for QUIC’s out-of-order delivery characteristics. HPACK uses a dynamic table that must be processed in order, out-of-order delivery on QUIC streams would cause HPACK synchronisation issues. QPACK separates the header compression table updates into a dedicated QUIC stream, allowing other streams to use the compressed headers without blocking on table updates. QPACK achieves similar compression ratios to HPACK while being compatible with QUIC’s stream independence.
Faster connection establishment: the combination of QUIC’s transport handshake and integrated TLS 1.3 reduces new connection establishment from two round trips, TCP plus TLS, to one round trip. For first-time connections the round trip reduction is one trip, meaningful particularly on high-latency connections. For resumed connections 0-RTT resumption allows the first request to be sent with the connection establishment packet, zero additional round trips.
Performance on degraded networks: HTTP/3’s most significant advantage over HTTP/2 is on networks with packet loss. The elimination of TCP head-of-line blocking means a 2% packet loss rate has a proportionally smaller impact on HTTP/3 performance than on HTTP/2 performance. The improvement is most pronounced for pages loading many resources, the more independent streams, the more damage TCP head-of-line blocking causes and the more benefit QUIC’s per-stream reliability provides.
Performance on low-latency reliable networks: on fast, reliable networks HTTP/3’s advantages over HTTP/2 are smaller. Packet loss is rare so TCP head-of-line blocking rarely triggers. The one round trip saved in connection establishment is a smaller proportion of total page load time when the connection is fast. HTTP/3 is generally as fast or faster than HTTP/2 on reliable connections but the margin is smaller than on degraded connections.
HTTP/3 and redirects
HTTP/3 changes the mechanics of how redirects perform, continuing the trend from HTTP/1.1 to HTTP/2 of reducing connection overhead and improving multiplexing efficiency.
Redirect responses over HTTP/3: HTTP redirects function identically over HTTP/3, the same 3xx status codes, Location headers, and browser redirect-following behaviour. The redirect response is transmitted as an HTTP/3 response, binary framed, header compressed with QPACK, delivered over a QUIC stream.
Faster connection establishment for cross-origin redirects: when a redirect sends the browser to a different domain a new connection must be established. Over HTTP/3 this new connection requires one round trip for the combined QUIC and TLS handshake, compared to two round trips for TCP plus TLS 1.3 or potentially more for older TLS versions. The reduced connection establishment latency makes cross-origin redirects faster under HTTP/3.
0-RTT for repeated redirect sources: for domains the browser has previously connected to QUIC’s 0-RTT resumption allows the redirect request to be sent immediately, without waiting for connection establishment. A redirect source domain that a visitor has accessed before can be reconnected to at 0-RTT, the redirect response is received faster than under HTTP/2 where the TLS session resumption still requires at least one round trip.
Redirect chains remain a performance concern: as with HTTP/2 reducing redirect hops is a performance best practice regardless of HTTP version. HTTP/3 improves the efficiency of each hop but multiple sequential hops still accumulate latency. Each additional redirect hop requires a request-response cycle, even with 0-RTT the round trip time multiplied by the number of hops adds meaningful latency on high-latency connections.
HTTP/3 deployment status
HTTP/3 deployment has accelerated rapidly since standardisation, major browsers, CDNs, and hosting platforms now support it.
Browser support: Chrome, Firefox, and Edge all support HTTP/3. Safari added HTTP/3 support in iOS 15 and macOS Monterey. HTTP/3 is now supported by all major browsers and enabled by default for connections to servers that advertise HTTP/3 support.
Server support: web server HTTP/3 support is less universal than HTTP/2 support but improving rapidly. Nginx supports HTTP/3 through the nginx-quic branch and as of version 1.25.0 in the mainline. Apache HTTP/3 support is under development. Caddy supports HTTP/3 natively. H2O supports HTTP/3. Many CDN edge servers have supported HTTP/3 for years.
CDN support: CDNs were early HTTP/3 adopters. Cloudflare has supported HTTP/3 since 2019, enabling it automatically for all domains on their network. Google Cloud CDN, Fastly, Akamai, and AWS CloudFront all support HTTP/3. For sites behind CDNs the client-to-edge connection benefits from HTTP/3 regardless of origin server support.
Advertising HTTP/3 support, Alt-Svc header: servers advertise HTTP/3 support through the Alt-Svc response header. When a browser receives an HTTP/2 or HTTP/1.1 response containing Alt-Svc: h3=":443"; ma=86400 it learns that the server supports HTTP/3 on port 443 and that this information is valid for 86400 seconds. On subsequent connections the browser attempts HTTP/3 first, falling back to HTTP/2 or HTTP/1.1 if the HTTP/3 connection fails.
This Alt-Svc mechanism means the first connection to an HTTP/3-capable server uses HTTP/2, subsequent connections use HTTP/3. The transition is transparent to users.
HTTP/3 and redirect management
HTTP/3 affects redirect management infrastructure in ways that build on and extend HTTP/2’s impact.
QUIC support in redirect infrastructure: redirect management platforms serving traffic over HTTP/3 must implement QUIC alongside TLS, a more significant infrastructure requirement than HTTP/2 which only required TLS and binary framing on top of existing TCP connections. QUIC requires UDP support, firewalls and network infrastructure that block UDP may prevent HTTP/3 connections. HTTP/3 deployments always maintain HTTP/2 and HTTP/1.1 fallback support for clients or network paths that cannot use QUIC.
CDN-based HTTP/3 for redirect management: redirect management platforms fronted by CDNs that support HTTP/3, Cloudflare being the most prominent, automatically benefit from HTTP/3 for client-to-CDN connections. The CDN terminates HTTP/3 connections at the edge and forwards requests to the redirect infrastructure over HTTP/2 or HTTP/1.1, providing HTTP/3’s performance benefits without requiring the redirect infrastructure to implement QUIC directly.
Connection migration for mobile redirect users: QUIC’s connection migration capability means mobile users who switch networks while following a redirect, rare but possible, maintain their connection without disruption. A redirect following in progress when a mobile device switches from Wi-Fi to cellular completes without the connection being dropped and re-established.
Checking HTTP/3 support
Verifying that HTTP/3 is working for a domain requires tools that check QUIC connectivity alongside standard HTTP checks.
Browser developer tools: the Network tab in Chrome or Firefox developer tools shows the protocol used for each request, h3 for HTTP/3 connections. Checking the protocol column after loading a page shows whether HTTP/3 was negotiated.
curl with HTTP/3 support: curl compiled with QUIC support can make HTTP/3 requests:
Tests HTTP/3 connectivity directly.
Online HTTP/3 test tools: http3check.net and similar online tools check whether a domain supports HTTP/3 from external perspectives, making QUIC connections and reporting the result.
Alt-Svc header inspection: checking the Alt-Svc header in HTTP/2 responses reveals whether the server advertises HTTP/3 support:
An alt-svc: h3=":443" header confirms the server advertises HTTP/3 availability.