HTTP/2 Streams and Frames
HTTP/2 uses stream IDs and frames so many request/response conversations can share one TCP connection.
Many letters in one mail truck
HTTP/1 often felt like sending one delivery per truck. HTTP/2 is more like one truck carrying many envelopes. Each envelope has a stream number, so the receiver sorts them back into conversations.
Memorable label: “Stream numbers on envelopes.” A stream is the conversation. A frame is one envelope piece.
Six-year-old version: Put puzzle pieces from two puzzles in one bag, but write Puzzle 1 or Puzzle 3 on every piece. At home, sort pieces by number.
HTTP/2 is lesson 1 in web clothing
HTTP/2 does not send one giant request blob. It breaks communication into frames. Frames carry a stream identifier. The receiver uses the identifier to rebuild each stream. RFC 9113 defines streams and frames and says HTTP/2 allows multiplexing requests and responses over one connection (RFC 9113).
This solves “too many roads” for web requests, but remember Lesson 2: multiplexing still needs good scheduling. Also, because HTTP/2 commonly runs over TCP, TCP-level head-of-line blocking can still matter if a packet is lost.
Six-lane idea: HTTP/2 gives requests logical lanes, but those lanes still sit inside one TCP tunnel. QUIC and HTTP/3 move closer to independent lanes: loss in one stream does not have to block every other stream the same way.
Demo: two web streams, one TCP road
Send frames. Watch stream 1 and stream 3 rebuild independently.
HTTP/2 frame road
Rebuilt streams
| Stream | Frames | Payload |
|---|---|---|
| 1 | 0 | |
| 3 | 0 |
Exercise
node --test tests/http2-frames.test.mjs Open src/http2-frames.mjs. It is the same mechanism as Lesson 1, with HTTP/2 names: stream IDs and frames.
Knowledge check
Interview payoff
Question: “How does HTTP/2 multiplex requests?”
Model answer: “HTTP/2 breaks messages into frames. Each frame has a stream ID. Frames from different streams can be interleaved on one connection, and the receiver demultiplexes them by stream ID.”
Pro tip: HTTP/2 removes many HTTP/1 connection bottlenecks, but it does not repeal physics. Lost TCP packets can still delay later bytes.
Next challenge: What changes when the shared road carries real-time audio and video instead of web requests?