HTTP 1.1 vs 2 vs 3: The Evolution
Here’s a question that shaped the entire modern web: Why does a page with 100 small CSS/JS files load 10x slower than a page with 1 bundled file, even on a fast connection? In the early 2010s, Twitter, LinkedIn, and Google answered this question — and their findings led directly to the creation of HTTP/2. Then in 2019, a single insight from Google changed everything again: “What if we replaced TCP entirely?” — and HTTP/3 was born.
Every HTTP version upgrade solved a real, measurable bottleneck that was costing companies millions in server costs and user attention. Understanding why each version exists tells you more about distributed systems than any textbook.
[!IMPORTANT] In this lesson, you will master:
- The Protocol Waterfall: How Binary Framing in HTTP/2 and QUIC in HTTP/3 eliminated layers of latency — and the exact problem each solved.
- 0-RTT and its Replay Attack Risk: How QUIC sends data before the handshake finishes, and how to mitigate security vulnerabilities.
- QPACK vs HPACK: Why HTTP/3 needed a new compression algorithm to solve “Dynamic Table Deadlocks”.
1. HTTP/1.1: The Standard (1997-2015)
The workhorse of the web.
- Keep-Alive: Reuses the TCP connection.
- Text Based: Headers are ASCII (
User-Agent: Chrome). - The Flaw: Head-of-Line (HOL) Blocking.
- It’s like a grocery store with one lane.
- If the customer in front buys 100 items (Large Image), you (Small CSS) wait.
- (Note: Optimizing headers here is key for CDN performance).
- Hack: Browsers open 6 parallel TCP connections to the same server to overcome this limit.
2. HTTP/2: The Multiplexer (2015)
Google’s SPDY project became HTTP/2. It solved the “Application Layer HOL Blocking” by moving away from text-based requests.
A. Binary Framing Layer
Unlike HTTP/1.1 which sends ASCII text (GET /index.html HTTP/1.1), HTTP/2 breaks communication into tiny Binary Frames.
Binary Frame Explorer (9-Byte Header)
B. Multiplexing: The “Magic Conveyor Belt”
- It splits data into frames.
- It interleaves Frame 1 of Image, Frame 1 of CSS, Frame 2 of Image… on a single TCP connection.
- No more Application-Layer HOL Blocking.
C. HPACK: Header Compression
HTTP headers are redundant. Every request sends User-Agent, Cookie, Accept-Encoding.
HPACK uses two tables:
- Static Table: Pre-defined list of 61 common headers (e.g.,
:method: GET,:status: 200). - Dynamic Table: Remembers headers specific to this connection. If you send a 1KB cookie once, HPACK assigns it an ID. Next time, you only send the ID.
Interactive Demo: HPACK Savings
Send multiple requests and watch the Dynamic Table learn.
| ID | Header Record |
|---|
[!WARNING] Server Push: HTTP/2 introduced “Server Push” (Server sends CSS before you ask). It failed in practice because Servers didn’t know if the Browser already had the file in Cache. Chrome removed support for it in 2020.
Load Performance: H1.1 vs H2
D. System Walkthrough: An HTTP/2 Frame Stream
How does the server send style.css and script.js at the same time on one connection?
It slices them into frames and interleaves them.
The Stream:
- Frame 1 (Stream 5):
HEADERS(Status: 200, Content-Type: text/css) - Frame 2 (Stream 7):
HEADERS(Status: 200, Content-Type: application/javascript) - Frame 3 (Stream 5):
DATA(“body { color: red…”). - Frame 4 (Stream 7):
DATA(“console.log(‘Hello’…”). - Frame 5 (Stream 5):
DATA(“… }”) +END_STREAM.
The browser reassembles Stream 5 into style.css and Stream 7 into script.js.
E. The Handshake Upgrade: ALPN
How does the Client know if the Server supports HTTP/2? It happens during the TLS Handshake via ALPN (Application-Layer Protocol Negotiation).
- Client Hello: “I support TLS 1.3. I can speak
h2(HTTP/2) orhttp/1.1.” - Server Hello: “Let’s use
h2.”
3. HTTP/3: The Rebel (2020+)
HTTP/3 dumps TCP entirely and builds on UDP. It implements its own reliability layer called QUIC.
Why UDP?
TCP is implemented in the OS Kernel. Updating it takes years (waiting for OS updates like Windows/Linux). QUIC lives in “User Space” (the App/Browser), so it updates instantly.
Feature A: 0-RTT (Zero Round Trip Time)
The most significant speed boost in HTTP/3 is the ability to send data on the very first packet.
- TCP + TLS: Requires 2-3 round trips (SYN, SYN-ACK, ClientHello…) before data flows.
- QUIC 0-RTT: If the client has connected to the server before, it reuses the previous session keys and sends the HTTP Request along with the initial Handshake Packet.
- Risk: Replay Attacks. A hacker could intercept the 0-RTT packet and send it again. This is why 0-RTT is typically only used for “Safe” methods (GET) and not for payments or login.
Feature B: True Parallelism (No HOL Blocking)
In QUIC, streams are independent. If Stream A loses a packet, Stream B keeps going. This is critical for Real-Time Gaming where latency is king.
Feature C: Connection Migration (The Killer Feature)
- Scenario: You are on WiFi downloading a file. You walk out the door and switch to 4G.
- TCP: Your IP Address changes. The socket is defined by
(SrcIP, SrcPort, DstIP, DstPort). The tuple breaks. Connection Dead. Re-handshake. - QUIC: Uses a Connection ID (CID) (e.g., UUID
a1b2c3d4). Even if your IP changes, the Server sees the same CID and accepts the packet. The download continues seamlessly.
Feature D: QPACK (The Out-of-Order Hero)
Remember HPACK? It relies on strict ordering. If Packet 1 (adding a header) is lost, Packet 2 cannot be decoded. In TCP, this is fine because TCP waits. In UDP, Packet 2 arrives before Packet 1 is retransmitted.
- The Solution: QPACK. It uses a separate “Control Stream” to synchronize the header table.
- If a packet arrives and it needs a header from the dynamic table that hasn’t arrived yet, QPACK only blocks that specific stream, not the whole connection.
Feature E: Security & 0-RTT Replay Mitigation
While 0-RTT is blazing fast, it is vulnerable to Replay Attacks.
- The Attack: A hacker captures your 0-RTT packet (
POST /transfer-money) and resends it 100 times. - The Mitigation:
- Idempotency: Servers should only allow 0-RTT for GET/HEAD requests.
- Strict Handshake: Servers use a
tokenin the 0-RTT packet to verify it was generated recently.
4. Interactive Demo: Connection Migration (The “Parking Lot”)
Experience Connection Migration. You are downloading a large file.
- Click “Start Download” (on WiFi).
- Mid-download, click “Switch Network” (to 4G).
- Watch TCP fail and restart. Watch QUIC keep going.
H2 vs H3: Connection Migration Test
5. Comparison Summary & Decision Guide
| Feature | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| Transport | TCP (Cleartext) | TCP (Encrypted) | UDP (QUIC, Encrypted) |
| Parallelism | 6 Connections | 1 Connection (Multiplexed) | 1 Connection (Independent Streams) |
| Headers | Text (Bloated) | HPACK (Compressed) | QPACK (Compressed) |
| HOL Blocking | App Layer | TCP Layer | None |
| Network Switch | Connection Reset | Connection Reset | Seamless Migration |
| When to use | Legacy systems | Most modern APIs | Mobile, real-time, gaming |
Memory trick: Think of evolution as a tunnel analogy. HTTP/1.1 = one car at a time. HTTP/2 = multiple lanes in the same tunnel. HTTP/3 = replaced the tunnel with an open highway (no HOL blocking).
6. Real-World Deployment: Alt-Svc
How does a server tell a client to stop using HTTP/2 and try HTTP/3?
- The Alt-Svc Header: The server sends a response header:
Alt-Svc: h3=":443"; ma=86400. - The Cache: The browser remembers this for 24 hours (ma=86400). Next time you visit, it attempts a QUIC connection immediately.
Staff Engineer Tip: HTTP/3 Adoption Strategy. Don’t blindly upgrade all traffic to HTTP/3 — measure first. HTTP/3 shines in two specific scenarios: (1) Mobile/lossy networks where QUIC’s per-stream recovery means one dropped video frame doesn’t stall your chat stream. (2) Multi-region APIs where Connection Migration saves re-handshake round trips on network switches. For stable data-center-to-data-center traffic on 10Gbps fiber with near-zero loss, HTTP/2 is already optimal.