We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Api Design Protocols
Free preview: the first 2 parts of this 8-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Api Design Protocols
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
/1.1 has a fundamental problem: one request at a time per connection. If you send a request for a JavaScript file and it takes 500ms, the next request (for a CSS file) waits 500ms before it even starts. This is called head-of-line blocking.
Browsers work around this by opening 6 connections per domain. But 6 connections means 6 handshakes, 6 TLS negotiations, and a hard ceiling on parallelism. Developers invented workarounds: domain sharding (serve images from img1.cdn.com, img2.cdn.com to get 12 connections), CSS sprites (combine images into one file), JavaScript bundling (combine scripts into one file). All because HTTP/1.1 could not handle multiple requests efficiently.
HTTP/2, published as RFC 7540 in May 2015, solved this. One connection, unlimited concurrent requests. Each request is a "stream" with its own ID, an independent, bidirectional sequence of frames multiplexed over the same TCP connection. No more head-of-line blocking at the application layer. No more domain . No more workarounds.
Google developed the initial protocol as SPDY in 2009, deployed it across all Google services by 2012, and then contributed it to the IETF to become HTTP/2. By 2016, most major browsers supported it. Today, over 65% of all websites serve traffic over HTTP/2.
/1.1 (sequential on each connection):
Connection 1: GET /page.html ──────> response ──> GET /style.css ──────> response
Connection 2: GET /app.js ──────────> response ──> GET /logo.png ────────> response
HTTP/2 (multiplexed on one connection):
Connection 1 (single TCP):
Stream 1: GET /page.html ─frame─frame─frame─>
Stream 3: GET /style.css ──frame─frame─>
Stream 5: GET /app.js ───frame─frame─frame─frame─>
Stream 7: GET /logo.png ─frame─frame─>
(all interleaved on the same connection)
Key HTTP/2 features:
| Feature | What It Does | Impact |
|---|---|---|
| Multiplexing | Multiple requests/responses on one connection | Eliminates connection limit workarounds |
| Header compression (HPACK) | Compresses headers with a static/dynamic table | 90% reduction in header overhead |
| Stream prioritization | Client hints which resources are most important | CSS loads before analytics scripts |
| Server push | Server proactively sends resources before requested | Deprecated in Chrome 2022 |
| Binary framing | All communication is binary frames, not text | Faster parsing, no ambiguity |
Header compression matters. In HTTP/1.1, every request sends cookies, user-agent, accept headers, often 500-800 bytes of the same headers repeated on every request. HPACK compresses headers by referencing a shared table of common headers and sending only the differences. For API calls with identical headers, compression can reduce header overhead by 90%. Cloudflare measured an average of 30% total bandwidth savings from HPACK alone across their .
Stream IDs. Client-initiated streams use odd numbers (1, 3, 5, 7). Server-initiated streams (push) use even numbers (2, 4, 6). Stream 0 is the control stream for connection-level frames (SETTINGS, WINDOW_UPDATE, GOAWAY). This numbering scheme prevents ID collisions without coordination.