QUIC Protocol & Transport

QUIC over UDP, 0-RTT handshake, multiplexed streams without HOL blocking, connection migration, and HTTP/3.

Overview

Overview QUIC (originally Google Quick UDP Internet Connections, now standardized as RFC 9000) is a multiplexed transport protocol built over UDP. It is the transport layer for HTTP/3 (RFC 9114).

Why QUIC? TCP + TLS has two fundamental problems at scale: 1. Head-of-line blocking: TCP delivers bytes in order. One lost packet stalls all data behind it, even data from unrelated requests. 2. Slow connection setup: TCP handshake (1 RTT) + TLS 1.3 handshake (1 RTT) = 2 RTTs before the first byte of application data.

QUIC solves both: - Multiplexed streams: QUIC runs multiple independent byte streams over one connection. A lost packet only blocks the stream it belongs to, not other streams. - 0-RTT / 1-RTT handshake: QUIC merges the transport and TLS handshakes into a single 1-RTT exchange. With session resumption, 0-RTT allows data in the first packet (with replay caveats). - Connection migration: QUIC connections are identified by a Connection ID, not the (IP, port) tuple. A mobile client can switch from Wi-Fi to LTE and maintain the same QUIC connection.

QUIC packet structure: encrypted at the QUIC layer (not just TLS). Even QUIC headers are partially encrypted to prevent middlebox ossification. Only the Connection ID and packet number are visible.

Deployment: Cloudflare, Google, Facebook, and Akamai carry significant QUIC traffic. In Kubernetes, HTTP/3 Ingress support is available in nginx-ingress (experimental) and Envoy (stable). gRPC over HTTP/3 is in progress.

Key concepts

Head-of-line blocking
TCP delivers bytes strictly in order. A single lost packet blocks all subsequent data on that connection, even from unrelated requests. QUIC eliminates this with independent streams.
0-RTT handshake
QUIC session resumption allows the client to send application data in the very first packet using a cached session ticket. Caution: 0-RTT data is replay-vulnerable (not idempotent-safe).
Connection ID
A QUIC connection identifier that is independent of the client IP and port. Enables connection migration: the client can change networks and keep the same QUIC connection.
Stream multiplexing
QUIC runs multiple independent byte streams over one UDP connection. A lost packet blocks only its own stream, not others — eliminating the TCP head-of-line blocking problem.
Connection migration
When the client IP or port changes (e.g., Wi-Fi to LTE), QUIC sends a PATH_CHALLENGE to the new path and continues the same logical connection using the Connection ID.

When to use it

  • Explaining why HTTP/3 uses UDP instead of TCP
  • Justifying QUIC for mobile applications with frequent network changes
  • Debugging connection migration or 0-RTT replay issues
  • Comparing QUIC with WebSockets or gRPC for real-time systems

Interview questions

  • How does QUIC eliminate head-of-line blocking that TCP suffers from?
  • What is QUIC connection migration and why does it matter for mobile users?

Sign up free to read the full topic

More Networking topics

Start free on Cariara · Coding problems · System design studio