The web is undergoing its biggest protocol upgrade since HTTP/2. HTTP/3 abandons TCP entirely, running instead over QUIC — a UDP-based transport protocol developed by Google and standardized by the IETF. This article explains why this matters and how it works.

Why Replace TCP?

TCP has served us well for 40 years, but it has fundamental limitations that cannot be fixed without breaking backward compatibility:

  • Head-of-Line Blocking: In HTTP/2 over TCP, a single lost packet blocks ALL streams on that connection until retransmission completes. QUIC fixes this by implementing streams at the transport layer — a lost packet only blocks its own stream.
  • Slow Connection Setup: TCP requires a 3-way handshake (1 RTT), then TLS requires another 1-2 RTTs. QUIC combines transport and crypto handshakes into a single round trip.
  • Ossification: Middleboxes (firewalls, NATs) inspect and sometimes modify TCP headers. This makes deploying TCP improvements nearly impossible. QUIC encrypts everything except the first byte, preventing middlebox interference.

0-RTT Connection Resumption

When reconnecting to a server you have visited before, QUIC can send application data in the very first packet — zero round trips of latency. This is achieved using a cryptographic token from the previous session.

Security Trade-off: 0-RTT data can be replayed by an attacker. Servers must ensure 0-RTT requests are idempotent (safe to repeat). For example, a GET request is safe, but a POST that transfers money is not.

Connection Migration

TCP connections are identified by a 4-tuple: source IP, source port, destination IP, destination port. If any of these change (e.g., switching from Wi-Fi to cellular), the connection dies.

QUIC connections are identified by a Connection ID chosen by the endpoints. When your phone switches networks, the Connection ID remains the same, and the session continues seamlessly. This is crucial for mobile users.

How QUIC Achieves Reliability Over UDP

UDP itself is unreliable — packets can be lost, duplicated, or arrive out of order. QUIC implements its own reliability mechanisms:

  • Packet Numbers: Every QUIC packet has a unique, monotonically increasing packet number. Unlike TCP sequence numbers, packet numbers are never reused, making loss detection unambiguous.
  • ACK Frames: Receivers send acknowledgments listing which packet numbers they have received. QUIC ACKs are more detailed than TCP ACKs, allowing faster loss detection.
  • Streams: Application data is sent on numbered streams. Each stream has its own flow control and is delivered in order, but streams are independent of each other.

Checking Your Connection

Want to know if you are using HTTP/3 right now? Use our homepage to check your connection protocol. Major sites like Google, YouTube, Facebook, and Cloudflare already serve traffic over HTTP/3.