One Connection to Rule Them All
HTTP/2, standardized in 2015 (based on Google's SPDY protocol), addressed the primary flaw of HTTP/1.1 by introducing multiplexing — the ability to send multiple requests and receive multiple responses simultaneously over a single TCP connection.
The key insight is a change in how data is structured. HTTP/1.1 sends requests and responses as plain text messages, one after another. HTTP/2 breaks every request and response into small binary chunks called frames. Each frame is tagged with a stream ID — a number identifying which request/response it belongs to. The connection then interleaves frames from many different streams, sending a frame for stream 1, then a frame for stream 7, then stream 3, and so on. The receiving end reassembles them by stream ID.
Returning to the diner analogy: HTTP/2 is like a waiter who carries a tray with items from ten different tables simultaneously, delivering each item as it's ready rather than completing one table's entire order before moving to the next.
The practical result: a browser can issue all 100 resource requests at once over a single TCP connection. A slow image download no longer blocks a tiny CSS file from arriving. Connection setup overhead (TCP handshakes, TLS negotiation) happens once instead of dozens of times.
HTTP/1.1 (6 connections, sequential per connection):
Conn 1: [Request A]----[Response A][Request G]----[Response G]
Conn 2: [Request B]----[Response B][Request H]----[Response H]
...
HTTP/2 (1 connection, multiplexed):
Stream 1: [Req A frames]...[Resp A frames]
Stream 2: [Req B frames]...[Resp B frames]
Stream 3: [Req C frames]...[Resp C frames]
All interleaved over a single TCP connection
HTTP/2 is also a binary protocol, not a text protocol. This makes it more efficient to parse (computers process binary faster than text) but less human-readable. Tools like Wireshark or browser DevTools handle the translation for debugging.
Interviewers often ask: "Does HTTP/2 eliminate the need for multiple connections?" The answer is yes, by design — and this is actually a behavioral change worth knowing. HTTP/2 also introduces stream prioritization, allowing clients to signal that certain resources (e.g., render-blocking CSS) should be delivered before others (e.g., below-the-fold images). Ask a candidate how they'd verify HTTP/2 is active in production: the answer is curl --http2 -I https://example.com and checking for HTTP/2 200 in the response, or inspecting the Protocol column in Chrome DevTools Network tab.