QUIC

For the technical specification, see RFC 9000.

QUIC (originally "Quick UDP Internet Connections") is a secure transport protocol standardised by the IETF that runs over UDP and integrates transport and cryptographic handshakes into a single layer. QUIC underpins HTTP/3 and DNS over QUIC (DoQ) and is a central example of how encrypted transports change network operations, traffic management, and DNS-based policy tools.

Origins and Standardization

QUIC began as a proprietary Google transport in the early 2010s, designed to reduce latency compared with TCP+TLS by combining the cryptographic and transport handshakes, eliminating connection-level head-of-line blocking, and enabling connection migration in user space over UDP. The IETF chartered the QUIC Working Group in 2016 to create a standards-track version with encrypted transport headers, a stable wire image, and a robust versioning model.

The resulting specification set consists of RFC 9000 (transport), RFC 9001 (TLS 1.3 integration), and RFC 9002 (loss detection and congestion control), plus RFC 9114 defining HTTP/3 as HTTP over QUIC and RFC 9250 defining DNS over QUIC. These documents together define "IETF QUIC", distinct from earlier Google deployments, and anchor QUIC in the IETF’s change-control and IANA registry processes.

Deployment and Roles

By the mid-2020s, QUIC and HTTP/3 had been deployed at scale by major content and platform providers, including Google, Meta, and large content-delivery networks such as Cloudflare. Measurements show growing fractions of Web traffic using HTTP/3, with QUIC traffic concentrated on a relatively small number of large providers and CDNs. Major browsers (Chrome, Microsoft Edge, Firefox, Safari) implement QUIC and enable HTTP/3 by default when supported by servers.

Operational studies report that HTTP/3 over QUIC can reduce connection setup and page-load latency compared to HTTP/2 over TCP+TLS, especially on lossy or mobile networks, and improves robustness when clients move between access networks via QUIC’s connection migration features.

Beyond web traffic, QUIC is being adopted as a substrate for other protocols. DNS over QUIC uses QUIC streams to carry encrypted DNS queries and responses, aiming to provide privacy properties similar to DNS over TLS with reduced head-of-line blocking. Recursive resolvers such as Unbound implement DoQ both as a client and as a server, and European operators and research groups discuss DoQ in the context of modernising DNS privacy and resilience.

Governance Aspects

QUIC is specified and versioned in the IETF, not by ICANN or the RIR system, and it operates entirely above the IP and DNS layers. Its governance relevance comes from how it redistributes control between endpoints, networks, and application platforms.

Encrypted Transport and Operational Visibility

QUIC encrypts not only application data but also almost all transport-layer control information, exposing only a minimal and version-independent "wire image" to the network. On-path devices cannot safely modify transport fields, and common operational practices based on inspecting TCP sequence numbers, flags, or application headers become less effective or infeasible. Operator analyses emphasise that QUIC pushes more responsibility for performance, congestion control, and security decisions to endpoints and cooperating proxies, limiting the role of traditional middleboxes.

This increased opacity complicates regulatory and enterprise arrangements that rely on in-network inspection or modification of transport and application headers, including some content-filtering regimes, specialised lawful-intercept designs, and fine-grained traffic classification.

Endpoint and Platform Control

Historically, general-purpose transport on the public Internet was dominated by TCP, implemented in operating-system kernels and evolving slowly. QUIC, running in user space over UDP, allows application platforms to innovate in congestion control, connection management, and encrypted transport features with less dependence on OS-level TCP stacks.

SSAC’s analysis of evolving name resolution notes that applications increasingly embed their own resolution and transport logic, using mechanisms such as DoH and DoQ without relying on network-provided resolvers. QUIC strengthens this trend at the transport layer: browsers and large CDNs that control both endpoints effectively become transport providers, deciding which QUIC versions and parameters are used for HTTP/3 and related protocols. From an Internet governance perspective, this contributes to wider debates about centralisation, platform power, and the distribution of responsibilities for security, abuse management, and lawful access between end systems, networks, and standards bodies.

See Also

• HTTP/3
• DNS over QUIC

Provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism. The protocol is transaction oriented, and delivery and duplicate protection are not guaranteed. Applications requiring ordered reliable delivery of streams of data should use the Transmission Control Protocol (TCP) (RFC 768).

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).

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).

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

Internet Assigned Numbers Authority

Regional Internet Registry

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