4.3.25
Intuition Is pure note ka 80/20HTTP/1.1 ek connection pe ek hi request bhejta hai, plain text mein. Yeh slow isliye hai kyunki
(a) requests ek ke peeche ek queue mein lagte hain (head-of-line blocking ), (b) headers har
request pe word-for-word repeat hote hain (cookies, user-agent), aur (c) browser ko khud andaza
lagana padta hai ki aage kya fetch karna hai.
HTTP/2 teeno problems fix karta hai ek binary, framed protocol over one connection mein switch
karke: multiplexing (kaafi streams interleaved), HPACK (header compression with a shared table),
aur server push (server resources bhejta hai maangne se pehle). Same semantics (GET, headers, status
codes) — wire format bilkul alag.
Definition Head-of-line (HOL) blockingHTTP/1.1 mein, ek TCP connection responses ko order mein process karta hai. Agar response #1 ek
bada slow file hai, toh responses #2 aur #3 wait karenge chahe woh ready hon. Browsers ne iska
jugaad nikala tha ~6 parallel TCP connections per origin kholke — yeh wasteful tha (har ek ko apna
TCP+TLS handshake, congestion window chahiye hota hai).
HTTP/2 mein KYA badla:
Text → binary framing .
6 connections → 1 connection, many streams .
Repeated headers → HPACK compression .
Pull-only → optional server push .
Definition Frame, Stream, Message
Ek frame wire pe sabse chhoti unit hai: ek 9-byte header + payload. Types mein shamil hain
HEADERS, DATA, SETTINGS, PUSH_PROMISE, RST_STREAM, WINDOW_UPDATE.
Ek stream frames ka ek independent, bidirectional sequence hai, jo ek Stream ID se identify hota hai.
Ek message (ek request ya ek response) = ek HEADERS frame + zero ya zyada DATA frames,
sab ek hi Stream ID share karte hain.
Intuition Feynman pictureImagine karo ek conveyor belt (the TCP connection). Har ek poora package rakhne aur wait karne ki
jagah, tum har package ke labelled tukde kaat ke unhe interleave kar dete ho. Har tukde ka label
(Stream ID) receiver ko batata hai ki woh tukda kaunse package ka hai. Receiver label se reassemble
karta hai.
Yeh kaise kaam karta hai step by step:
Client stream 1 kholta hai: ek HEADERS frame bhejta hai (Stream ID = 1).
Client stream 3 kholta hai: HEADERS bhejta hai (Stream ID = 3) — response 1 ka intezaar kiye bina .
Server interleave karta hai: DATA(1), DATA(3), DATA(1), HEADERS(3 response)... kisi bhi order mein.
Har side Stream ID se demultiplex karta hai.
Common mistake "Multiplexing head-of-line blocking ko poori tarah khatam kar deta hai."Yeh sahi kyun lagta hai: HTTP layer pe, streams sach mein independent hain — ek slow stream ab
doosron ko block nahi karta. Pakad: HTTP/2 ab bhi ek TCP connection ke upar chalta hai, aur TCP bytes
ko order mein deliver karta hai. Agar ek TCP packet lost ho jaye, toh TCP saari streams ko rok leta hai
retransmission tak — yeh TCP-level HOL blocking hai. Fix: HTTP/3 QUIC (over UDP) pe shift karta hai,
jahan har stream ki apni ordering hoti hai, transport-level HOL blocking khatam ho jaati hai. Toh: HTTP/2
application -layer HOL hatata hai, transport -layer wala nahi.
Intuition Headers ko special compression kyun chahiye thiHar HTTP request almost identical headers bhejti hai: :method: GET, user-agent: ..., cookie: ....
100 requests pe wahi kilobytes 100 baar. Aap unhe sirf gzip nahi kar sakte — yahin pe SPDY
CRIME attack ke liye vulnerable tha (compression ratio secret cookie bytes leak karta hai). HPACK ek
compression scheme hai jo isse resist karne ke liye design ki gayi hai jabki headers ko chhota bhi karti hai.
Definition HPACK ke teen mechanisms
Static table : 61 predefined common header entries (:method GET = index 2, etc.), spec mein fixed.Dynamic table : ek per-connection table jise encoder/decoder dono update karte hain jaise headers dekhe jaate hain, taaki ek
repeated header agli baar ek single index byte ban jaaye.Huffman coding : literal header strings (jo indexed nahi hain) ek fixed Huffman
code se encode hoti hain jo HTTP header characters ke liye optimize ki gayi hai.
Ek header field encode kaise hoti hai — teen cases:
Worked example Dynamic-table ka faydaRequest 1 cookie: id=abc... ek literal-with-indexing ke roop mein bhejti hai → woh dynamic table mein,
maan lo, index 62 pe enter hoti hai. Yeh step kyun? taaki hum lambi cookie dobara na bhejein. Request 2 wahi
cookie indexed ke roop mein bhejti hai → index 62 ko reference karta ek single byte. Ek 200-byte cookie ~1 byte ban jaati hai.
Worked example Index 10 ko 5-bit prefix mein encode karna2 5 − 1 = 31 10 < 31 10 0b01010 plus uske upar 3 flag bits. Ek byte. Kyun: chhota index seedha fit ho gaya, koi continuation nahi chahiye.
Worked example Index 1337 ko 5-bit prefix mein encode karnaPrefix mein 31 1337 − 31 = 1306 1306 = 10 ⋅ 128 + 26 26 + 128 = 154 10 31, 154, 10. Kyun: value 5 bits mein fit nahi hui, isliye 7-bit groups mein overflow ho gaya.
Common mistake "HPACK sirf headers ka gzip hai."Yeh sahi kyun lagta hai: dono compress karte hain. Fix: attacker-influenced + secret data pe gzip
length ke zariye secrets leak karta hai (CRIME). HPACK attacker aur secret strings ki context-mixing avoid karta hai aur
adaptive entropy coding ki jagah indexing + static Huffman table use karta hai, us attack ko neutralize karta hai.
Server client ka ek aisa response proactively bhej sakta hai jo usne maanga nahi hai abhi, pehle ek
PUSH_PROMISE frame bhejkr (client ke stream pe) ek even Stream ID reserve karke, phir us nayi stream pe pushed
response. Use case: client index.html maangta hai; server style.css aur app.js push karta hai kyunki usse pata hai page ko chahiye.
HOW:
Server stream 1 pe GET /index.html receive karta hai.
Server stream 1 pe PUSH_PROMISE bhejta hai /style.css ka promise stream 2 pe.
Server stream 2 pe /style.css ke liye HEADERS+DATA bhejta hai.
Jab parsing browser ko style.css ki zaroorat hoti hai, woh already cache mein hoti hai → koi round trip nahi.
Common mistake "Server push hamesha pages faster banaata hai."Yeh sahi kyun lagta hai: yeh ek round trip remove karta hai. Reality: server kuch aisa push kar sakta hai jo
browser already cache mein rakhe hue hai , bandwidth waste hoti hai, aur push usi congestion window ke liye
real HTML se compete karta hai. Galat tune ki hui push ne performance aksar hurt ki — isliye major browsers ne
push hata diya/deprecate kar diya (Chrome ne drop kiya). Modern replacement hai 103 Early Hints + <link rel=preload>.
Worked example HTML + CSS + JS wala page load karnaForecast karo frame sequence, phir verify karo:
HEADERS(1): GET /index.htmlHEADERS(1 resp) + DATA(1): HTML, interleaved ke saath...PUSH_PROMISE(1 → 2), HEADERS(2)+DATA(2): pushed style.cssClient HEADERS(3) kholta hai: GET /app.js — turant bheja, multiplexed.
Har step kyun? Ek connection, koi wait nahi, headers request 1 ke baad index bytes mein shrink ho gaye,
CSS parser ke maangne se pehle aa jaati hai. Yahi hai HTTP/2 ki value ek trace mein.
HTTP/2 mein wire pe unit kya hai — HTTP/1.1 text lines ki jagah kya aaya? Binary frames (9-byte header + payload); types jaise HEADERS, DATA, SETTINGS, PUSH_PROMISE.
HTTP/2 mein stream define karo. Frames ka ek independent bidirectional sequence jo ek Stream ID share karta hai, ek single connection pe multiplexed.
Client streams ___ IDs use karte hain, server-pushed ___ IDs. Odd; even (taaki woh kabhi collide na karein).
HTTP/2 kaun sa HOL blocking fix karta hai, aur kaun sa rehta hai? Application/HTTP-layer HOL fix karta hai; TCP-layer HOL (ek lost packet saari streams rok deta hai) rehta hai — HTTP/3/QUIC se solve hota hai.
HPACK ke teen compression mechanisms ke naam batao. Static table (61 entries), per-connection dynamic table, literals ka Huffman coding.
Headers ko sirf gzip kyun nahi kiya? Attacker+secret data ka adaptive compression length ke zariye secrets leak karta hai (CRIME); HPACK indexing/static-Huffman isse resist karta hai.
Kaun sa frame server push announce karta hai aur woh kaun sa ID reserve karta hai? PUSH_PROMISE; pushed response ke liye even Stream ID reserve karta hai.
HPACK encode index 1337 in a 5-bit prefix. Prefix=31, phir 1337−31=1306 → bytes 31,154,10.
Server push browsers mein kyun deprecate hua? Aksar already-cached resources push karta tha aur congestion window ke liye compete karta tha; 103 Early Hints + preload se replace hua.
Default max frame payload size aur kyun limited hai? 16384 bytes (2 14
Recall Ek 12-saal ke bachche ko samjhao (Feynman)Puraana internet: tum ek letter bhejte ho, reply ka wait karte ho, phir agla bhejte ho — slow, aur tum
har baar envelope ka poora address block waste karte ho. HTTP/2 aisa hai jaise har letter ke chhote numbered
cards kaat ke unhe ek hi tube mein ek saath dalte ho; doosri taraf number se sort karta hai. Yeh ek
shortcut list bhi rakhta hai taaki repeated info ("from: you") sirf "#5" ban jaaye. Aur ek smart helper
tumhe woh homework pages bhej sakta hai jo use pata hai tumhe aage chahiye honge, maangne se pehle. Ek
hi dikkat: agar tube mein ek card kho jaaye, sab uske resent hone ka wait karte hain — HTTP/3 usse fix karne ke liye alag tubes banata hai.
"FM-H-P" : F rames M ultiplexed streams banate hain; H PACK headers chhote karta hai;
P ush aage bhejta hai. Ya: "Frame More, Header Pack, Push."
HTTP-1.1 — predecessor; text protocol aur HOL blocking jise yeh fix karta hai.HTTP-3-and-QUIC — TCP-layer HOL blocking hatane ke liye UDP pe move karta hai.TCP — single shared connection & congestion window; remaining HOL ka source.TLS — HTTP/2 practice mein hamesha TLS ke upar chalta hai (ALPN "h2" negotiate karta hai).Huffman-Coding — HPACK ke andar literal string compression.CRIME-and-BREACH-attacks — naive header gzip kyun unsafe hai.Varint-encoding — wahi prefix-integer / 7-bit continuation idea.
~6 parallel TCP connections
HTTP/2 binary framed protocol
Stream - unique Stream ID
Message - HEADERS plus DATA
