HTTP - 3 — QUIC, UDP-based, why: Worked examples

This page is the "prove it with numbers" companion to the parent HTTP/3 note. The parent told you why QUIC beats TCP. Here we grind through every case — fresh vs resumed connections, zero loss, heavy loss, one object vs fifty, and the tricky "resumed connection with a lost packet" twist — so no scenario surprises you in an exam.

Before we start, one reminder of the two quantities we will reuse everywhere.

The scenario matrix

Every question this topic can ask lives in one of these cells. Each worked example below is tagged with the cell it fills.

#	Case class	Concrete question it asks	Example
A	Setup, fresh connection	How long before the first byte on a brand-new visit?	Ex 1
B	Setup, resumed (0-RTT)	How long for a returning visitor?	Ex 2
C	Degenerate: $R T T \to 0$	What happens on a perfect/local link?	Ex 3
D	Zero-loss delivery ( $p = 0$ )	Does QUIC still help when nothing is lost?	Ex 4
E	Single loss, small $N$	One object, one loss — TCP vs QUIC	Ex 5
F	Single loss, large $N$	50 objects, one loss — the HOL gap	Ex 6
G	Probabilistic loss over many packets	"At least one loss" probability	Ex 7
H	Real-world word problem	Mobile user, mixed setup + loss, total wait	Ex 8
I	Exam twist: 0-RTT with a lost first packet	Does 0-RTT still win if that packet drops?	Ex 9

Case A — Setup on a fresh connection

Worked example Ex 1 — first visit, 40 ms RTT

A user with no prior connection loads a page. $R T T = 40$ ms. Compare time-before-first-request-byte for TCP+TLS 1.3 vs fresh QUIC.

Forecast: Guess now — is QUIC one $R T T$ faster, or two?

TCP+TLS 1.3 setup. Why this step? The parent formula says setup here is $1 R T T$ for the TCP three-way handshake plus $1 R T T$ for TLS 1.3 (see TCP — three-way handshake and reliability and TLS 1.3 — handshake and 0-RTT). $T_{setup}^{TCP+TLS1.3} = 1 R T T + 1 R T T = 2 R T T = 2 \times 40 = 80 ms$
Fresh QUIC setup. Why this step? QUIC folds crypto and transport parameters into one flight, so a fresh connection costs $1 R T T$ . $T_{setup}^{QUIC, fresh} = 1 R T T = 40 ms$
Saving. Why this step? The exam usually wants the difference. $80 - 40 = 40 ms saved$

Verify: Units are ms throughout (RTT in ms × dimensionless count = ms). QUIC removes exactly one $R T T$ (the separate TLS round-trip), matching the parent's "1-RTT connections" claim. ✓

Case B — Resumed (0-RTT) connection

Case C — Degenerate limit $R T T \to 0$

Case D — Zero packet loss ( $p = 0$ )

Case E — Single loss, small $N$

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

Case F — Single loss, large $N$ (the headline case)

Worked example Ex 6 — 50 objects, the first one's packet is lost

$N = 50$ objects are multiplexed. The packet for object #1 is lost; objects #2–#50 have already arrived. Blocked-object count for each protocol?

Forecast: How many of the 49 already-arrived objects does TCP refuse to hand over?

TCP: in-order delivery rule. Why this step? TCP is one ordered byte stream: it will not deliver byte after the gap until the gap is filled. So all objects queued behind the lost one wait. $E [blocked]_{TCP} = N - 1 = 50 - 1 = 49$
QUIC: independent streams. Why this step? Each object rides its own stream with its own ordering (see Head-of-line blocking). A loss on stream 1 blocks only stream 1. $E [blocked]_{QUIC} = 1$
The gap. Why this step? This is the number the parent said "grows with $N$ ." $49 - 1 = 48 objects freed by QUIC$

Verify: Plug $N = 50$ into the parent's toy model: TCP $\approx N - 1 = 49$ , QUIC $= 1$ . ✓ Look at the figure — 49 go-karts sail past the broken one, but the whole TCP truck sits still. The advantage scales with $N$ : exactly why HTTP/3 shines on rich pages over lossy links. ✓

Case G — Probabilistic "at least one loss"

Worked example Ex 7 — 50 packets, 5% per-packet loss

Per-packet loss $p = 0.05$ , and $N = 50$ packets fly. What is the probability that at least one is lost (i.e. that TCP's HOL blocking gets triggered at all)?

Forecast: With only 5% loss per packet, is a page-wide stall likely or rare?

Probability all 50 survive. Why this step? Independent packets each survive with probability $1 - p$ ; all surviving means multiplying. $P (no loss) = (1 - p)^{N} = (0.95)^{50}$
Complement for "at least one loss." Why this step? "At least one" is the opposite of "none," so subtract from 1 — much easier than summing every failure combination. $P (\geq 1 loss) = 1 - (0.95)^{50} \approx 1 - 0.0769 = 0.9231$

Verify: $\approx 92.3%$ . Sanity: with 50 chances at 5% each, a hit is almost certain — probability sits just under 1, and it is far above the single-packet 5%. So on a lossy mobile link a TCP page almost always hits HOL blocking, while QUIC's damage stays confined to one stream. ✓

Case H — Real-world word problem

Worked example Ex 8 — commuter on a train, everything combined

A commuter on 4G ( $R T T = 100$ ms, $p = 0.05$ ) freshly loads a 50-object page. Estimate total "wait pain": setup time plus blocked-object count, TCP+TLS 1.3 vs fresh QUIC, assuming exactly one loss occurs among the objects.

Forecast: Roughly how many milliseconds and how many stalled objects separate the two?

Setup times. Why this step? Reuse Ex 1's structure with $R T T = 100$ ms. $T_{setup}^{TCP+TLS} = 2 \times 100 = 200 ms, T_{setup}^{QUIC} = 1 \times 100 = 100 ms$
Setup saving. Why this step? Difference is what QUIC buys before any data moves. $200 - 100 = 100 ms saved$
Blocked objects on the single loss. Why this step? From Ex 6, worst case the loss hits object #1. $TCP blocked = 49, QUIC blocked = 1$

Verify: Units check: setup in ms, blocked as a count. QUIC saves 100 ms and frees 48 objects (49 − 1) from stall on a single loss. On a high-RTT lossy link both of QUIC's mechanisms — faster setup and no transport HOL — fire at once, matching the parent's claim that mobile users benefit most. ✓

Case I — Exam twist: 0-RTT but the first packet is lost

Worked example Ex 9 — does 0-RTT still win when that first datagram drops?

A returning visitor sends request data in the 0-RTT first packet ( $R T T = 60$ ms). That very packet is lost. What is the effective setup wait now, and does QUIC still beat TCP+TLS 1.3?

Forecast: Loss on the magic 0-RTT packet — does the advantage evaporate?

Nominal 0-RTT cost. Why this step? On success, resumed QUIC pays $0 R T T$ . $T_{setup}^{QUIC, 0-RTT, success} = 0 ms$
Account for the lost first packet. Why this step? A lost packet must be retransmitted after the loss is detected — one extra round-trip. So the effective wait becomes one $R T T$ . $T_{setup}^{QUIC, 0-RTT, lost} \approx 1 R T T = 60 ms$
Compare to TCP+TLS 1.3. Why this step? TCP still owes its full $2 R T T$ even on a resumed visit. $T_{setup}^{TCP+TLS} = 2 \times 60 = 120 ms > 60 ms$

Verify: Even in the unlucky case, degraded 0-RTT ( $60$ ms) still beats TCP+TLS ( $120$ ms) by $60$ ms — because QUIC falls back only to its 1-RTT behaviour, never worse. The advantage shrinks but does not vanish. This is the subtle point graders love: 0-RTT's benefit is best-case-extra, not a fragile all-or-nothing. ✓

Recall Quick self-test

Fresh QUIC vs TCP+TLS 1.3 setup at 80 ms RTT — how much saved? ::: $2 \times 80 - 1 \times 80 = 80$ ms. With $p = 0$ , how many objects does QUIC unblock vs TCP? ::: Zero — HOL blocking is loss-triggered, so both tie. 50 objects, first packet lost: TCP blocked count? ::: $N - 1 = 49$ . $P (\geq 1$ loss $)$ for 50 packets at $p = 0.05$ ? ::: $1 - 0.9 5^{50} \approx 0.923$ . Does 0-RTT still beat TCP+TLS if the first packet is lost? ::: Yes — it degrades to $1 R T T$ , still less than TCP's $2 R T T$ .

Connections

4.3.26 HTTP - 3 — QUIC, UDP-based, why (Hinglish)
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