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

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

Ek shared vocabulary jaldi dekh lo taaki neeche koi word undefined na rahe:

Definition Neeche har jagah use hone wale words aur symbols

QUIC = originally "Quick UDP Internet Connections" — woh transport protocol jis par HTTP/3 chalta hai. Yeh UDP ke andar baitha hai aur reliability, ordering, congestion control, aur encryption khud rebuild karta hai.
RTT (round-trip time) = woh time jo ek signal ko client se server tak aur wapas aane mein lagta hai. Yeh setup ka natural "clock tick" hai: har extra back-and-forth ek RTT ki pure waiting add karta hai. Mobile par ek RTT 50–100 ms ho sakta hai.
0-RTT = "zero round-trips of setup" — real request data pehle hi packet mein bhejna, bina kisi waiting handshake ke. Yeh sirf ek resumed connection par possible hai jahan client ne server ki crypto keys cache kar rakhi hoon.
QPACK = HTTP/3 ka header-compression scheme. Yeh wahi kaam karta hai jo HTTP/2 ka HPACK karta hai (repeated headers ko chhota karna) lekin redesigned hai taaki jab streams out of order aayein tab bhi kaam kare.
4-tuple = woh chaar values jo ek TCP connection identify karti hain: (source IP, source port, destination IP, destination port). Koi bhi ek badlo — jaise tumhara IP jab tum Wi-Fi→mobile switch karte ho — aur TCP ise ek alag, dead connection maanta hai.
$N$ = un independent objects (images, scripts, ...) ki sankhya jo ek page ek single connection par ek saath load kar raha hai. Rich pages mein $N \approx 50$ hota hai.

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

True or false — justify

TRUE or FALSE: HTTP/3 mein HTTP/2 se alag HTTP methods aur status codes hain.

FALSE — HTTP semantics (GET, POST, headers, 200 OK) byte-for-byte same hain; sirf transport TCP se QUIC par gaya. Dekho HTTP-2 — multiplexing and HPACK.

TRUE or FALSE: Kyunki HTTP/3 UDP par chalta hai, ek lost packet simply kabhi recover nahi hota.

FALSE — QUIC apne ACKs, sequence numbers, aur retransmission UDP ke upar layer karta hai, isliye lost data recover hoti hai; UDP sirf delivery truck hai.

TRUE or FALSE: HTTP/2 ne head-of-line blocking poori tarah khatam kar di thi.

FALSE — HTTP/2 ne application-layer HOL blocking khatam ki, lekin ek lost TCP segment abhi bhi transport layer par har multiplexed stream ko rok deta hai; sirf QUIC use hatata hai. Dekho Head-of-line blocking.

TRUE or FALSE: QUIC sirf request/response body encrypt karta hai, bilkul classic HTTPS ki tarah.

FALSE — QUIC almost poora packet encrypt karta hai, jismein zyaadatar transport-level headers bhi hain, specifically taaki middleboxes chedchhad na kar sakein, aur encryption mandatory hai.

TRUE or FALSE: Ek fresh (pehli baar) QUIC connection 0-RTT setup achieve karta hai.

FALSE — ek fresh connection ki cost 1 RTT hai; 0-RTT sirf tab available hota hai jab ek connection resume ho raha ho jahan client ne server ki crypto keys pehle se cache kar rakhi hoon.

TRUE or FALSE: Agar aap lightweight, unencrypted version chahte ho to QUIC ko bina TLS ke chala sakte ho.

FALSE — koi unencrypted QUIC nahi hota; TLS 1.3 (current encryption handshake, jo keys aur identity negotiate karta hai) QUIC handshake mein baked in hai aur band nahi kiya ja sakta.

TRUE or FALSE: Independent streams ka matlab hai QUIC mein bilkul bhi ordering nahi hai.

FALSE — har stream individually ordered hai (byte

k

abhi bhi us stream ke andar byte

k - 1

ka wait karta hai); fayda yeh hai ki streams ek dusre ka wait nahi karti.

TRUE or FALSE: Wi-Fi se mobile data par switch karna hamesha ek TCP connection drop karta hai lekin QUIC nahi.

TRUE — TCP 4-tuple se identify hota hai jismein tumhara IP bhi hai, isliye IP change use khatam karta hai; QUIC ek Connection ID use karta hai jo IP/port se independent hai, jisse connection migrate ho sakta hai. Dekho TCP — three-way handshake and reliability.

TRUE or FALSE: QUIC ne congestion control chhor di kyunki usne TCP chhor diya.

FALSE — QUIC congestion control user space mein reimplement karta hai (slow start karo, phir gently badhao aur loss par sharply back off karo); TCP chhodne ka matlab uske acche parts rebuild karna hai, discard karna nahi. Dekho Congestion control — slow start, AIMD.

Spot the error

"HTTP/3 ne TCP replace karne ke liye ek brand-new IP-layer protocol number invent kiya." — kya galat hai?

Ek brand-new protocol number middleboxes drop kar dete jo kuch bhi unfamiliar block karte hain; QUIC deliberately UDP ke andar chhupa rehta hai, jo universally allowed hai (yeh DNS carry karta hai).

"QUIC OS kernel mein TCP ki tarah rehta hai, isliye ise upgrade karne ke liye OS update chahiye." — kya galat hai?

QUIC user space mein rehta hai (browser/server binary ke andar), isliye yeh kisi bhi normal app ki tarah update hota hai — yahi precisely wajah hai ki yeh evolve ho sakta hai jahan kernel-frozen TCP nahi kar sakta.

"Kyunki streams independent hain, stream A par ek packet lose hone se stream B bhi thoda delay hota hai." — kya galat hai?

Stream A par loss sirf stream A ko delay karta hai; streams B, C, D bina rukawat ke chalti rehti hain — yahi independence QUIC ki TCP par puri baat hai.

"TCP par TLS 1.3 QUIC jaiti hi fast hai kyunki dono TLS 1.3 use karte hain." — kya galat hai?

TCP+TLS1.3 ko TCP handshake (1 RTT) chahiye pehle TLS start bhi ho sake, total 2 RTT hota hai; QUIC transport + crypto ko ek flight mein fold karta hai yaani 1 RTT (ya resume par 0).

"HTTP/3 HTTP/2 ki tarah HPACK header compression use karta hai." — kya galat hai?

HTTP/3 QPACK use karta hai, HPACK ka ek redesign jo out-of-order, independent streams ke liye adapted hai; compressed meaning same hai lekin mechanism alag hai.

"QUIC unreliable hai kyunki UDP ka koi handshake nahi hota." — kya galat hai?

QUIC ka apna cryptographic + transport handshake UDP datagrams ke andar carry hota hai; UDP ke handshake ki kami irrelevant hai jab QUIC khud ek supply karta hai.

"Transport headers encrypt karna sirf privacy ke liye hai." — kya galat hai?

Privacy ek bonus hai; primary goal middleboxes ko transport fields padhne aur "optimise" karne se rokna hai, yahi wajah hai jisse TCP ossified aur frozen ho gaya.

Why questions

Ek lost TCP segment unrelated HTTP/2 streams kyun rok deta hai?

TCP ek single ordered byte stream deliver karta hai aur baad ke bytes tab tak hand over karne se mana karta hai jab tak missing earlier segment na aa jaaye, isliye us stream ko share karne wali saari multiplexed streams saath mein wait karti hain.

QUIC baad ki streams kyun deliver kar sakta hai jab ek earlier wali retransmit ka wait kar rahi ho?

QUIC ordering per stream track karta hai, isliye stream A ke sequence numbers mein gap stream B ke already-complete bytes ki delivery block nahi karta.

QUIC ne raw IP ki jagah UDP kyun choose kiya?

Middleboxes unknown IP protocols drop karte hain lekin UDP har jagah pass karte hain; UDP ports + ek checksum deta hai, aur QUIC uske upar encrypted user space mein reliability/ordering/congestion control rebuild karta hai.

0-RTT resumption pehle packet mein hi request data kyun bhejta hai?

Resumption par client ke paas pehle se cached crypto keys hoti hain prior session se, isliye woh negotiate karne ke liye ek round-trip wait karne ki jagah turant application data encrypt karke bhej sakta hai.

QUIC Connection ID ki zaroorat hi kyun hai jab hamare paas pehle se IP aur port hai?

IP/port (4-tuple) tab change ho jaata hai jab network badlta hai (Wi-Fi→4G), jo connection khatam kar deta; Connection ID ek stable identifier hai jo server ko migrated client pehchaanne deta hai.

HTTP/3 ka HOL-blocking advantage objects ki sankhya

N

badhne ke saath kyun badhta hai?

Zyada multiplexed objects ka matlab hai ek single loss TCP mein zyada baad ke objects rok sakta hai (up to

N - 1

tak), jabki QUIC hamesha sirf wahi ek lost stream block karta hai — isliye fark

N

ke saath badhta hai.

HTTP/3 high-latency mobile links par specially valuable kyun hai?

Setup savings RTTs mein measure hoti hain, aur mobile RTTs bade hote hain, isliye 2 RTT ko 1 (ya 0) par laana time-to-first-byte ka ek bada absolute chunk hata deta hai.

Edge cases

EDGE CASE: Ek page exactly ek object load karta hai. Kya QUIC ki stream independence help karta hai?

Yahan koi meaningful HOL advantage nahi — ek hi stream ke saath doosri koi streams nahi hain bachane ke liye; setup-latency aur migration benefits phir bhi apply hote hain.

EDGE CASE: Page load ke dauran zero packets lost hote hain. Kya HTTP/2 aur HTTP/3 HOL blocking mein alag hain?

Nahi — koi loss nahi toh kuch rokne wala nahi, isliye dono smoothly deliver karte hain; QUIC ka edge sirf actual packet loss hone par dikhta hai.

EDGE CASE: Kisi site par pehli baar QUIC se visit. Setup cost kya hai?

1 RTT, 0 nahi — 0-RTT ke liye kisi previous session se cached keys chahiye, jo pehli baar visit mein hoti nahi hain.

EDGE CASE: Ek network path silently sabhi UDP block kar deta hai. HTTP/3 ka kya hoga?

HTTP/3 ek QUIC connection establish nahi kar sakta, isliye client HTTP/2 over TCP par fall back karta hai; yahi wajah hai servers HTTP/3 advertise karte hain instead of force karne ke.

EDGE CASE: 0-RTT data ek attacker replay karta hai. Yeh special risk kyun hai?

0-RTT data replay ke khilaf protected nahi hai kyunki yeh full handshake freshness confirm karne se pehle bheja jaata hai, isliye sirf idempotent requests (jaise GET) hi 0-RTT mein jaani chahiye. Dekho TLS 1.3 — handshake and 0-RTT.

EDGE CASE: Loss rate bahut zyada hai (maano zyaadatar packets drop ho rahe hain). Kya QUIC phir bhi "bada win" deta hai?

Relative HOL advantage rehta hai, lekin massive loss ke neeche sab kuch retransmission delay aur congestion control ke back off se dominate ho jaata hai, isliye raw throughput transport se parwah kiye bina suffer karta hai.

EDGE CASE: QUIC ke andar ek single stream ek packet lose karta hai. Kya woh stream head-of-line blocked hai?

Haan — stream ke andar ordering abhi bhi enforce hoti hai, isliye gap ke baad ke bytes wait karte hain; baat sirf yeh hai ki doosri streams bach jaati hain.

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