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

HTTP/3 ke seedha neeche QUIC hai. QUIC ke seedha neeche UDP hai. Poora stack hai: HTTP/3 → QUIC → UDP → IP. Yahan IP (Internet Protocol, upar define kiya) woh bottom network layer hai jo actually machines ke beech packets route karta hai. TCP is stack mein kaheen nahi aata — yehi poora point hai.

Paanch letters expand hote hain:

• S — Setup faster (0/1-RTT),
• H — HOL blocking gone (independent streams),
• I — IP migration (Connection ID),
• M — Multiplexing without TCP,
• E — Encryption built-in (TLS 1.3 mandatory).

TCP par chaar distinct wins hain S, H, I, aur E. M (Multiplexing) woh overlapping letter hai: kaafi streams ko multiplex karna koi nayi capability nahi hai jo QUIC ne invent ki — HTTP/2 pehle se TCP par streams multiplex karta tha. QUIC jo add karta hai woh hai yeh multiplexing karna bina TCP ke single ordered stream ke, jo exactly wahi hai jo H win (HOL blocking gone via independent streams) already describe karta hai. Isliye M actually H ka hi ek alag angle se restatement hai, na ki paanchvaa independent benefit. SHIM-E mein M sirf isliye hai kyunki isse word pronounceable banta hai.

Galat. HTTP semantics (methods, headers, status codes) HTTP/2 ke same hain. Sirf transport badla. Header compression alag hai — HTTP/2 HPACK use karta hai aur HTTP/3 QPACK (dono upar define: repeated headers ko chhota karne ka same goal, lekin QPACK QUIC streams par out-of-order arrival tolerate karta hai) — phir bhi GET /index.html ka matlab dono mein exactly same hai.

TCP + TLS 1.3 ke liye 2 RTT kyun? HTTP byte bhejne se pehle round trips count karo:

1. TCP three-way handshake (dekho TCP — three-way handshake and reliability): client SYN bhejta hai, server SYN-ACK reply karta hai, client ACK bhejta hai. Client data sirf tabhi bhej sakta hai jab SYN-ACK wapas aaye — woh client ka packet bahar aur server ki reply wapas = 1 full RTT of pure waiting.
2. TLS 1.3 handshake (dekho TLS 1.3 — handshake and 0-RTT): ab open TCP connection ke upar, client ClientHello bhejta hai, server ServerHello + keys reply karta hai, aur sirf woh reply aane ke baad hi client encrypted data bhej sakta hai = 1 aur RTT.

Isliye $T_{\text{setup}}^{\text{TCP+TLS}}=1RT{T}_{\text{TCP}}+1RT{T}_{\text{TLS}}=2RTT$.

Fresh QUIC ke liye sirf 1 RTT kyun? QUIC transport handshake aur crypto handshake ko same first flight of packets mein fold kar deta hai. Client ki first flight mein "let's connect" aur "here is my crypto" dono hote hain; server ki single reply dono ka jawab deti hai. Isliye $T_{\text{setup}}^{\text{QUIC fresh}}=1RTT$.

Resumed QUIC ke liye 0 RTT kyun? Repeat visit par client pehle se server ki crypto keys yaad rakhta hai, isliye woh actual HTTP request ko pehle packet ke saath encrypt karke attach kar sakta hai. Pure waiting ka koi round trip nahi chahiye: $T_{\text{setup}}^{\text{QUIC 0-RTT}}=0RTT$.

Ab $RTT=80$ ms plug karo:

• (a) $T_{\text{setup}}^{\text{TCP+TLS}}=2\times 80=160$ ms.
• (b) $T_{\text{setup}}^{\text{QUIC fresh}}=1\times 80=80$ ms.
• (c) $T_{\text{setup}}^{\text{QUIC 0-RTT}}=0$ ms.

Returning QUIC 0-RTT use karta hai: $T_{\text{setup}}^{\text{QUIC 0-RTT}}=0$ ms. TCP+TLS1.3: $T_{\text{setup}}^{\text{TCP+TLS}}=160$ ms. Saving $=160-0=160$ ms.

Assumption (pehle bataya): packet losses independent hain — ek packet ka gayab hona humein kuch nahi batata ki koi aur packet bhi gayab hoga ya nahi. Yahi hume per-packet survival probabilities ko multiply karne deta hai; independence ke bina product $(1-p{)}^N$ valid nahi hota. Ek single packet ke survive hone ki probability hai $1-p=0.98$. Kyunki losses independent hain, sabhi $N$ ka saath survive karna probability hai $(1-p{)}^N=0.98^{50}$. Isliye $P(\text{at least one loss})=1-(1-p{)}^N=1-0.98^{50}\approx 1-0.3642=0.6358.$ Yeh formula kyun? "Kam se kam ek" "koi nahi gaya" ka complement hai. "Koi nahi gaya" calculate karna easy hai kyunki independent survivals multiply hote hain; $1$ se subtract karna saare "exactly-$k$-lost" cases add karne se bahut simple hai.

Assumption (pehle bataya): jaise L2.3 mein, losses independent hain packets ke across, har ek same probability $p$ se lost. Yeh exactly woh setup hai jo binomial count define karta hai, isliye binomial coefficient $\left(\genfrac{}{}{0ex}{}{N}{k}\right)$ aur factors $p^k(1-p{)}^{N-k}$ justified hain. Lost packets ki sankhya binomial count follow karti hai: $N$ packets mein se har ek independently $p$ probability se lost hota hai. (a) Expected losses. Independent indicators ke sum ki expectation unki probabilities ka sum hai: $E[\text{losses}]=Np=50\times 0.02=1.0.$ Isliye average par ek packet lost hota hai — yehi reason hai ki L3/L4 mein single-loss model natural baseline hai, lekin note karo yeh sirf average hai, guarantee nahi. (b) Exactly two lost. Choose karo ki $50$ mein se kaun se $2$ lost hain ($\left(\genfrac{}{}{0ex}{}{50}{2}\right)$ ways), woh $2$ lost ($p^2$), baaki $48$ survive karte hain ($(1-p{)}^{48}$): $P(\text{exactly }2)=\left(\genfrac{}{}{0ex}{}{50}{2}\right)p^2(1-p{)}^{48}=1225\times 0.02^2\times 0.98^{48}\approx 0.1858.$ Isliye bhaale average ek loss hai, phir bhi roughly $18.6\%$ chance hai do losses ka — multiple losses common hain, exotic nahi.

TCP: delivery strictly in order hai, isliye lost object ke baad aane wala har object tab tak roka jaata hai jab tak retransmission aaye. Agar loss position $k$ par hai, toh objects $k+1,k+2,\dots ,N$ block hain — woh $N-k$ baad wale objects block hain, aur object $k$ khud bhi late hai. Worst case hai $k=1$: $N-1=49$ tak baad wale objects block. QUIC: har object apni stream par ride karta hai, isliye stream $k$ par loss sirf stream $k$ ko block karta hai. Exactly $1$ object delayed hai. Baaki $49$ flow karte rehte hain. Yeh "independent streams" ka visual meaning hai: ek toota hua go-kart, na ki ek frozen truck.

HTTP/2 kaafi logical streams ko frames mein slice karta hai aur unhe interleave karta hai — isse application-layer HOL blocking hati hai. Lekin woh saare frames ek TCP byte-stream mein dal diye jaate hain. TCP promise karta hai ki byte-#500 tab tak deliver nahi hoga jab tak bytes #1–#499 nahi pahunchein. Jab ek TCP segment lost hota hai, TCP saare already-arrived later bytes ko rok leta hai — including frames jo doosri HTTP/2 streams ke hain — jab tak retransmission gap nahi bharta. Isliye blocking ek layer neeche chali gayi, HTTP se TCP mein, lekin khatam nahi hui. QUIC isse solve karta hai har stream ko transport ke andar apna ordering dekar, taaki ek stream mein gap doosri stream ko kabhi nahi rokta. Dekho Head-of-line blocking.

QUIC: har lost packet sirf apni stream ko delay karta hai. Do alag streams par do independent losses exactly 2 objects delay karte hain; baaki $48$ flow karte hain. Delayed objects ka count losses ke count ke barabar hota hai — yeh linearly aur dheere barta hai. TCP: sab kuch ek ordered stream hai, isliye jo matter karta hai woh hai do losses mein se earliest kaun sa hai. Agar earlier loss position $k_{\min }$ par hai, toh saare objects $k_{\min }+1,\dots ,N$ block hain = $N-k_{\min }$ objects — doosra loss practically kuch nahi add karta, kyunki earliest gap already tail ko freeze kar chuka hai. Worst case ($k_{\min }=1$) abhi bhi $49$ block karta hai. Gap kyun barta hai: QUIC ke under, blocked-objects ≈ number-of-losses (linear, chhota). TCP ke under, blocked-objects earliest loss ki position se govern hota hai, aur zyada losses ke saath earliest loss aage badhta jaata hai, ek aur badi tail freeze karta hai. Zyada losses QUIC ko barely hurt karte hain lekin TCP ko worst case ki taraf push karte hain — isliye lossy links ($p$ zyada, losses zyada) par independent streams ka advantage barta hai.

(a) Setup. $T_{\text{setup}}^{\text{TCP+TLS}}=2\times 60=120$ ms; $T_{\text{setup}}^{\text{QUIC fresh}}=1\times 60=60$ ms. Saving $=120-60=60$ ms. (b) Blocked objects. Ek loss jo uniformly position $k\in \{1,\dots ,N\}$ par placed hai:

• TCP: blocked-later count hai $N-k$. $k$ par averaging: $E[\text{blocked}{]}_{\text{TCP}}=\frac{1}{N}{\sum }_{k=1}^N(N-k)=\frac{N-1}{2}=\frac{49}{2}=24.5.$
• QUIC: exactly lost stream delayed hai, isliye $E[\text{blocked}{]}_{\text{QUIC}}=1$. Story: fresh-connection setup win ek fixed $60$ ms hai, lekin HOL win page ke saath scale karta hai — average par TCP ek loss ke peeche ~$24.5$ objects stall karta hai jabki QUIC ek. Rich, lossy pages par HOL win dominate karta hai.

Define combined saving $=(\text{setup ms saved})+(\text{HOL ms saved})$, blocked objects ko time mein convert karke "har average blocked object retransmission ke liye ek extra $RTT$ wait karta hai."

Setup saving. $T_{\text{setup}}^{\text{QUIC 0-RTT}}=0$ ms; $T_{\text{setup}}^{\text{TCP+TLS}}=2\times 60=120$ ms. Setup saved $=120$ ms.

HOL time. Toy model ke under ek stalled batch ek retransmission $RTT$ wait karta hai unblock hone ke liye, aur number stalled alag hai: TCP average par $24.5$ objects gap ke peeche rakhta hai, QUIC sirf $1$. Kyunki TCP mein woh $24.5$ objects sab same single retransmission ke peeche wait karte hain, extra wall-clock delay hai $1RTT=60$ ms TCP ke liye versus $1RTT=60$ ms QUIC ke liye — same ek retransmission RTT. Isliye is simplest model mein HOL wall-clock time saving $0$ ms hai bhaale $23.5$ kam objects stalled hoon: QUIC ka win yahan yeh hai ki kitne objects ruke hain, na ki single retransmission wait ki length.

Combined saving (wall-clock ms) $=120+0=120$ ms, plus ek throughput/experience win of $24.5-1=23.5$ fewer objects stalled jo yeh ms-only number deliberately capture nahi karta.

Honest answer: clean combined time saving hai $120$ ms (sab setup se); HOL benefit dikhta hai $23.5$ fewer blocked objects mein, jo perceived load improve karta hai bhaale single retransmission RTT shared ho. Dono report karo — sirf ek ms figure QUIC ko understate karta hai.

Reason 1 — deployability. Middleboxes (NATs, firewalls) routinely unknown IP protocol numbers wale packets drop kar dete hain. Ek brand-new protocol number internet ke bahut bade hisse mein silently blackhole ho jaata, isliye use kabhi deploy nahi kiya ja sakta. UDP already universally permitted hai (DNS carry karta hai), isliye QUIC packets har jagah pass hote hain. Reason 2 — evolvability. TCP OS kernel mein rehta hai aur middleboxes dwara fossilize ho gaya hai jo uske headers inspect aur rewrite karte hain. QUIC user space mein rehta hai aur apna almost poora packet encrypt kar leta hai, isliye browsers/servers ordinary software ki tarah transport upgrades ship kar sakte hain aur middleboxes peek ya meddle nahi kar sakte. Consequence: UDP sirf ports + checksum provide karta hai, isliye QUIC ko khud reliability, ordering, flow control, aur congestion control rebuild karna padta hai (dekho Congestion control — slow start, AIMD). Yeh ek cost hai, lekin yeh cost user-space code mein paid hai jo evolve ho sakta hai — exactly yehi point hai.

Ek TCP connection 4-tuple (source IP, source port, destination IP, destination port) se identify hoti hai. Jab Wi-Fi → 4G tumhara source IP change karta hai, tuple kisi known connection se match nahi karta — OS packets ko treat karta hai jaise woh kisi known connection ke nahi — TCP connection mar jaati hai aur rebuild karni padti hai (naya handshake, naya TLS). QUIC connection ko Connection ID se tag karta hai jo IP aur port se independent hai. Jab tumhara IP change hota hai, server tab bhi same Connection ID recognize karta hai aur connection migrate ho jaata hai bina interruption ke — koi naya handshake nahi, koi dropped call nahi.

Yeh claim layers confuse karta hai. UDP sach mein koi retransmission nahi offer karta — woh dumb "delivery truck" hai. Lekin QUIC, UDP ke upar, apna khud ka packet numbers, acknowledgements, aur retransmission logic add karta hai. Agar ek QUIC packet lost hota hai, QUIC missing ACK detect karta hai aur affected stream par data resend karta hai. Application ke view se, HTTP/3 har byte reliably aur per-stream order mein deliver karta hai — TCP jaisa reliable, aur TCP ke cross-stream HOL blocking ke bina. Isliye HTTP/3 fully reliable hai; unreliability sirf UDP carrier mein rehti hai QUIC ki reliability machinery ke neeche.

HTTP/3 ke seedha neeche transport ::: QUIC (jo UDP par run karta hai). Fresh QUIC ke liye $T_{\text{setup}}$ RTTs mein ::: $1$ RTT. TCP+TLS1.3 ke liye $T_{\text{setup}}$ RTTs mein ::: $2$ RTT (1 TCP handshake ke liye + 1 TLS 1.3 ke liye). Probability of at least one loss among $N$ packets, per-packet loss $p$ (losses independent) ::: $1-(1-p{)}^N$. Expected number of packets lost among $N$ at loss $p$ ::: $Np$. Probability of exactly $k$ losses among $N$ at loss $p$ (independent) ::: $\left(\genfrac{}{}{0ex}{}{N}{k}\right)p^k(1-p{)}^{N-k}$. Average objects blocked by one uniformly-placed loss under TCP, $N$ objects ::: $(N-1)/2$. Objects blocked by one loss under QUIC ::: exactly 1. Header compression format in HTTP/2 vs HTTP/3 ::: HPACK vs QPACK (QPACK tolerates out-of-order streams). QUIC feature that survives Wi-Fi→4G ::: the Connection ID (connection migration).