HTTP - 3 — QUIC, UDP-based, why: Question bank

A quick shared vocabulary so nothing below uses an undefined word:

Definition Words and symbols used everywhere below

QUIC = originally "Quick UDP Internet Connections" — the transport protocol HTTP/3 runs on. It sits inside UDP and rebuilds reliability, ordering, congestion control, and encryption itself.
RTT (round-trip time) = the time for one signal to travel from client to server and back. It is the natural "clock tick" for setup: every extra back-and-forth adds one RTT of pure waiting. On mobile, one RTT can be 50–100 ms.
0-RTT = "zero round-trips of setup" — sending real request data in the very first packet, with no waiting handshake beforehand. Only possible on a resumed connection using cached keys.
QPACK = HTTP/3's header-compression scheme. It does the same job as HTTP/2's HPACK (shrinking repeated headers) but is redesigned so it still works when streams arrive out of order.
4-tuple = the four values that identify a TCP connection: (source IP, source port, destination IP, destination port). Change any one — e.g. your IP when you move Wi-Fi→mobile — and TCP treats it as a different, dead connection.
$N$ = the number of independent objects (images, scripts, ...) a page is loading at once over a single connection. Rich pages have $N \approx 50$ .

Figure — HTTP - 3 — QUIC, UDP-based, why

True or false — justify

TRUE or FALSE: HTTP/3 uses different HTTP methods and status codes than HTTP/2.

FALSE — HTTP semantics (GET, POST, headers, 200 OK) are byte-for-byte the same; only the transport moved from TCP to QUIC. See HTTP-2 — multiplexing and HPACK.

TRUE or FALSE: Because HTTP/3 rides on UDP, a lost packet is simply never recovered.

FALSE — QUIC layers its own ACKs, sequence numbers, and retransmission on top of UDP, so lost data is recovered; UDP is only the delivery truck.

TRUE or FALSE: HTTP/2 already eliminated head-of-line blocking entirely.

FALSE — HTTP/2 killed application-layer HOL blocking, but one lost TCP segment still stalls every multiplexed stream at the transport layer; only QUIC removes that. See Head-of-line blocking.

TRUE or FALSE: QUIC encrypts only the request/response body, exactly like classic HTTPS.

FALSE — QUIC encrypts almost the entire packet, including most transport-level headers, specifically to stop middleboxes from meddling, and encryption is mandatory.

TRUE or FALSE: A fresh (first-time) QUIC connection reaches 0-RTT setup.

FALSE — a fresh connection costs 1 RTT; 0-RTT is only available when resuming a connection where the client already cached the server's crypto keys.

TRUE or FALSE: You can run QUIC without TLS if you want a lightweight, unencrypted version.

FALSE — there is no unencrypted QUIC; TLS 1.3 (the current encryption handshake, which negotiates keys and identity) is baked into the QUIC handshake and cannot be turned off.

TRUE or FALSE: Independent streams mean QUIC has no ordering at all.

FALSE — each stream is individually ordered (byte

k

still waits for byte

k - 1

within that stream); the win is that streams don't wait on each other.

TRUE or FALSE: Switching from Wi-Fi to mobile data always drops a TCP connection but not a QUIC one.

TRUE — TCP is identified by the 4-tuple including your IP, so an IP change kills it; QUIC uses a Connection ID independent of IP/port, letting the connection migrate. See TCP — three-way handshake and reliability.

TRUE or FALSE: QUIC abandons congestion control since it left TCP.

FALSE — QUIC reimplements congestion control (starting slow, then increasing gently and backing off sharply on loss) in user space; leaving TCP means rebuilding its good parts, not discarding them. See Congestion control — slow start, AIMD.

Spot the error

"HTTP/3 invented a brand-new IP-layer protocol number to replace TCP." — what's wrong?

A brand-new protocol number would be dropped by middleboxes that block anything unfamiliar; QUIC deliberately hides inside UDP, which is universally allowed (it carries DNS).

"QUIC lives in the OS kernel like TCP, so upgrading it needs an OS update." — what's wrong?

QUIC lives in user space (inside the browser/server binary), so it updates like any normal app — that's precisely why it can evolve where kernel-frozen TCP cannot.

"Because streams are independent, losing a packet on stream A also delays stream B a little." — what's wrong?

A loss on stream A delays only stream A; streams B, C, D keep flowing untouched — that independence is the whole point of QUIC over TCP.

"TLS 1.3 over TCP is just as fast as QUIC because both use TLS 1.3." — what's wrong?

TCP+TLS1.3 needs the TCP handshake (1 RTT) before TLS can even start, totalling 2 RTT; QUIC folds transport + crypto into one flight for 1 RTT (or 0 on resume).

"HTTP/3 uses HPACK header compression like HTTP/2." — what's wrong?

HTTP/3 uses QPACK, a redesign of HPACK adapted for out-of-order, independent streams; the compressed meaning is the same but the mechanism differs.

"QUIC is unreliable because UDP has no handshake." — what's wrong?

QUIC has its own cryptographic + transport handshake carried inside UDP datagrams; UDP's lack of a handshake is irrelevant once QUIC supplies one.

"Encrypting transport headers is just for privacy." — what's wrong?

Privacy is a bonus; the primary goal is preventing middleboxes from reading and "optimising" transport fields, which is how TCP got ossified and frozen.

Why questions

Why does one lost TCP segment stall unrelated HTTP/2 streams?

TCP delivers a single ordered byte stream and refuses to hand over later bytes until the missing earlier segment arrives, so all multiplexed streams sharing that stream wait together.

Why can QUIC deliver later streams while an earlier one waits for a retransmit?

QUIC tracks ordering per stream, so a gap in stream A's sequence numbers doesn't block stream B's already-complete bytes from being delivered.

Why did QUIC choose UDP rather than raw IP?

Middleboxes drop unknown IP protocols but pass UDP everywhere; UDP gives ports + a checksum, and QUIC rebuilds reliability/ordering/congestion control on top in encrypted user space.

Why does 0-RTT resumption send request data in the very first packet?

On resumption the client already holds cached crypto keys from the prior session, so it can encrypt and send application data immediately instead of waiting a round-trip to negotiate.

Why is a QUIC Connection ID needed at all if we already have IP and port?

IP/port (the 4-tuple) change when the network changes (Wi-Fi→4G), which would kill the connection; the Connection ID is a stable identifier that lets the server recognise the migrated client.

Why does the HOL-blocking advantage of HTTP/3 grow as the number of objects

N

grows?

More multiplexed objects mean a single loss can block more later objects under TCP (up to

N - 1

), while QUIC always blocks just the one lost stream — so the gap widens with

N

Why is HTTP/3 especially valuable on high-latency mobile links?

Setup savings are measured in RTTs, and mobile RTTs are large, so cutting 2 RTT to 1 (or 0) removes a big absolute chunk of the time-to-first-byte.

Edge cases

EDGE CASE: A page loads exactly one object. Does QUIC's stream independence help?

No meaningful HOL advantage here — with a single stream there are no other streams to protect; the setup-latency and migration benefits still apply though.

EDGE CASE: Zero packets are lost during a page load. Do HTTP/2 and HTTP/3 differ in HOL blocking?

No — with no loss there is nothing to stall, so both deliver smoothly; QUIC's edge only appears under actual packet loss.

EDGE CASE: The very first-ever visit to a site over QUIC. What's the setup cost?

1 RTT, not 0 — 0-RTT requires cached keys from a previous session, which a first-ever visit doesn't have.

EDGE CASE: A network path silently blocks all UDP. What happens to HTTP/3?

HTTP/3 can't establish a QUIC connection, so the client falls back to HTTP/2 over TCP; this is why servers advertise HTTP/3 rather than force it.

EDGE CASE: 0-RTT data is replayed by an attacker. Why is that a special risk?

0-RTT data isn't protected against replay because it's sent before the full handshake confirms freshness, so only idempotent requests (like GET) should ride in 0-RTT. See TLS 1.3 — handshake and 0-RTT.

EDGE CASE: Loss rate is extremely high (say most packets drop). Does QUIC still "win big"?

The relative HOL advantage remains, but under massive loss everything is dominated by retransmission delay and congestion control backing off, so raw throughput suffers regardless of transport.

EDGE CASE: A single stream inside QUIC loses a packet. Is that stream head-of-line blocked?

Yes — within a stream ordering is still enforced, so bytes after the gap wait; the point is only that other streams are spared.

Connections

HTTP-2 — multiplexing and HPACK
TCP — three-way handshake and reliability
UDP — connectionless transport
TLS 1.3 — handshake and 0-RTT
Head-of-line blocking
Congestion control — slow start, AIMD
Middlebox ossification and protocol evolution