Cloud Parts

QUIC

A secure, multiplexed transport over UDP: TLS 1.3 is built into its handshake, many streams share one connection without blocking each other, and a connection can survive a change of network.

What it is
Network protocols (transport protocols)
Type
Open source
Made by
IETF
License
Open standard (IETF RFC)
Facts checked
8 October 2026
Website

What it is

QUIC is connection-oriented like TCP, but it runs in UDP datagrams and does its own reliability, flow control and congestion control. Its handshake negotiates transport parameters and runs TLS 1.3 at the same time, so a new connection can carry application data after one round trip, and a client that has talked to the server before can send data in its very first packets (0-RTT). QUIC authenticates every packet and encrypts as much of each as practical, including most of the header fields that TCP leaves in the clear. To stop its handshake being used for traffic amplification, a server sends at most three times as many bytes to an unverified address as it has received from it.

Inside a connection, applications open bidirectional or unidirectional streams, each an ordered sequence of bytes. When a packet is lost, only the streams with data in that packet wait for the retransmission; the rest keep going, which removes the head-of-line blocking that HTTP/2 suffers over TCP. Connections are identified by connection IDs rather than by addresses and ports, so a client can move to a new network path, or survive a NAT rebinding, without starting over. QUIC version 1 is RFC 9000 (May 2021) with RFC 9001 (TLS) and RFC 9002 (loss detection and congestion control); HTTP/3 is its best-known user, and RFC 9369 (2023) defined a version 2 that differs only in small details, to keep version negotiation working.

Why teams pick it

  • Setup costs one round trip including encryption, and 0-RTT lets a returning client send its request immediately
  • Independent streams: one lost packet stalls only the streams it carried, not the whole connection
  • Always encrypted and authenticated, so devices on the path can’t read or alter most of what TCP exposes
  • Connection IDs let a phone keep its connection across a network change or NAT rebinding

Watch out for

  • Some networks block UDP: measurements cited by the IETF put it at 3% to 5%, so clients need a TCP fallback (HTTP/3 falls back to HTTP/2 or HTTP/1.1 over TLS)
  • Load balancers that route by address and port can send a migrated or rebound connection to the wrong server; they need to route by connection ID instead
  • Encrypted headers hide what operators used to see in TCP, such as sequence numbers, so passive troubleshooting tools see much less
  • 0-RTT data can be replayed by an attacker and has weaker forward secrecy, so it should carry only requests that are safe to repeat

Alternatives

What all transport protocols have in common →
TCPOpen sourceThe Transmission Control Protocol: a handshake opens a connection between two ports, then bytes arrive complete and in order, resent when lost and paced to what the path can carry.UDPOpen sourceThe User Datagram Protocol: ports and a checksum on top of IP, and nothing else. Each datagram is sent on its own, with no connection, no retransmission and no ordering.

How it fits with other technologies

Check that a site answers over HTTP/3 (needs a curl built with HTTP/3) · bash

# the server advertises HTTP/3 on UDP port 443 in an Alt-Svc header
curl -sI https://www.cloudflare.com/ | grep -i alt-svc
# alt-svc: h3=":443"; ma=86400

# force QUIC and print the HTTP version used
curl -sI --http3-only https://www.cloudflare.com/ -o /dev/null -w '%{http_version}\n'
# 3

See it in a real stack

No architecture uses QUIC yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2013–2023

By 2013 Google had already sped up the web with SPDY, which became the foundation of HTTP/2. But round-trip time, as Jim Roskind wrote, is “ultimately bounded by the speed of light”, and cutting round trips was hard with protocols built on TCP. In June 2013 the Chromium team described QUIC (Quick UDP Internet Connections): stream multiplexing over a new flavour of TLS on top of UDP, aiming for often 0-RTT connections, no TCP head-of-line blocking and a connection identifier so mobile clients reconnect less. Google tested it on a small share of Chrome traffic to its own servers.

The IETF then took QUIC on in a working group, which drew a clear line between the transport (QUIC) and the application mapping (HTTP/3), and replaced Google’s own QUIC Crypto with TLS 1.3. QUIC version 1 was published as RFC 9000, with RFC 9001 and RFC 9002, in May 2021, followed by HTTP/3 as RFC 9114 in June 2022 and QUIC version 2 in May 2023.

Why it’s built this way

Build on UDP, not a new IP protocol
Running over UDP lets QUIC be implemented in user space and pass through NATs and other middleboxes without updating network infrastructure. The cost is that networks blocking UDP block QUIC too.
Encryption inside the transport
Combining the TLS 1.3 handshake with transport setup saves a round trip, and protecting the transport headers means devices on the path can’t modify them. The IETF expects QUIC to evolve quickly, with new versions deployed more often than for older transports.
Streams in the transport
TCP delivers one ordered byte stream, so a single loss stalls every HTTP/2 request on the connection. QUIC tracks loss per stream, so the others keep moving.

Timeline

  1. 2013

    Google describes QUIC and starts experiments in Chrome

  2. 2021

    QUIC version 1 published as RFC 9000, with RFC 9001 and RFC 9002

  3. 2022

    HTTP/3 over QUIC published as RFC 9114

  4. 2023

    QUIC version 2 (RFC 9369) exercises version negotiation

Sources8 · facts checked 8 October 2026

Improve this page on GitHub