HTTP - 3 — QUIC, UDP-based, why: Visual walkthrough

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

Hum do questions ko unke picture-proofs tak chase karenge:

Pehle useful byte se pehle kitne round-trips ka wait? (setup latency)
Jab ek packet lost ho, toh kitne web objects freeze ho jaate hain? (head-of-line blocking)

Koi bhi formula aane se pehle, ek measurement par agree kar lete hain jis par sab kuch depend karta hai.

Step 1 — Round-trip kya hota hai, aur RTT mein measure kyun karein?

KYA karte hain yahan: hum $R T T$ ko milliseconds ki jagah apni time ki unit ke roop mein chunte hain.

KYU yeh tool aur raw milliseconds nahi: connection setup karne ka har step ek bheja gaya sawaal, awaited jawab hota hai. Aap tab tak aage nahi badh sakte jab tak jawab wapas nahi aata — yeh exactly ek round-trip of waiting hai. Toh "setup kitna slow hai" actually yeh hai "kitne round-trips wait karne padte hain", aur $R T T$ natural ruler hai. $R T T$ mein count karna comparison ko fast fibre ya slow mobile se independent banata hai.

PICTURE: arrow aapke paas se nikalta hai, server tak pohonchta hai, wapas aata hai. Pura loop ek $R T T$ hai. Jis cheez ka bhi wait karna padta hai, usme kam se kam ek loop lagta hai.

Step 2 — TCP ka setup: loops ginna (the "before" picture)

KYA karte hain: purane stack ke liye $k$ count karein — pehle TCP, phir uske upar TLS 1.3.

KYU alag-alag do counts: purani duniya mein yeh do independent conversations ek doosre ke upar stacked hain. TCP ko pehle finish karna padta hai pipe open hai yeh prove karke, tabhi TLS ko shuru hone ki permission milti hai prove karne ki ki aap kaun hain. Do conversations, har ek ko apna round-trip chahiye, matlab hum sirf unke loop-counts add karte hain.

PICTURE: do coloured brackets vertically stacked. Lavender bracket TCP ka handshake hai — SYN out, SYN-ACK back — yeh $1$ loop hai. Sirf uske band hone ke baad coral bracket (TLS) shuru hoti hai — ClientHello out, ServerHello back — aur $1$ loop. Pehla request byte tabhi ja sakta hai jab dono brackets band ho jaayein.

Step 3 — QUIC ka setup: loops ko ek mein fold karna

KYA karte hain: UDP ko koi handshake nahi chahiye (yeh connectionless hai), isliye QUIC ko transport layer par kuch wait nahi karna padta. QUIC phir crypto handshake ko apne pehle flight of packets ke andar hi le jaata hai.

KYU yeh $k$ collapse karta hai: Step 2 ke do sawaal — "kya pipe open hai?" aur "tum kaun ho + keys?" — ek hi sawaal mein merge ho jaate hain jo same pehle packet mein bheja jaata hai. Ek sawaal, ek loop back. Matlab $k = 1$ . Koi alag transport round-trip wait nahi karna padta, kyunki UDP sirf packets fire karta hai bina kisi permission ke.

PICTURE: ek single bracket. Aapka pehla packet already crypto ClientHello aur transport parameters saath liye hue hai. Server ek baar jawab deta hai; aap ek loop mein done hain. Step 2 ke two-bracket tower se is single bracket ko compare karein.

Step 4 — Degenerate case: returning visitors ke liye 0-RTT

KYA karte hain: special input handle karein "aap pehle is server se baat kar chuke hain."

KYU iska apna alag step hai: Steps 2–3 ne ek fresh stranger assume kiya tha. Lekin ek returning visitor already pichli baar ki keys yaad rakhta hai. Toh koi identity/key sawaal poochna hi nahi padta — aap apna actual HTTP request pehle packet ke saath hi attach kar sakte hain aur immediately bhej sakte hain, koi bhi jawab aane se pehle.

PICTURE: request khud jaane wale arrow par sawaar hai — koi bracket nahi, data se pehle koi waiting loop nahi. Server aapki request aur resumption ticket ek hi saath dekhta hai. Yeh $k = 0$ edge case hai.

Step 5 — Doosri race: ek lost packet kitna cost karta hai

Ab hum sawaal bilkul badal dete hain: setup bhool jaao, maano connection up hai. Hum kaafi saare objects wala ek page load kar rahe hain aur ek packet lost ho gaya. Kitne objects freeze ho jaate hain?

KYA karte hain: $N$ objects line up karo aur unme se exactly ek ka packet girgao.

KYU ordering villain hai: TCP waada karta hai "koi byte tab tak upar nahi diya jaayega jab tak saare pehle wale byte nahi aa jaayein." Yeh waada ek global line hai. QUIC bhi yahi waada karta hai, lekin sirf har stream ke andar — per-stream line.

PICTURE: $N$ boxes, label hai object 1…N. Lost packet par coral ✗ laga hai. Hum dekhne wale hain ki freeze kitni door tak failti hai dono duniya mein.

Step 6 — TCP ki blocking: poori line freeze ho jaati hai

KYA karte hain: single TCP stream mein lost packet mark karo, phir uske baad ki sab cheez shade karo jo deliver nahi ho sakti.

KYU baad wala sab freeze ho jaata hai: TCP object $i + 1, i + 2, \dots$ ko browser ko nahi dega jab tak object $i$ ka missing packet retransmit nahi hota — chahe woh baad wale bytes physically already aa chuke hon. In-order rule unhe hostage rakhta hai. Yeh head-of-line blocking transport layer par hai, aur HTTP/2 isse nahi bach saka kyunki usne sab kuch ek TCP stream par multiplex kiya.

PICTURE: ✗ position $i$ par baitha hai; coral wash positions $i$ se $N$ tak cover karti hai. Saare woh objects ek retransmission ka wait karte hain (jo khud $\approx 1 R T T$ leta hai).

Step 7 — QUIC ki blocking: sirf injured stream freeze hoti hai

KYA karte hain: same loss, lekin ab har object apni khud ki stream par hai.

KYU freeze spread nahi ho sakti: QUIC ka in-order rule per stream hai. Object $i$ ki apni private line hai, toh uska missing packet sirf object $i$ ko hi rok sakta hai. Streams $1, \dots, i - 1, i + 1, \dots, N$ ki apni independent ordering hai aur woh flow karte rehte hain — yahi exactly wajah hai ki transport-level HOL blocking gayab ho jaati hai.

PICTURE: ✗ abhi bhi ek box par girta hai, lekin ab sirf wahi ek box coral-washed hai. Baaki saare $N - 1$ boxes mint-green rehte hain aur deliver hote hain. Ise directly Step 6 ke coral flood se compare karein.

Step 8 — Bilkul naya protocol kyun nahi? (woh constraint jisne UDP force kiya)

KYA karte hain: justify karein kyun carrier UDP hai na ki koi shiny new transport IP layer par.

KYU yeh ek derivation step hai aur trivia nahi: poora "independent streams + user-space transport" design tabhi deployable hai kyunki middleboxes (routers, firewalls, NATs) unknown IP protocol number wale packets drop kar dete hain. UDP pehle se har jagah pass ho jaata hai (yeh DNS carry karta hai). Toh QUIC ko UDP ke andar delivery truck ki tarah sawaar hona padta hai, aur reliability/ordering/congestion control khud rebuild karni padti hai, encrypted, user space mein.

PICTURE: teen lanes ek firewall gate par pohonchti hain. "New protocol" lane blocked hai (✗). TCP lane allowed hai lekin frozen/ossified. UDP lane freely pass hoti hai (✓) QUIC truck carry karte hue.

Ek-picture summary

Yeh single figure dono derivations compress karta hai: left par setup ladder ( $k = 2 \to 1 \to 0$ ) aur right par blocking spread ( $N - i + 1$ vs $1$ ).

Recall Feynman: poora walkthrough plain words mein

Pehle hum raazi hue ki waiting "round-trips" mein measure karein — ek loop server tak aur wapas — kyunki har setup sawaal hai poochho, phir echo ka wait karo. Purana tarika do sawaal ek ke baad ek poochha karta hai: "kya line open hai?" (ek loop) phir "tum kaun ho aur key kya hai?" (ek aur loop) — do loops of waiting. QUIC unhe ek packet mein squish kar deta hai, toh ek loop; aur agar aap pehle visit kar chuke hain, toh woh key yaad rakhta hai aur request instantly bhejta hai — zero loops.

Phir ek alag kahani: kaafi saare toys ek road par safar kar rahe hain. Purana TCP rule hai "strictly order mein unload karo," toh agar toy number 25 gir jaaye, toys 26 se 50 sab wait karte hain — aadha pile freeze ho jaata hai. QUIC har toy ko apna chhota go-kart deta hai apni ordering ke saath, toh ek tuta hua go-kart sirf usi ek toy ko rokta hai; baaki 49 sail karte rehte hain. Aur yeh sab ordinary UDP road par chalti hai kyunki fancy special roads guards (middleboxes) dwara block ho jaati hain — plain road hi woh hai jo hamesha open rehti hai.

Connections

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