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

False. Ye application-layer HOL hata deta hai (streams ek doosre ka HTTP mein wait nahi karte), lekin single TCP connection ab bhi bytes in-order deliver karta hai, isliye ek lost packet saare streams ko stall kar deta hai — transport-layer HOL. HTTP-3-and-QUIC woh fix karta hai.

False. Semantics HTTP-1.1 se identical hain; sirf wire format (text ki jagah binary framing) badla hai. 200 OK ka matlab ab bhi same hai.

False. HTTP/1.1 ko parallelism fake karne ke liye ~6 connections chahiye the; HTTP/2 ek connection chahta hai taaki ek single warmed-up congestion window mile aur chhe ki jagah ek hi TCP+TLS handshake ho.

False. Gzip attacker-controlled aur secret bytes ko mix karta hai, aur uski output length secrets leak karti hai (CRIME-and-BREACH-attacks). HPACK ek static/dynamic index table plus ek fixed Huffman-Coding table use karta hai, us adaptive context-mixing se bachte hue.

False. Clients odd IDs use karte hain, servers even IDs use karte hain, isliye same connection pe dono ID spaces kabhi collide nahi karte.

False. Agar server ek aisi resource push kare jo browser ne already cache kar rakhi hai, toh bandwidth waste hoti hai aur real HTML ka congestion window chura liya jaata hai. Mis-tuned push aksar nuksan karta tha, isliye Chrome ne ise drop kar diya.

False. 24-bit Length field $2^{24}-1$ bytes tak allow karta hai, lekin default maximum $2^{14}=16384$ hai taaki koi single frame link ko monopolize na kare.

False. Dynamic table per-connection hoti hai; encoder aur decoder dono apni-apni copy maintain karte hain jo us ek connection pe headers dekhe jaane par evolve hoti hai.

False. HPACK ek fixed, spec-defined Huffman code use karta hai jo typical HTTP header characters ke liye optimize hai. Static hona hi ise CRIME-resistant banata hai, adaptive coding ke unlike.

False. Ye wahi 7-bit continuation idea hai jo Varint-encoding aur kaafi binary protocols mein use hota hai — chhote numbers inline fit ho jaate hain, bade ones continuation bytes mein spill karte hain jinka high bit matlab hai "aur aane wale hain".

Galat frame aur stream. Server pehle client ke stream par ek PUSH_PROMISE bhejta hai ek naya even stream ID reserve karne ke liye, phir us naye stream par pushed resource ke liye HEADERS+DATA deliver karta hai.

Galat pattern. Ek akela leading 1 bit fully indexed representation mark karta hai. 01 prefix literal with incremental indexing mark karta hai (ek naya header yaad rakhne ke liye).

Top bit ek reserved (R) bit hai, chooser nahi. Odd/even sirf 31-bit ID value ki parity hai — clients odd choose karte hain, servers even choose karte hain.

Galat. $10<2^5-1=31$, isliye ye seedha 5 bits mein 0b01010 fit ho jaata hai. Tum $31$ tabhi pehle emit karte ho jab value prefix overflow kare.

Ek message (ek request ya response) ek HEADERS frame plus zero ya zyada DATA frames hota hai, sab ek hi Stream ID share karte hue. Ye generally kaafi frames hote hain.

Khatara algorithm se nahi balki length-based leakage se hai jab secret aur attacker-influenced data ek saath compress hote hain; HPACK ka design (static table pe indexing) asli fix hai, alag se compress karna nahi.

Taaki kaafi messages ek connection par interleave ho sakein — labeled chunks (Stream ID se) ek slow response ko wire yield karne dete hain ready walon ko, application-layer HOL blocking khatam kar ke.

Kisi bhi single frame ko shared connection monopolize karne se rokne ke liye; chhote frames interleaving ko fair rakhte hain taaki koi stream doosron ko starve na kare.

Sabse common headers (:method GET, :status 200, etc.) advance mein known hote hain, isliye inhe pehli request se hi ek single index byte ke roop mein bheja ja sakta hai — koi learning phase nahi chahiye.

Kyunki ek secret (cookie) ko attacker-chosen text ke saath compress karne par compressed length depend karti thi ki guess secret se kitna match kiya, ise byte by byte leak kar ke. Dekho CRIME-and-BREACH-attacks.

Ek connection matlab ek properly-warmed TCP congestion window jo bada rehta aur grow karta hai, chhe chhote cold windows ki jagah jo slow-start se restart karte hain.

Push blindly resources dobara bhejta hai jinhein browser cache kar chuka hota hai aur bandwidth ke liye compete karta hai; 103 Early Hints + <link rel=preload> browser ko decide karne deta hai kya fetch karna hai, waste se bachte hue.

Saare das streams tab tak stall ho jaate hain jab tak TCP us packet ko retransmit na kare, kyunki TCP in-order byte delivery guarantee karta hai — yahi transport-level HOL hai jo HTTP-3-and-QUIC remove karta hai.

Ye ek literal without indexing (ya never-indexed) representation use karta hai — Huffman-encoded bheja jaata hai lekin dynamic table mein add nahi hota, taaki table space waste na ho ya index hone ka risk na ho.

Entries oldest-first evict hoti hain negotiated size limit ke andar rehne ke liye; kisi entry ko evict karna sirf itna matlab hai ki us header ki agli occurrence phir literal ke roop mein bheji jaayegi.

Client pushed (even) stream par RST_STREAM bhej ke use cancel kar sakta hai — lekin in-flight frames par already kharch bandwidth waste ho jaati hai, ek kaaran push favor se bahar ho gaya.

Nahi. Rule hai if I < 2^N - 1 inline fit hota hai; $I=2^N-1$ overflow path trigger karta hai: prefix mein $2^N-1$ store karo, phir ek single continuation byte mein $0$.