QUIC (originally an informal name for “Quick UDP Internet Connections”, now just used as the protocol’s official name) is a relatively modern transport protocol, designed by Google and later standardised by the IETF, that underpins HTTP/3 — the newest version of HTTP. Unlike almost every other protocol covered on this site, QUIC is built on UDP rather than TCP, which is the key to understanding why it exists at all.
Why QUIC exists
To understand QUIC, it helps to understand the specific problems it was built to solve in how HTTPS traffic (see the HTTP & HTTPS page) traditionally worked over TCP:
- TCP’s handshake is slow, and TLS adds another one on top. Before any HTTPS data can be sent, a client and server first need to complete a TCP handshake (see the TCP & UDP page) to establish a connection, and then a separate TLS handshake on top of that to negotiate encryption. Each of these handshakes requires a round trip between client and server, adding real, noticeable delay before a single byte of the actual webpage has been transferred — this matters a lot on high-latency connections, like mobile networks.
- TCP’s reliability guarantee creates a problem called head-of-line blocking. TCP guarantees that data arrives in the correct order, which it achieves by holding back any data that arrives out of sequence until the missing piece catches up. A modern webpage loads many resources (images, scripts, stylesheets) over the same connection at once, and if a single lost packet belongs to just one of those resources, TCP will still delay delivery of every other resource’s data too, even though it arrived perfectly fine — all of them get stuck waiting behind the one lost packet.
- Switching networks breaks the connection. A TCP connection is identified by a combination including both devices’ IP addresses. If a phone switches from Wi-Fi to mobile data mid-download, its IP address changes, and the existing TCP connection breaks entirely, forcing a fresh handshake (and often a restarted download) on the new network.
QUIC was designed specifically to address all three of these.
How QUIC solves these problems
Combined handshake
QUIC integrates the transport and encryption handshakes into a single combined process, rather than TCP’s handshake followed by a separate TLS handshake on top. In many cases, this reduces connection setup to a single round trip, and QUIC also supports “0-RTT” resumption for servers a client has connected to recently, allowing it to start sending encrypted application data immediately, without waiting for any handshake round trip at all.
Encryption is not optional in QUIC — unlike plain HTTP, which can run without TLS, QUIC has no unencrypted mode. Every QUIC connection is encrypted by design.
Independent streams
Rather than treating a connection as a single ordered sequence of data (as TCP does), QUIC multiplexes multiple independent streams within one connection. If a packet belonging to one stream is lost, only that specific stream is delayed while it’s resent — the other streams continue delivering their data without waiting, solving the head-of-line blocking problem described above.
Connection IDs
Instead of identifying a connection by the two devices’ IP addresses and ports (as TCP does), QUIC assigns each connection its own Connection ID, independent of the network path being used. This allows a QUIC connection to survive a network change — like a phone moving from Wi-Fi to mobile data — without needing to restart, since the server continues to recognise the same Connection ID even though the client’s IP address has changed underneath it. This capability is sometimes referred to as connection migration.
QUIC and UDP
Since QUIC needed to build all of this custom behaviour (reliability, ordering, congestion control) itself rather than relying on TCP’s, it made more sense to build it on top of UDP — a deliberately minimal, connectionless transport protocol that doesn’t get in the way — rather than trying to bolt these new capabilities onto TCP itself. QUIC essentially reimplements the useful parts of TCP’s reliability from scratch, but in a way specifically designed to avoid TCP’s head-of-line blocking and slow connection setup.
This does mean QUIC traffic can occasionally be treated unusually by older or overly strict firewalls, some of which have historically been configured with less nuanced rules for UDP traffic than for the extremely well-understood TCP. Most modern firewalls handle QUIC correctly today, but it remains a common early troubleshooting step when diagnosing unexpected connectivity issues with a QUIC-enabled service.
HTTP/3
HTTP/3 is simply the version of HTTP designed to run over QUIC, rather than over TCP as every previous version of HTTP did. Critically, HTTP/3 doesn’t change the actual semantics of HTTP itself — the same methods, status codes, and headers covered on the HTTP & HTTPS page still apply. What changes is purely the transport underneath, bringing the faster connection setup and elimination of head-of-line blocking described above to ordinary web browsing.
A server can advertise that it supports HTTP/3 to a browser that initially connects over HTTP/2 or HTTP/1.1, via a response header called Alt-Svc. The browser can then use HTTP/3 for subsequent requests to that same server.
Checking if a site uses QUIC/HTTP/3
Most modern browsers show this directly in their developer tools — in Chrome or Edge, opening Developer Tools, going to the Network tab, and adding the “Protocol” column will show h3 for any resource loaded over HTTP/3.
QUIC and security
Because encryption is mandatory and built into every QUIC connection from the outset, QUIC removes an entire category of misconfiguration that’s possible with traditional HTTP/TLS — there’s no equivalent of accidentally leaving a service reachable over plain, unencrypted HTTP, since QUIC has no unencrypted mode at all.
However, QUIC introduces its own set of newer considerations:
Connection migration can complicate network monitoring. Since a QUIC connection can legitimately continue across a change in IP address via its Connection ID, security tools that rely on tracking a “connection” purely by matching IP address and port pairs (a very traditional approach) may need updating to correctly follow QUIC traffic, or risk losing visibility partway through a session.
QUIC’s use of UDP can be attractive for DDoS amplification. Like other UDP-based protocols, QUIC can potentially be abused in reflection/amplification-style Denial of Service attacks, where an attacker sends small spoofed requests designed to trigger a much larger response directed at a victim. QUIC’s designers built in specific mitigations against this (such as requiring a server to see a sufficiently large “hello” from a genuine client before responding with much data), but it remains an active area of ongoing research and refinement, since attackers regularly probe new protocols for exactly this kind of weakness. This connects to the general amplification concept covered on the Denial of Service (DoS) page.
0-RTT resumption carries a subtle replay risk. Because 0-RTT allows a client to send encrypted application data immediately, without waiting for a fresh handshake round trip, there’s a theoretical window where an attacker who has captured an initial 0-RTT request could replay it back to the server. Server implementations need to specifically account for this risk (for example, by treating 0-RTT requests as non-idempotent-unsafe unless proven otherwise), and it’s a good example of how a performance optimisation can introduce a security trade-off that needs deliberate, careful handling.