HTTP/1.1 vs HTTP/2: What Changed?
Learn the real differences between HTTP/1.1 and HTTP/2 — multiplexing, HPACK compression, and why sharding stops helping.
Expected Interview Answer
HTTP/2 replaces HTTP/1.1’s text-based, one-request-per-connection-slot model with a single binary-framed connection that multiplexes many concurrent request/response streams, eliminating head-of-line blocking at the HTTP layer and removing the need for domain sharding.
HTTP/1.1 sends plain-text requests and typically opens several TCP connections per origin (browsers cap this around six) to work around the fact that one connection can only have one request in flight without pipelining, and pipelining was rarely usable because a slow response still blocked everything behind it. HTTP/2 introduces binary framing, splitting messages into frames tagged with a stream ID, so many logical streams share one TCP connection and interleave freely — a slow response no longer blocks an unrelated fast one at the HTTP layer. It also adds header compression via HPACK, which removes the redundant plain-text header overhead HTTP/1.1 resends on every request, and server push, which lets a server proactively send resources it knows the client will need. Because HTTP/2 multiplexes efficiently over one connection, techniques from the HTTP/1.1 era like domain sharding and file concatenation actually become counterproductive.
- Multiplexed streams over one TCP connection remove HTTP-layer head-of-line blocking
- HPACK header compression cuts redundant repeated header bytes
- Server push lets the server proactively send resources before they are requested
- Removes the need for legacy HTTP/1.1 workarounds like domain sharding
AI Mentor Explanation
HTTP/1.1 is like a single narrow tunnel to the practice nets where only one player bowls at a time, so a slow bowler holds up everyone queued behind him even if the next player is ready instantly. HTTP/2 is like opening one wide net complex where every bowler gets a lane and bowls simultaneously, tagged by lane number so deliveries never get mixed up. A slow bowler in lane three no longer stops a fast bowler in lane one from finishing early. That parallel-lanes-on-one-facility model is exactly how HTTP/2 multiplexing removes head-of-line blocking that plagued HTTP/1.1.
Step-by-Step Explanation
Step 1
HTTP/1.1 opens multiple connections
Browsers open several TCP connections per origin because one connection serializes requests without usable pipelining.
Step 2
HTTP/2 negotiates a single connection
Client and server negotiate HTTP/2 (often via ALPN during TLS) and use one persistent TCP connection per origin.
Step 3
Messages are split into binary frames
Requests and responses are broken into frames tagged with a stream ID, allowing interleaving on the wire.
Step 4
Streams multiplex and headers compress
Many streams progress concurrently over the one connection, with HPACK shrinking repeated header bytes across requests.
What Interviewer Expects
- Clear explanation of HTTP-layer head-of-line blocking in HTTP/1.1
- Understanding of binary framing and stream multiplexing in HTTP/2
- Mention of HPACK header compression and its benefit
- Awareness that HTTP/1.1 optimizations like domain sharding become counterproductive under HTTP/2
Common Mistakes
- Claiming HTTP/2 eliminates all head-of-line blocking (TCP-layer blocking can still occur)
- Confusing HTTP/2 server push with WebSockets or Server-Sent Events
- Not knowing HTTP/2 still requires TLS in virtually all real deployments (via browser policy)
- Forgetting that HTTP/2 is binary, not human-readable like HTTP/1.1
Best Answer (HR Friendly)
“HTTP/1.1 sends requests mostly one at a time per connection, so browsers open several connections to load a page faster, and a slow response can still hold things up. HTTP/2 sends everything over one smarter connection where many requests travel at the same time without blocking each other, and it also compresses repeated headers, so pages generally load faster.”
Code Example
const entries = performance.getEntriesByType('resource')
for (const entry of entries) {
// 'h2' indicates HTTP/2, 'http/1.1' indicates HTTP/1.1
console.log(entry.name, entry.nextHopProtocol)
}
// Server-side (Node.js) HTTP/2 server sketch
const http2 = require('node:http2')
const server = http2.createSecureServer({ key, cert })
server.on('stream', (stream, headers) => {
stream.respond({ ':status': 200, 'content-type': 'text/plain' })
stream.end('Hello over HTTP/2')
})Follow-up Questions
- What is TCP-layer head-of-line blocking and why can it still affect HTTP/2?
- How does HPACK header compression differ from gzip on the body?
- Why did domain sharding help under HTTP/1.1 but hurt under HTTP/2?
- How does HTTP/2 server push differ from a client just prefetching resources?
MCQ Practice
1. What is the main mechanism HTTP/2 uses to avoid HTTP-layer head-of-line blocking?
HTTP/2 interleaves independently tagged streams over a single connection so one slow stream does not block others.
2. What does HPACK do in HTTP/2?
HPACK is a header-specific compression scheme that avoids resending identical headers on every request.
3. Why does domain sharding lose its benefit under HTTP/2?
Since one HTTP/2 connection already handles many concurrent streams, extra connections from sharding add setup cost without added benefit.
Flash Cards
What does HTTP/2 add over HTTP/1.1? — Binary framing, stream multiplexing over one connection, and HPACK header compression.
Why did browsers open multiple connections under HTTP/1.1? — One connection largely serialized requests, so parallel connections worked around that.
What still can cause blocking in HTTP/2? — TCP-layer head-of-line blocking from packet loss, even though HTTP-layer blocking is solved.
What legacy optimization hurts under HTTP/2? — Domain sharding, since it fragments a connection that HTTP/2 already multiplexes efficiently.