Stage 3 · Build
HTTP, HTTP/2 & gRPC
HTTP/2 and HTTP/3
Multiplexing, header compression, server push, and QUIC/HTTP3.
Why HTTP/2 Exists
HTTP/1.1 has a fundamental performance problem: head-of-line blocking at the application layer. A browser can only use 6 connections per domain, and each connection handles one request at a time. HTTP/2 fixes this with binary framing and multiplexing.
| Feature | HTTP/1.1 | HTTP/2 |
|---|---|---|
| Wire format | Text | Binary |
| Multiplexing | No (6 conn limit) | Yes (unlimited streams) |
| Header compression | None (repeated) | HPACK |
| Server push | No | Yes (stream-based) |
| Priority | None | Stream priority |
| TLS | Optional | Required (practical) |
HTTP/2 breaks messages into binary frames. Frames from multiple requests can interleave on the same TCP connection. The receiver reassembles the frames into complete requests and responses. This eliminates head-of-line blocking at the HTTP layer.
Multiplexing and Streams
In HTTP/2, each request-response pair is a stream. Multiple streams share a single TCP connection. Frames from different streams are interleaved and reassembled at the other end. This means one slow response does not block others.
Single TCP Connection:
Stream 1 (GET /style.css): [Frame 1] [Frame 3] [Frame 5]
Stream 2 (GET /app.js): [Frame 2] [Frame 4] [Frame 6]
Stream 3 (GET /api/data): [Frame 7] [Frame 8]
All frames interleaved on one connection.
Receiver reassembles each stream independently.Multiplexing eliminates the need for domain sharding (spreading assets across multiple domains to parallelize downloads). One connection is enough. This also reduces TCP overhead and improves congestion control.
Header Compression (HPACK)
HTTP/1.1 sends the same headers (Host, Cookie, Accept) on every request — completely uncompressed. HPACK uses a static table of common headers and dynamic tables that learn headers during a connection. This typically reduces header overhead by 85-95%.
HTTP/1.1 request (uncompressed):
GET /api/users HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGci...
Accept: application/json
Cookie: session=abc123
Total header size: ~180 bytes (repeated every request)
HTTP/2 with HPACK:
Static table index 2 (:method: GET)
Static table index 4 (:path: /)
Dynamic table: :authority = api.example.com
Dynamic table: authorization = Bearer eyJhbGci...
Total header size: ~30 bytes (first request)
Subsequent requests: ~10 bytes (table references only)HPACK maintains a table of headers seen so far. On subsequent requests, only new or changed headers are sent. Common headers like :method and :scheme are referenced by index, taking 1-2 bytes instead of the full text.
Server Push
Server push lets the server send resources the client has not requested yet. If the server knows a client needs style.css after requesting index.html, it can push the CSS file proactively, eliminating a round trip.
Client: GET /index.html
Server: PUSH_PROMISE for /style.css
Server: PUSH_PROMISE for /app.js
Server: Response for /index.html
Server: Data frame for /style.css
Server: Data frame for /app.js
Client receives all resources without requesting them.In practice, server push has been removed from most browsers (Chrome removed it in 2022). It was complex to implement correctly — pushing resources the client already cached wasted bandwidth. HTTP/103 Early Hints is the replacement.
HTTP/3 and QUIC
HTTP/3 runs on QUIC instead of TCP. QUIC provides multiplexing without head-of-line blocking at the transport layer. If one stream loses a packet, other streams continue unaffected. QUIC also includes TLS 1.3 built-in and supports 0-RTT connection establishment.
| Feature | HTTP/2 (TCP) | HTTP/3 (QUIC) |
|---|---|---|
| Transport | TCP + TLS | QUIC (includes TLS 1.3) |
| Head-of-line blocking | TCP-level HOL | No transport HOL |
| Connection migration | No (IP:port tuple) | Yes (connection ID) |
| 0-RTT | No | Yes |
| Handshake | TCP + TLS = 2-3 RTT | 1 RTT (0-RTT resumed) |
# Check HTTP/2 support
curl -v --http2 https://example.com 2>&1 | grep "< HTTP"
# Check HTTP/3 support
curl -v --http3 https://example.com 2>&1 | grep "< HTTP"
# Check with openssl (ALPN negotiation)
echo | openssl s_client -connect example.com:443 -alpn h2,http/1.1 2>/dev/null | grep ALPNHTTP/3 requires QUIC support in both the client and server. If the server does not support HTTP/3, the client falls back to HTTP/2 over TCP. The Alt-Svc header advertises HTTP/3 availability.
QUIC uses connection IDs instead of IP:port tuples. When a mobile device switches from Wi-Fi to cellular (IP change), the QUIC connection survives without reconnecting. TCP connections would break and need to re-establish.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.