View source for RFC 9000

{{Note|For implications on Internet governance, see [[QUIC]] and [[HTTP/3]].}}

'''RFC 9000''', ''QUIC: A UDP-Based Multiplexed and Secure Transport'', is an IETF standards-track RFC that defines the core QUIC transport protocol. QUIC provides applications with flow-controlled streams over UDP, enabling secure, multiplexed, low-latency connections with support for connection migration and integrated congestion control. It was published in May 2021 as the main output of the IETF QUIC Working Group.<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><ref name="rfcinfo9000">[https://www.rfc-editor.org/info/rfc9000 RFC Editor, "Information on RFC 9000" (accessed 2025-12-08).]</ref> Subsequent RFCs extend QUIC with new versions, manageability guidelines and additional features, but RFC 9000 remains the reference document for the core transport semantics and wire format of IETF QUIC.<ref name="rfc-overview" /><ref name="iana-quic" />

== Background ==
QUIC originated as a [[Google]] transport protocol (gQUIC) deployed experimentally from 2012, aiming to reduce web latency and to move congestion control and transport evolution into user space over UDP.<ref name="quic-wiki">[https://en.wikipedia.org/wiki/QUIC "QUIC", Wikipedia (accessed 2025-12-08).]</ref> Early deployments carried HTTP traffic between [[Chrome]] and Google services and demonstrated performance gains over TCP+TLS+[[HTTP/2]] by avoiding head-of-line blocking at the connection level and shortening connection setup.<ref name="quic-michelin">[https://blogit.michelin.io/quic-analysis-a-udp-based-multiplexed-and-secure-transport/ S. Carrel-Billiard, "QUIC Analysis – A UDP-Based Multiplexed and Secure Transport", Michelin, 30 June 2022.]</ref>

In 2016 the IETF chartered the QUIC Working Group to standardise a version of QUIC distinct from gQUIC, with encrypted transport headers, a stable wire image and a versioning scheme resilient to middlebox ossification.<ref name="quic-wiki" /><ref name="demystify-quic">[https://arxiv.org/html/2511.08375v1 "Demystifying QUIC from the Specifications", arXiv preprint 2511.08375, 11 November 2025.]</ref> RFC 9000 and its companion documents (RFC 8999, 9001, 9002) were published in May 2021 and define "IETF QUIC", which underpins [[HTTP/3]] and other newer application protocols.<ref name="rfc9000" /><ref name="rfc8999">[https://datatracker.ietf.org/doc/html/rfc8999 M. Thomson, "Version-Independent Properties of QUIC", RFC 8999, IETF, May 2021.]</ref><ref name="rfc-overview">[https://www.net.in.tum.de/fileadmin/TUM/NET/NET-2024-04-1/NET-2024-04-1_02.pdf Y.-X. Chen et al., "RFC 9000 and its Siblings: An Overview of QUIC Standards", Technische Universität München, 2024.]</ref>

== Protocol Overview ==
RFC 9000 specifies a connection-oriented transport protocol running over UDP. Endpoints maintain QUIC connections identified by versioned wire formats and opaque connection IDs, decoupling logical connections from the underlying IP address and UDP port, enabling migration across network paths (for example, when a mobile device changes access networks).<ref name="rfc9000" /><ref name="rfc8999" /><ref name="iana-quic">[https://www.iana.org/assignments/quic/quic.xhtml IANA, "QUIC Parameters" (accessed 2025-12-08).]</ref>

Within a connection, QUIC provides lightweight, flow-controlled streams that carry ordered byte streams in each direction. Streams are multiplexed into QUIC packets using typed frames, and loss or blocking on one stream does not stall others, removing the connection-level head-of-line blocking that affects HTTP/2 over TCP.<ref name="rfc9000" /><ref name="http3">[https://www.rfc-editor.org/rfc/rfc9114.html J. Bishop, "HTTP/3", RFC 9114, IETF, June 2022.]</ref><ref name="quic-wiki" /> The specification defines separate flow-control windows for streams and for the connection as a whole, allowing endpoints to limit resource usage and to prioritise streams.

Connection establishment and security are tightly integrated with cryptography. RFC 9000 mandates that QUIC be secured by a cryptographic handshake and references RFC 9001, which defines the mandatory mapping of QUIC to TLS 1.3.<ref name="rfc9000" /><ref name="rfc9001">[https://datatracker.ietf.org/doc/html/rfc9001 M. Thomson, S. Turner, "Using TLS to Secure QUIC", RFC 9001, IETF, May 2021.]</ref> The TLS 1.3 handshake provides 1-RTT connection setup for new peers and 0-RTT resumption in many cases, while deriving the traffic keys used to encrypt almost all QUIC headers and payloads.<ref name="rfc9001" /> Only a small, version-invariant portion of the header remains visible on the wire, as captured by RFC 8999.<ref name="rfc8999" />

Loss detection and congestion control are part of the QUIC transport design, but the detailed algorithms are delegated to RFC 9002.<ref name="rfc9002">[https://datatracker.ietf.org/doc/html/rfc9002 IETF, "QUIC Loss Detection and Congestion Control", RFC 9002, IETF, May 2021.]</ref> RFC 9002 specifies acknowledgement handling, packet number spaces and congestion-control behaviour inspired by TCP NewReno and CUBIC, adapted for QUIC’s encrypted headers and multiple packet number spaces.<ref name="rfc9002" /><ref name="rfc-overview" />

== Security and Privacy Properties ==
From the outset, QUIC is specified as an always-encrypted transport. Application data and most control information are protected using Authenticated Encryption with Associated Data algorithms and keys established by TLS 1.3, providing confidentiality, integrity and peer authentication properties that are comparable to or stronger than TCP+TLS.<ref name="rfc9000" /><ref name="rfc9001" /> Header protection conceals fields such as packet numbers from passive observers, reducing the amount of transport metadata exposed to on-path devices and limiting opportunities for protocol ossification and interference by middleboxes.<ref name="rfc8999" /><ref name="demystify-quic" />

The protocol includes anti-amplification limits and address validation mechanisms designed to mitigate reflection and amplification attacks, particularly during connection establishment. Servers can require clients to prove reachability of their source address (e.g. using Retry packets) before sending significantly more data than they have received.<ref name="rfc9000" /> Together with connection IDs and path validation procedures, these mechanisms help QUIC operate robustly in the presence of NATs, address translation and mobility, while constraining abuse of spoofed addresses.

== Deployment and Applications ==
RFC 9000 is the transport foundation for [[HTTP/3]], standardised in [[RFC 9114]] as a mapping of HTTP semantics onto QUIC streams.<ref name="http3" /> HTTP/3 reuses QUIC’s stream multiplexing, flow control, and low-latency connection establishment to improve Web performance compared with [[HTTP/2]] over TCP.<ref name="http3" /><ref name="quic-wiki" /> Measurements by operators such as [[Cloudflare]] and independent studies show increasing shares of HTTP traffic using HTTP/3/QUIC as browsers and servers enable it by default.<ref name="cloudflare-http3">[https://blog.cloudflare.com/cloudflare-view-http3-usage/ Cloudflare, "A Cloudflare view of HTTP usage trends", 6 June 2022.]</ref><ref name="http3-adoption">[https://w3techs.com/technologies/details/ce-http3 "Usage of HTTP/3 for websites", W3Techs (accessed 2025-12-08).]</ref>

Beyond HTTP, QUIC is used as a general-purpose transport for other protocols. [[RFC 9250]] specifies [[DNS over QUIC]] (DoQ), using QUIC to encrypt DNS queries and responses with latency characteristics similar to classic DNS over UDP but with transport-level confidentiality.<ref name="doq9250">[https://datatracker.ietf.org/doc/rfc9250/ C. Huitema et al., "DNS over Dedicated QUIC Connections", RFC 9250, IETF, May 2022.]</ref> Operator and vendor reports describe growing, though still limited, deployment of DoQ in recursive resolvers and authoritative servers.<ref name="doq-operators">[https://blog.nlnetlabs.nl/dns-over-quic-in-unbound/ NLnet Labs, "DNS-over-QUIC in Unbound", 17 October 2024.]</ref><ref name="doq-sidn">[https://www.sidn.nl/en/news-and-blogs/new-dns-over-quic-protocol-makes-encrypted-dns-traffic-faster-and-more-efficient SIDN, "New DNS over QUIC protocol makes encrypted DNS traffic faster and more efficient", 25 August 2022.]</ref>

Major browsers (Chrome, [[Edge]], Firefox, [[Safari]]) and large content providers (including Google, [[Meta]] and others) support QUIC, and operating-system and application stacks expose APIs or libraries that implement RFC 9000 and its extensions.<ref name="quic-wiki" /><ref name="quic-ptwiki">[https://pt.wikipedia.org/wiki/QUIC "QUIC", Wikipédia em português (accessed 2025-12-08).]</ref><ref name="dotnet-quic">[https://learn.microsoft.com/pt-br/dotnet/fundamentals/networking/quic/quic-overview Microsoft, ".NET QUIC overview" (accessed 2025-12-08).]</ref>

== References ==
{{reflist}}

[[Category:Standards]]
[[Category:RFC]]