View source for QUIC

{{Note|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.<ref name="rfc9000">[https://datatracker.ietf.org/doc/html/rfc9000 J. Iyengar, M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, IETF, May 2021.]</ref> 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.<ref name="cloudflare-http3">[https://www.cloudflare.com/learning/performance/what-is-http3/ Cloudflare Learning Center, "What is HTTP/3?" (accessed 2025-12-09).]</ref><ref name="rfc9250">[https://www.rfc-editor.org/rfc/rfc9250.html C. Huitema et al., "DNS over Dedicated QUIC Connections", RFC 9250, IETF, March 2022.]</ref>

== 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.<ref name="quic-wiki">[https://en.wikipedia.org/wiki/QUIC "QUIC", Wikipedia (accessed 2025-12-09).]</ref> 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.<ref name="quic-adoption">[https://www.diva-portal.org/smash/get/diva2%3A1994517/FULLTEXT01.pdf M. Al Homsi, "Investigating the Adoption of QUIC and Its Impact on Network Performance and Security", MSc thesis, 2025.]</ref>

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.<ref name="rfc9000" /><ref name="rfc9250" /> 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.<ref name="http3-measure">[https://arxiv.org/pdf/2102.12358 M. Trevisan et al., "Measuring HTTP/3: Adoption and Performance", 2021.]</ref><ref name="cloudflare-radar2024">[https://blog.cloudflare.com/radar-2024-year-in-review/ Cloudflare, "Internet traffic trends in 2024", 9 December 2024.]</ref> Major browsers ([[Chrome]], [[Microsoft Edge]], [[Firefox]], [[Safari]]) implement QUIC and enable HTTP/3 by default when supported by servers.<ref name="quic-wiki" />

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.<ref name="cloudflare-http3" /><ref name="apnic-quic">[https://labs.apnic.net/presentations/store/2023-09-07-quic-ausnog.pdf G. Huston, "A quick look at QUIC", AusNOG 2023.]</ref>

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.<ref name="rfc9250" /> 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.<ref name="unbound-doq">[https://unbound.docs.nlnetlabs.nl/en/latest/topics/privacy/dns-over-quic.html Unbound Documentation, "DNS over QUIC" (accessed 2025-12-09).]</ref><ref name="dns-over-quic-perf">[https://www.researchgate.net/publication/364718228_DNS_privacy_with_speed_evaluating_DNS_over_QUIC_and_its_impact_on_web_performance C. Friberg et al., "DNS privacy with speed: evaluating DNS over QUIC and its impact on web performance", 2022.]</ref>

== 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.<ref name="rfc9312">[https://datatracker.ietf.org/doc/rfc9312/ M. Kühlewind, B. Trammell, "Manageability of the QUIC Transport Protocol", RFC 9312, IETF, September 2022.]</ref> 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.<ref name="rfc9312" /> 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.<ref name="apnic-quic" />

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.<ref name="quic-adoption" /><ref name="http3-measure" />

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]]

== References ==
{{reflist}}

[[Category:Glossary]]
[[Category:Technical Standards]]