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

4.3.26 · D3 · Coding › Computer Networks › HTTP - 3 — QUIC, UDP-based, why

Yeh page parent HTTP/3 note ki "numbers se prove karo" companion hai. Parent ne bataya kyun QUIC TCP se behtar hai. Yahan hum har case grind karenge — fresh vs resumed connections, zero loss, heavy loss, ek object vs pachaas, aur woh tricky "resumed connection with a lost packet" twist — taaki exam mein koi bhi scenario tumhe surprise na kare.

Shuru karne se pehle, un do quantities ka ek reminder jo hum har jagah reuse karenge.

The scenario matrix

Is topic se jo bhi question poochha ja sakta hai, woh in cells mein se kisi ek mein aata hai. Neeche har worked example us cell ke saath tagged hai jo woh fill karta hai.

#	Case class	Concrete question jo woh poochha hai	Example
A	Setup, fresh connection	Bilkul nayi visit par pehla byte aane mein kitna time?	Ex 1
B	Setup, resumed (0-RTT)	Returning visitor ke liye kitna time?	Ex 2
C	Degenerate: $R T T \to 0$	Perfect/local link par kya hota hai?	Ex 3
D	Zero-loss delivery ( $p = 0$ )	Kya QUIC tab bhi help karta hai jab kuch lost nahi hota?	Ex 4
E	Single loss, small $N$	Ek object, ek loss — TCP vs QUIC	Ex 5
F	Single loss, large $N$	50 objects, ek loss — 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	Kya 0-RTT tab bhi jeetta hai agar woh packet drop ho jaye?	Ex 9

Case A — Setup on a fresh connection

Worked example Ex 1 — pehli visit, 40 ms RTT

Ek user jisका pehle koi connection nahi tha woh ek page load karta hai. $R T T = 40$ ms. TCP+TLS 1.3 vs fresh QUIC ke liye time-before-first-request-byte compare karo.

Forecast: Abhi guess karo — kya QUIC ek $R T T$ faster hai ya do?

TCP+TLS 1.3 setup. Yeh step kyun? Parent formula kehta hai yahan setup $1 R T T$ TCP three-way handshake ke liye plus $1 R T T$ TLS 1.3 ke liye hai (dekho TCP — three-way handshake and reliability aur 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. Yeh step kyun? QUIC crypto aur transport parameters ko ek flight mein fold kar leta hai, isliye fresh connection mein $1 R T T$ lagta hai. $T_{setup}^{QUIC, fresh} = 1 R T T = 40 ms$
Saving. Yeh step kyun? Exam usually difference maangta hai. $80 - 40 = 40 ms saved$

Verify: Units poore mein ms hain (RTT in ms × dimensionless count = ms). QUIC exactly ek $R T T$ remove karta hai (alag TLS round-trip), jo parent ke "1-RTT connections" claim se match karta hai. ✓

Case B — Resumed (0-RTT) connection

Worked example Ex 2 — returning visitor, same 40 ms RTT

Wahi user ek ghante baad wapas aata hai; browser ne QUIC session cache kar rakha hai. $R T T = 40$ ms. Ab setup wait kitna hai?

Forecast: Zero, ya ek $R T T$ ?

0-RTT yaad karo. Yeh step kyun? Resumed connection par QUIC request ko cached keys use karke sabse pehle packet ke saath attach kar sakta hai. $T_{setup}^{QUIC, resumed} = 0 R T T = 0 ms$
TCP+TLS se compare karo. Yeh step kyun? TCP repeat visit par bhi apna handshake skip nahi kar sakta (TCP Fast Open help karta hai lekin middleboxes wide block karte hain — dekho Middlebox ossification and protocol evolution). $80 - 0 = 80 ms saved$

Verify: $0 R T T$ matlab request byte pehle datagram mein nikalta hai — bhejne se pehle literally koi wait nahi hai. 80 ms saving poore TCP+TLS cost ke barabar hai, jaise expected tha. ✓

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

Worked example Ex 3 — localhost / same datacenter,

$R T T \approx 0$ Server aur client ek hi machine par hain, isliye $R T T \to 0$ . Kya QUIC ka setup advantage tab bhi matter karta hai?

Forecast: Kya 40 ms saving tab bhi rehti hai jab RTT shrink ho jaata hai?

Har formula ki limit lo. Yeh step kyun? Setup times $R T T$ ke multiples hain, isliye jaise $R T T \to 0$ sab vanish ho jaate hain. $lim_{R T T \to 0} 2 R T T = 0, lim_{R T T \to 0} 1 R T T = 0$
Interpret karo. Yeh step kyun? Saving hai $(2 - 1) R T T = 1 \times R T T$ , jo bhi $\to 0$ ho jaati hai. $saving = 1 \times R T T \to 0 ms$

Verify: Advantage $R T T$ ke proportional hai. Near-zero-latency link par QUIC ka setup win disappear ho jaata hai — aur exactly isliye QUIC ke headline benefits high-RTT mobile users ke liye quote kiye jaate hain, localhost benchmarks ke liye nahi. Sanity check pass: koi benefit tab nahi aa sakta jab round-trip cost hi nahi tha hataane ko. ✓

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

Worked example Ex 4 — perfect wire, 50 objects, no loss

Ek page mein $N = 50$ objects hain, har ek ~1 packet, aur loss probability $p = 0$ hai. Kya HTTP/3, HTTP/2 ko delivery mein beat karta hai (setup ignore karo)?

Forecast: Jab kuch lost hi nahi, kya koi HOL difference hoga?

TCP ke under blocked objects count karo. Yeh step kyun? Head-of-line blocking sirf loss se trigger hoti hai. $p = 0$ ke saath koi packet kabhi missing nahi hoga. $E [blocked]_{TCP} = 0$
QUIC ke under blocked objects count karo. Yeh step kyun? Same reasoning — koi loss nahi, koi stall nahi. $E [blocked]_{QUIC} = 0$

Verify: Dono 0 hain — tie. HOL blocking ek loss-triggered problem hai, isliye clean wire par HTTP/3 ki stream independence koi delivery advantage nahi deti (iske setup aur migration benefits tab bhi apply hote hain). Yeh myth khatam karta hai ki HTTP/3 hamesha faster hota hai. ✓

Case E — Single loss, small $N$

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

Worked example Ex 5 — ek object (

$N = 1$ ), ek lost packet Ek single 1-packet object request kiya gaya aur uska packet ek baar lost ho gaya. TCP vs QUIC ke under kitne objects blocked hain?

Forecast: Sirf ek object ke saath, kya dono protocols mein fark ho sakta hai?

TCP blocked count. Yeh step kyun? Lost packet hi akela object hai; baad mein "block" karne ko kuch nahi. $E [blocked]_{TCP} = 1$
QUIC blocked count. Yeh step kyun? Single stream apne loss se delay hoti hai. $E [blocked]_{QUIC} = 1$

Verify: Dono 1 ke barabar — tie. Figure mein ek TCP truck aur ek QUIC go-kart dono ek toy le ja rahe hain; khoyi hui toy dono mein se exactly usi ek ko rokti hai. Yeh prove karta hai ki HOL advantage sirf tab aata hai jab $N > 1$ ho — poora point doosri streams ka survive karna hai, aur yahan koi aur stream nahi. ✓

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

Worked example Ex 6 — 50 objects, pehle wale ka packet lost

$N = 50$ objects multiplex kiye gaye hain. Object #1 ka packet lost hai; objects #2–#50 pehle hi aa chuke hain. Har protocol ke liye blocked-object count?

Forecast: TCP un 49 already-arrived objects mein se kitno ko deliver karne se mana kar deta hai?

TCP: in-order delivery rule. Yeh step kyun? TCP ek ordered byte stream hai: woh gap fill hone tak gap ke baad ka byte deliver nahi karega. Isliye lost wale ke peeche queued sab objects wait karte hain. $E [blocked]_{TCP} = N - 1 = 50 - 1 = 49$
QUIC: independent streams. Yeh step kyun? Har object apni stream par ride karta hai apni ordering ke saath (dekho Head-of-line blocking). Stream 1 par loss sirf stream 1 ko block karta hai. $E [blocked]_{QUIC} = 1$
The gap. Yeh step kyun? Yahi woh number hai jo parent ne "grows with $N$ " kaha tha. $49 - 1 = 48 objects freed by QUIC$

Verify: Parent ke toy model mein $N = 50$ plug karo: TCP $\approx N - 1 = 49$ , QUIC $= 1$ . ✓ Figure dekho — 49 go-karts tute hue wale se aage nikal jaate hain, lekin poora TCP truck khada reh jaata hai. Advantage $N$ ke saath scale karta hai: exactly isliye HTTP/3 lossy links par rich pages ke liye shine karta hai. ✓

Case G — Probabilistic "at least one loss"

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

Per-packet loss $p = 0.05$ hai, aur $N = 50$ packets fly karte hain. Probability kya hai ki kam se kam ek lost ho (matlab TCP ka HOL blocking trigger ho)?

Forecast: Sirf 5% loss per packet ke saath, kya page-wide stall likely hai ya rare?

Probability ki sab 50 survive karein. Yeh step kyun? Independent packets har ek $1 - p$ probability se survive karte hain; sab ka survive karna multiply karna hai. $P (no loss) = (1 - p)^{N} = (0.95)^{50}$
"At least one loss" ke liye complement. Yeh step kyun? "Kam se kam ek" "koi nahi" ka opposite hai, isliye 1 se subtract karo — har failure combination summing karne se kaafi easy hai. $P (\geq 1 loss) = 1 - (0.95)^{50} \approx 1 - 0.0769 = 0.9231$

Verify: $\approx 92.3%$ . Sanity: 5% each par 50 chances ke saath, hit almost certain hai — probability 1 ke just neeche hai, aur yeh single-packet 5% se kaafi upar hai. Isliye lossy mobile link par TCP page almost always HOL blocking hit karta hai, jabki QUIC ka damage ek stream tak confined rehta hai. ✓

Case H — Real-world word problem

Worked example Ex 8 — train par commuter, sab kuch combined

4G par ek commuter ( $R T T = 100$ ms, $p = 0.05$ ) freshly 50-object page load karta hai. Total "wait pain" estimate karo: setup time plus blocked-object count, TCP+TLS 1.3 vs fresh QUIC, assuming objects mein exactly ek loss hoti hai.

Forecast: Roughly kitne milliseconds aur kitne stalled objects dono ke beech ka fark hai?

Setup times. Yeh step kyun? Ex 1 ki structure $R T T = 100$ ms ke saath reuse karo. $T_{setup}^{TCP+TLS} = 2 \times 100 = 200 ms, T_{setup}^{QUIC} = 1 \times 100 = 100 ms$
Setup saving. Yeh step kyun? Difference woh hai jo QUIC koi bhi data move hone se pehle buys karta hai. $200 - 100 = 100 ms saved$
Single loss par blocked objects. Yeh step kyun? Ex 6 se, worst case loss object #1 ko hit karti hai. $TCP blocked = 49, QUIC blocked = 1$

Verify: Units check: setup ms mein, blocked count ke roop mein. QUIC 100 ms bachata hai aur single loss par stall se 48 objects (49 − 1) free karta hai. High-RTT lossy link par QUIC ke dono mechanisms — faster setup aur no transport HOL — ek saath fire karte hain, jo parent ke claim se match karta hai ki mobile users sabse zyada benefit karte hain. ✓

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

Worked example Ex 9 — kya 0-RTT tab bhi jeetta hai jab woh pehla datagram drop ho?

Ek returning visitor 0-RTT first packet mein request data bhejta hai ( $R T T = 60$ ms). Wahi packet lost ho jaata hai. Ab effective setup wait kitna hai, aur kya QUIC tab bhi TCP+TLS 1.3 se beat karta hai?

Forecast: Magic 0-RTT packet par loss — kya advantage evaporate ho jaata hai?

Nominal 0-RTT cost. Yeh step kyun? Success par, resumed QUIC $0 R T T$ pay karta hai. $T_{setup}^{QUIC, 0-RTT, success} = 0 ms$
Lost first packet account karo. Yeh step kyun? Ek lost packet ko loss detect hone ke baad retransmit karna padta hai — ek extra round-trip. Isliye effective wait ek $R T T$ ban jaata hai. $T_{setup}^{QUIC, 0-RTT, lost} \approx 1 R T T = 60 ms$
TCP+TLS 1.3 se compare karo. Yeh step kyun? TCP resumed visit par bhi apna poora $2 R T T$ deta hai. $T_{setup}^{TCP+TLS} = 2 \times 60 = 120 ms > 60 ms$

Verify: Unlucky case mein bhi, degraded 0-RTT ( $60$ ms) TCP+TLS ( $120$ ms) se $60$ ms se beat karta hai — kyunki QUIC sirf apne 1-RTT behaviour par fall back karta hai, usse bura kabhi nahi. Advantage shrink hota hai lekin vanish nahi hota. Yahi woh subtle point hai jo graders love karte hain: 0-RTT ka benefit best-case-extra hai, koi fragile all-or-nothing nahi. ✓

Recall Quick self-test

Fresh QUIC vs TCP+TLS 1.3 setup at 80 ms RTT — kitna saved? ::: $2 \times 80 - 1 \times 80 = 80$ ms. $p = 0$ ke saath, QUIC TCP vs kitne objects unblock karta hai? ::: Zero — HOL blocking loss-triggered hai, isliye dono tie karte hain. 50 objects, pehla 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$ . Kya 0-RTT tab bhi TCP+TLS ko beat karta hai agar pehla packet lost ho? ::: Haan — yeh $1 R T T$ par degrade hota hai, jo TCP ke $2 R T T$ se ab bhi kam hai.

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