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

1. WHY HTTP/2 exists — the HTTP/1.1 pain

WHAT changed in HTTP/2:

Text → binary framing.
6 connections → 1 connection, many streams.
Repeated headers → HPACK compression.
Pull-only → optional server push.

2. The framing layer (the foundation of everything)

Formula Frame header (9 bytes, fixed)

$\text{Frame} = \underbrace{24\text{ bits Length}}_{\le 2^{14}\text{ default}} + \underbrace{8\text{ bits Type}}_{} + \underbrace{8\text{ bits Flags}}_{} + \underbrace{1\text{ bit R}}_{} + \underbrace{31\text{ bits Stream ID}}_{}$

WHY these sizes? 24-bit length lets one frame carry up to $2^{24}-1$ bytes, but the default max is $2^{14}=16384$ so no single frame monopolizes the link. 31-bit Stream ID (top bit reserved) gives ~2 billion stream IDs. Client streams use odd IDs, server-pushed streams use even IDs — so they never collide.

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

3. Multiplexing — HOW one connection carries many streams

HOW it works step by step:

Client opens stream 1: sends a HEADERS frame (Stream ID = 1).
Client opens stream 3: sends HEADERS (Stream ID = 3) — without waiting for response 1.
Server interleaves: DATA(1), DATA(3), DATA(1), HEADERS(3 response)... in any order.
Each side demultiplexes by Stream ID.

4. HPACK — header compression (the clever part)

HOW a header field is encoded — three cases:

Formula Prefix integer encoding (the trick that packs small numbers)

To encode integer $I$ in an $N$ -bit prefix:

\text{if } I < 2^N - 1:\ \text{store } I \text{ in the } N \text{ bits.}

\text{else: store } (2^N-1),\ \text{then } I' = I-(2^N-1) \text{ in 7-bit continuation groups:}

$\text{while } I' \ge 128:\ \text{emit } (I' \bmod 128) + 128;\quad I' \leftarrow \lfloor I'/128\rfloor;\ \ \text{emit } I'$

WHY: common small indices fit in the prefix (1 byte). Big ones spill into 7-bit continuation bytes where the high bit means "more bytes follow". This is the same varint idea used everywhere.

5. Server Push — HOW the server sends before you ask

HOW:

Server receives GET /index.html on stream 1.
Server sends PUSH_PROMISE on stream 1 promising /style.css on stream 2.
Server sends HEADERS+DATA for /style.css on stream 2.
When the parsing browser discovers it needs style.css, it's already in cache → no round trip.

6. Putting it together (forecast-then-verify)

Flashcards

HTTP/2 unit on the wire — what replaced HTTP/1.1 text lines?

Binary frames (9-byte header + payload); types like HEADERS, DATA, SETTINGS, PUSH_PROMISE.

Define a stream in HTTP/2.

An independent bidirectional sequence of frames sharing one Stream ID, multiplexed over a single connection.

Client streams use ___ IDs, server-pushed use ___ IDs.

Odd; even (so they never collide).

What kind of HOL blocking does HTTP/2 fix, and what kind remains?

Fixes application/HTTP-layer HOL; TCP-layer HOL (one lost packet stalls all streams) remains — solved by HTTP/3/QUIC.

Name HPACK's three compression mechanisms.

Static table (61 entries), per-connection dynamic table, Huffman coding of literals.

Why not just gzip headers?

Adaptive compression of attacker+secret data leaks secrets via length (CRIME); HPACK indexing/static-Huffman resists this.

What frame announces a server push and what ID does it reserve?

PUSH_PROMISE; it reserves an even Stream ID for the pushed response.

HPACK encode index 1337 in a 5-bit prefix.

Prefix=31, then 1337−31=1306 → bytes 31,154,10.

Why was server push deprecated in browsers?

Often pushed already-cached resources and competed for the congestion window; replaced by 103 Early Hints + preload.

Default max frame payload size and why limited?

16384 bytes (

2^{14}

); prevents one frame monopolizing the shared connection.

Recall Explain to a 12-year-old (Feynman)

Old internet: you mail one letter, wait for the reply, then mail the next — slow, and you waste the envelope's whole address block every time. HTTP/2 is like cutting every letter into small numbered cards and tossing them all down one tube at once; the other side sorts by number. It also keeps a shortcut list so repeated info ("from: you") becomes just "#5". And a smart helper can send you the homework pages it knows you'll need next, before you even ask. The only snag: if one card gets lost in the tube, everything waits for it to be resent — HTTP/3 builds separate tubes to fix that.

Connections

HTTP-1.1 — predecessor; text protocol and HOL blocking this fixes.
HTTP-3-and-QUIC — moves to UDP to remove TCP-layer HOL blocking.
TCP — single shared connection & congestion window; source of remaining HOL.
TLS — HTTP/2 in practice always runs over TLS (ALPN negotiates "h2").
Huffman-Coding — literal string compression inside HPACK.
CRIME-and-BREACH-attacks — why naive header gzip is unsafe.
Varint-encoding — same prefix-integer / 7-bit continuation idea.

Concept Map

Hinglish (regional understanding)

Intuition Hinglish mein samjho

Dekho, HTTP/1.1 ka problem yeh tha ki ek TCP connection pe ek time pe ek hi request-response chal sakti thi. Agar pehli file slow hai to baaki sab line mein khade intezaar karte the — isko head-of-line blocking kehte hain. Isliye browser 6 connections kholta tha, jo waste tha. HTTP/2 ne sab kuch binary frames mein convert kar diya: har request-response ko chote chote frames mein toda, har frame pe ek Stream ID ka label lagaya, aur ek hi connection pe sab streams ko interleave kar diya. Receiver label dekh ke reassemble kar leta hai. Isko multiplexing bolte hain.

HPACK header compression hai. Har request mein cookie, user-agent same repeat hoti hain, to inko baar baar bhejna fizool hai. HPACK ek static table (61 common headers fixed), ek dynamic table (connection ke dauran jo dikha use yaad rakho), aur Huffman coding use karta hai. Dusri baar wahi header bas ek index byte ban jati hai — 200 byte cookie, 1 byte mein. Important baat: normal gzip use nahi kiya kyunki usse CRIME attack se secret cookie leak ho jaata hai; HPACK design hi safe hai.

Server push mein server bina mange aapko resource bhej deta hai — jaise index.html maanga to style.css aur app.js pehle hi PUSH_PROMISE frame ke through bhej deta hai, taaki cache mein ready ho. Lekin yeh ulta nuksaan bhi kar sakta hai (already-cached cheez push karna, bandwidth waste), isliye browsers ne ise hata diya aur ab 103 Early Hints + preload use hota hai.

Ek catch yaad rakhna: HTTP/2 application-layer HOL blocking hatata hai, par TCP-layer HOL abhi bhi hai — ek packet lost hua to saare streams ruk jaate hain. Isi liye HTTP/3 (QUIC, UDP pe) aaya jahan har stream ki apni ordering hai. Yeh exam aur interview dono mein favourite question hai.

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

1. WHY HTTP/2 exists — the HTTP/1.1 pain

2. The framing layer (the foundation of everything)

3. Multiplexing — HOW one connection carries many streams

4. HPACK — header compression (the clever part)

5. Server Push — HOW the server sends before you ask

6. Putting it together (forecast-then-verify)

Flashcards

Connections

Concept Map

Hinglish (regional understanding)

Go deeper — visual, from zero

Test yourself — Computer Networks

Connections