Exercises — HTTP - 2 — multiplexing, header compression (HPACK), server push

Framing spec se, 9 bytes = 72 bits aise split hote hain:

• Length — 24 bits
• Type — 8 bits
• Flags — 8 bits
• R (reserved) — 1 bit
• Stream ID — 31 bits

Check: $24+8+8+1+31=72$ bits $=9$ bytes. ✅

Client streams odd IDs use karte hain (1, 3, 5, …); server-pushed streams even IDs use karte hain (2, 4, 6, …). Kyon: dono sides ek hi connection par streams open karti hain. Agar dono ek hi pool se pick kar sakti, toh do independent choosers same number pick kar sakte — collision. Odd/even mein split karna ek zero-coordination tarika hai jo guarantee karta hai ki dono kabhi clash nahi karenge.

• HEADERS — (HPACK-encoded) header block carry karta hai jo ek message shuru karta hai.
• DATA — body bytes carry karta hai.
• PUSH_PROMISE — us stream ko announce karta hai jise server push karna chahta hai, ek even Stream ID reserve karte hue.
• RST_STREAM — connection ko touch kiye bina ek stream ko abruptly cancel karta hai.

$2^{14}=16384$ bytes ($16$ KiB). Length field could $2^{24}-1=16777215$ bytes tak hold karta, lekin default cap deliberately choti rakhi gayi hai. Kyon: agar ek frame bahut bada ho sakta, toh use bhejna single TCP connection ko lambe samay ke liye hog kar leta — wohi head-of-line stall wapas aa jaata jise multiplexing khatam karne ke liye hai. 16 KiB cap rakhe se doosre streams ke frames beech mein slip kar sakte hain.

Rule: agar $I<2^N-1$ toh $I$ ko seedha $N$ bits mein store karo. Yahan $N=5$, toh $2^5-1=31$. Kyunki $10<31$, hum bas $10$ ko 5 bits mein likhte hain. Us byte ke 3 high bits HPACK flag bits hain (woh representation type mark karte hain). Ek byte total. Koi continuation nahi chahiye.

$2^5-1=31$ aur $1337\ge 31$, toh prefix overflow karta hai.

1. Prefix value $31$ emit karo (sab 5 bits set).
2. Remainder $I^{\prime }=1337-31=1306$.
3. $1306$ ko 7-bit groups mein split karo, low group pehle, high bit = "aur aayenge":
   • $1306=10\cdot 128+26$, toh pehla continuation byte $=26+128=154$.
   • Agla $I^{\prime }=10<128$, toh final byte $=10$ (high bit clear = "last").

Byte sequence: 31, 154, 10 — teen bytes.

Fully indexed = leading 1 bit, phir index ek 7-bit prefix mein. Index $2<2^7-1=127$, toh seedha fit ho jaata hai. Byte hai 1 ke baad 0000010: $\text{1}\Vert \text{0000010}=\text{0b10000010}=130$ Ek byte poori :method: GET line encode kar deta hai.

Per connection setup $=\text{TCP}+\text{TLS}=1+2=3$ RTTs.

• HTTP/1.1, ek origin ke liye 6 cold connections khule: handshakes time mein overlap kar sakte hain, lekin har connection phir bhi $3$ RTTs pay karta hai aur har ek tiny cold congestion window se shuru karta hai. Setup RTTs per connection $=3$ RTT $=3\times 40=120$ ms.
• HTTP/2, 1 connection: $3$ RTT $=120$ ms — same handshake latency, lekin chhah cold ones ki jagah sirf ek warmed congestion window.

Asli jeet handshake number mein nahi hai (dono $3$ RTTs setup); yeh hai ki HTTP/2 ise ek baar pay karta hai aur phir ek properly-grown congestion window reuse karta hai, jabki HTTP/1.1 ke chhah windows har baar cold start karte hain aur compete karte hain. Total handshake work: HTTP/1.1 $=6\times 3=18$ RTT-connections of setup cost; HTTP/2 $=1\times 3=3$. Ratio $18/3=6\times$ kam setup cost.

Setup: teen streams (1, 3, 5) ek TCP connection par DATA frames interleave karte hain. Maan lo ek TCP segment jo stream 1 ka part carry karta hai network par lost ho jaata hai.

• TCP guarantee karta hai ki application bytes in order receive kare. Toh TCP sab kuch buffer kar leta hai jo lost segment ke baad aaya — jisme streams 3 aur 5 ke perfectly-intact frames bhi hain — aur unhe tab tak upar dene se mana karta hai jab tak lost segment retransmit na ho jaaye (≈ 1 RTT baad).
• HTTP/2 layer par, streams independent hain — wahan kuch block nahi karta. Lekin block ek layer neeche, TCP (transport) par hota hai.

Conclusion: HTTP/2 application-layer HOL blocking hataata hai lekin transport-layer HOL blocking nahi. HTTP/3 over QUIC har stream ko apni ordering deta hai, toh ek lost packet sirf apni stream ko stall karta hai — TCP dekho kyon in-order delivery wait force karta hai.

(a) HTTP/1.1: $200\times 100=20000$ bytes. (b) HPACK: request 1 full literal bhejta hai ($\approx 200$ bytes) aur dynamic table mein store karta hai; requests 2–100 har ek 1-byte index bhejti hai → $200+99\times 1=299$ bytes. Savings: $20000-299=19701$ bytes, ek $20000/299\approx 66.9\times$ shrink.

1. HEADERS Stream 1 par — /index.html ke liye client ki request. Stream 1 odd hai → client-initiated. ✅
2. PUSH_PROMISE Stream 1 par — requesting stream par announce kiya gaya, Stream 2 (even → server-initiated) pushed resource ke liye reserve karte hue.
3. HEADERS Stream 2 par — /style.css ke liye response headers.
4. DATA Stream 2 par — CSS bytes.
5. HEADERS Stream 1 par — /index.html ke liye response headers.
6. DATA Stream 1 par — HTML bytes.

Key point: promise client ki stream (1) par sawaar hoti hai, lekin pushed content ek nayi even stream (2) par rehta hai, toh kisi bhi odd client stream se kabhi collide nahi karta. Jab parser <link> style.css ka discover karta hai, woh already aa raha/cached hota hai → round trip bachaya.

Har index $<127$, toh har ek single fully-indexed byte hai: 1 || 7-bit index.

• idx 2 → 1 byte
• idx 4 → 1 byte
• idx 7 → 1 byte

Total $=3$ bytes teen poori header lines ke liye. (Compare: unhe text mein likhna dozens of bytes hota.)

Do HPACK properties attack todti hain:

1. Attacker+secret par koi adaptive entropy coding nahi. HPACK ki string compression ek static Huffman table use karti hai jo spec mein fixed hai, koi adaptive coder nahi jo attacker text secret text se match hone par shrink ho. Toh compressed length ab signal nahi karta "tumhara guess ek secret byte se mila."
2. Indexing per-whole-header, table-based hai. Ek secret cookie ya toh ek table index hai (opaque, fixed 1 byte) ya ek literal — yeh gzip ki sliding window ki tarah attacker input ke saath byte-by-byte mix nahi hoti.

Ye dono milke woh length-vs-guess correlation hatate hain jo CRIME exploit karta tha. Woh layer jo abhi bhi apni protection chahti hai woh hai TLS (connection ki encryption/integrity); HPACK compression side protect karta hai, TLS confidentiality side protect karta hai. CRIME-and-BREACH-attacks dekho.

Encode (L2.3 se): prefix $=31$; remainder $1306=10\cdot 128+26$ → bytes 31, 154, 10. Decode: prefix all-ones hai ($31$) → accumulator $31$ se shuru karo, phir continuation bytes padho:

• byte $154$: high bit set (subtract $128\Rightarrow 26$), add $26\cdot 128^0=26$. Accumulator $=31+26=57$. Aur aayenge.
• byte $10$: high bit clear → add $10\cdot 128^1=1280$, phir ruko. Accumulator $=57+1280=1337$. ✅

$1337$ recover hua — encoding lossless hai. Yahi varint idea hai: 7 data bits per byte, top bit = continuation flag.

Default frame payload $=2^{14}=16384$ bytes. Body $=2^{20}=1048576$ bytes. Number of frames $=2^{20}/2^{14}=2^6=64$ frames exactly. Ek frame mein representable hai? Length field $2^{24}-1=16777215$ bytes tak hold karta hai, aur $2^{20}=1048576\le 16777215$, toh haan, ek single 1 MiB frame representable hai — lekin sirf tabhi jab peer ne SETTINGS_MAX_FRAME_SIZE raise kiya ho. By default aap $64$ frames of $16$ KiB bhejoge taaki koi single frame connection ko monopolise na kare.

Odd Stream IDs kiske hote hain? ::: Client ke (client-initiated streams). Even Stream IDs kiske hote hain? ::: Server ke (pushed streams). Default max frame payload bytes mein? ::: 16384 ($2^{14}$). HPACK ke teen mechanisms? ::: Static table, dynamic table, static Huffman coding. HTTP/2 kaun sa HOL blocking abhi bhi suffer karta hai? ::: Transport-layer (TCP in-order delivery). Server push ka modern replacement? ::: 103 Early Hints + link rel=preload.