HTTP/3

HTTP/3 (RFC 9114) is the third major version of the Hypertext Transfer Protocol, standardised by the IETF as a mapping of HTTP semantics over QUIC rather than TCP. It retains the request/response model, methods, and status codes of earlier HTTP versions, but uses QUIC streams, QPACK header compression, and an integrated TLS 1.3 handshake to reduce latency and head-of-line blocking compared with HTTP/1.1 and HTTP/2. HTTP/3 itself does not change naming, addressing, or numbering policies. Its governance relevance arises from the way QUIC-based HTTP affects traffic observability, content control, and the distribution of power between access networks, CDNs, and application platforms.

Origins and Standardization

HTTP/3 grew out of work in the QUIC Working Group on "HTTP over QUIC", which adapted HTTP/2-style framing to run on top of the emerging QUIC transport. In 2018, it was proposed a renaming of the work from "HTTP over QUIC" to "HTTP/3" to emphasise that it is another binding of HTTP semantics to a wire protocol, distinct from QUIC itself.

The resulting protocol was standardised as RFC 9114 in June 2022 as a Proposed Standard. RFC 9114 defines how HTTP fields and frames are carried over QUIC bidirectional and unidirectional streams, how flow control and prioritisation are expressed, and which HTTP/2 features are handled by QUIC and QPACK instead of TCP and HPACK.

HTTP/3 remains part of the HTTP family: it is negotiated using the Application-Layer Protocol Negotiation (ALPN) mechanism in TLS, coexisting with HTTP/2 and HTTP/1.1 on the same hostnames and ports.

Protocol Characteristics

HTTP/3 preserves HTTP semantics while changing how they are encoded. Each HTTP request/response exchange is mapped to one QUIC bidirectional stream, allowing independent delivery and avoiding somee of the blocking between streams that occurs with HTTP/2 over a single TCP connection. Control information such as SETTINGS and QPACK encoder/decoder instructions is carried on unidirectional control streams.

Header fields are compressed using QPACK, a variant of HPACK adapted to QUIC’s independent streams to reduce blocking on header state updates. QUIC provides integrated TLS 1.3 encryption and 0-RTT mechanisms, so HTTP/3 benefits from reduced handshake latency and connection migration, while inheriting QUIC’s encrypted transport headers and versioning model.

Deployment and Adoption

HTTP/3 has been deployed by major content and platform providers, including Google, Meta, and large content-delivery networks such as Cloudflare. Early large-scale measurements found HTTP/3 support concentrated on leading Internet companies, with performance gains particularly visible on lossy or mobile networks.

By 2024, HTTP/3 was supported by all major browsers and by roughly one-third of the top 10 million websites, with continued growth in server-side support reported by measurement studies and operators. Web stacks typically offer HTTP/1.1, HTTP/2, and HTTP/3 simultaneously, with the client and server negotiating the highest mutually supported version over TLS.

Encrypted Web Transport and Network Visibility

Because HTTP/3 always runs over QUIC with TLS 1.3, virtually all application and transport-layer information is encrypted and integrity-protected. Only a minimal QUIC "wire image" (such as version indicators and connection IDs) remains visible to the network, and middleboxes are not expected to modify transport headers.

This design reduces the usefulness of techniques that relied on parsing HTTP headers or TCP behaviour in the network, including some forms of traffic classification, DDoS mitigation, and performance optimisation for high-delay paths such as satellite links. Operators can still observe endpoints, ports, and coarse flow statistics, but detailed visibility into HTTP transactions is increasingly available only at endpoints or in purpose-built proxies.

DNS, Blocking, and Circumvention

HTTP/3 itself does not change DNS, but it interacts with broader trends toward encrypted transport and encrypted DNS. ICANN’s SSAC has highlighted that encrypted transports such as DNS over HTTPS (DoH) and DNS over QUIC (DoQ) make DNS-based blocking harder to apply at on-path interception points and can push blocking towards endpoints, recursive resolvers, or non-DNS mechanisms.

As more Web traffic moves to HTTP/3 over QUIC, HTTPS-based blocking and IP-based blocking become relatively more important compared with techniques that relied on inspecting unencrypted HTTP headers. SAC127 notes that any blocking regime must account for collateral damage and the ease with which users can circumvent controls via VPNs, alternative DNS resolvers, or privacy-enhancing protocols, a situation reinforced by widespread deployment of HTTP/3 and related encrypted transports.

Platform and CDN Centralisation

Measurement work indicates that HTTP/3 usage is heavily driven by a relatively small number of large providers and CDNs, which control both HTTP/3-capable servers and the QUIC implementations used by major browsers or apps. Because QUIC and HTTP/3 are implemented in user space and can be updated independently of operating-system TCP stacks, browser vendors and large platforms can roll out new HTTP/3 and QUIC features quickly across their ecosystems.

From an Internet governance perspective, this contributes to debates about centralisation and platform power: performance, security properties, and some aspects of traffic manageability increasingly depend on a small set of HTTP/3 and QUIC implementations controlled by large content and platform operators, rather than on protocol behaviour mediated by diverse access networks.

See Also

• DNS over QUIC

Hypertext Transfer Protocol. Application-level protocol for distributed, collaborative, hypermedia information systems (RFC 2616).

Request For Comments. Archival series dedicated to documenting Internet technical specifications, including general contributions from the Internet research and engineering community as well as standards documents (RFC Editor Model, Version 3).

Internet Engineering Task Force

Allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery (RFC 8446).

Security and Stability Advisory Committee. Advises the ICANN community and Board on matters relating to the security and integrity of the Internet's naming and address allocation systems (ICANN Bylaws).

DNS over HTTPS

HTTP over Transport Layer Security (TLS), distinguishing secured traffic from insecure traffic by the use of a different server port (RFC 2818).