QUIC is the transport protocol underneath HTTP/3. Built on UDP, it solves three TCP problems at once: head-of-line blocking across streams, 1-RTT connection setup with 0-RTT resumption, and connection migration across IP changes. For mobile users on flaky networks, this is night and day.
Streams inside one connection
Like HTTP/2, QUIC multiplexes many streams over one connection. Unlike HTTP/2, packet loss on stream A does NOT block stream B — because QUIC controls retransmission per-stream rather than at the transport layer. A single dropped packet only delays that one stream's data.
Connection migration
Your phone switches from Wi-Fi to LTE — IP address changes. With TCP, the connection dies and you reconnect. With QUIC, the connection ID is independent of IP/port; the connection migrates seamlessly. For long-lived bidi streams on mobile, this eliminates the most common stall.
0-RTT resumption
First connection: client and server do a handshake (1-RTT). For subsequent connections to the same server, the client can send application data in the very first packet using cached cryptographic parameters. This is unsafe for non-idempotent requests (replay risk), so use 0-RTT only for GETs.
Operational gotchas
Some middleboxes still drop UDP — fallback to TCP must be available. QUIC's per-packet encryption is more CPU-intensive than TCP+TLS (~10-15% server overhead). The Linux kernel UDP stack was slower than TCP until kernel 5.x — measure on your kernel.
When to adopt
Use it when: your users are on mobile/lossy networks, you control both client and server (or your CDN supports it), and tail latency matters. Cloudflare and Google measure ~5-15% page-load improvement at the p99.