HTTP/1.1 vs HTTP/2

1. What Is It?

HTTP/1.1 and HTTP/2 are two versions of the HTTP protocol that define how browsers and servers exchange data. HTTP/1.1 (standardized in 1997) is text-based and handles one request at a time per connection. HTTP/2 (standardized in 2015) is a binary protocol that multiplexes many requests over a single connection, adds header compression, and enables server push.

The performance gap matters in practice: HTTP/1.1 forces browsers to open 6–8 parallel TCP connections per domain to work around its single-request limitation. HTTP/2 eliminates this need with a single multiplexed connection, reducing latency and connection overhead especially over HTTPS where each TCP connection requires a TLS handshake.

2. How It Works

HTTP/1.1 Limitations

HTTP/1.1 is a text protocol with a strict request-response model. A single TCP connection handles one request at a time (unless pipelining is used, which most servers and browsers disabled due to head-of-line blocking bugs). To parallelize requests, browsers open multiple connections.

Common HTTP/1.1 workarounds developers used:

• Domain sharding — split assets across static1.example.com, static2.example.com to get more parallel connections.
• CSS/JS bundling — combine files to reduce request count.
• Sprite sheets — combine images into one to save requests.
• Inlining — embed small CSS/JS/images in HTML directly.

All of these are hacks to work around HTTP/1.1's connection limitations. HTTP/2 makes most of them unnecessary.

HTTP/2 Key Features

Multiplexing: Multiple request/response pairs are interleaved on one TCP connection using streams. Each stream has an ID; frames from different streams are interleaved and reassembled at the other end.

-+ResetFullscreen

Header Compression (HPACK): HTTP/1.1 headers are sent as plain text with every request. A typical request header block is 500–1000 bytes. HPACK maintains a shared compression table between client and server, sending indices into that table rather than repeated full strings. Significant wins for APIs that send large Authorization or Cookie headers repeatedly.

Stream prioritization: Clients can assign weights and dependencies to streams, telling the server which responses matter most (e.g., critical CSS before images). Servers can use this to schedule responses.

Server push: The server can proactively send resources the client hasn't requested yet (e.g., send /style.css while the client is still parsing the HTML). In practice, server push has complex interaction with browser caches and was largely deprecated by major browsers — don't rely on it.

Binary framing: HTTP/2 frames data in binary rather than text. This eliminates ambiguous parsing edge cases in HTTP/1.1 but means HTTP/2 traffic is not human-readable in a terminal without tools.

3. What SDEs Actually Need to Know

Negotiation is automatic: Modern browsers and servers negotiate HTTP/2 via ALPN (Application-Layer Protocol Negotiation), a TLS extension exchanged during the TLS handshake. If both sides support HTTP/2, it's used automatically. You don't add HTTP/2 to your code; you configure it in your web server or load balancer.

HTTP/2 requires HTTPS in practice: The spec doesn't mandate TLS, but all major browsers only implement HTTP/2 over TLS. If you're terminating TLS at a load balancer, configure HTTP/2 there.

H2 between a load balancer and backend: Most LBs (nginx, AWS ALB) can accept HTTP/2 from clients but forward to backends over HTTP/1.1. This is common and fine for most cases. If you want end-to-end HTTP/2 (useful for gRPC), you need to configure it explicitly.

gRPC uses HTTP/2 exclusively: gRPC is built on HTTP/2. It requires HTTP/2's multiplexing for bidirectional streaming and uses it for all communication — single connection, multiple concurrent RPCs, full-duplex. If gRPC connections are failing or falling back, HTTP/2 negotiation failure is a common cause.

HTTP/1.1 connection pooling vs. HTTP/2: With HTTP/1.1, you need a pool of connections to parallelize requests. With HTTP/2, a single connection handles parallelism. But the optimal pool size changes: with HTTP/2, 1–2 connections per host is usually enough; with HTTP/1.1, you need 6+ for similar throughput.

Head-of-line blocking still exists in HTTP/2: HTTP/2 eliminates HTTP-level head-of-line blocking (multiple requests no longer wait for one to finish). But TCP-level head-of-line blocking remains — a lost TCP segment blocks all HTTP/2 streams on that connection. HTTP/3 (QUIC) solves this at the transport layer.

4. Tradeoffs & Decisions

When HTTP/2 wins clearly:

• Browser-to-server for web pages with many assets (CSS, JS, images).
• gRPC and streaming APIs.
• High-latency connections where handshake overhead is significant.
• Clients with large repeated headers (APIs with JWT tokens in every request).

When HTTP/1.1 may still be appropriate:

• Simple internal service-to-service APIs with low request concurrency per connection — the complexity gain may not be worth it.
• Debugging: HTTP/1.1 is human-readable; you can telnet or curl --http1.1 and read raw traffic. HTTP/2 binary framing requires tools (nghttp2, Wireshark with HTTP/2 support).
• Legacy proxies and tools that don't support HTTP/2.

Migrating to HTTP/2: Enable it in your web server / LB config (nginx: listen 443 ssl http2;). Test with curl -I --http2 https://yourdomain.com and check for HTTP/2 200 in the response. Revisit your bundling strategy: with HTTP/2, many small files can be more efficient than one large bundle (browser can cache individual files granularly).

5. Interview Cheat Sheet

Key sentences:

• "HTTP/2 multiplexes multiple requests over one TCP connection using binary frames and stream IDs, eliminating the 6-connection-per-domain hack browsers use with HTTP/1.1."
• "HTTP/2 uses HPACK to compress headers; a 1000-byte Authorization header sent 100 times becomes ~1 byte on the 2nd–100th request."
• "HTTP/2 head-of-line blocking is solved at the HTTP layer but not at TCP — a lost packet still stalls all streams. HTTP/3 (QUIC/UDP) fixes this."
• "gRPC requires HTTP/2; if your load balancer doesn't support h2 backend connections, gRPC streams won't work end-to-end."

Common follow-ups:

Q: Does HTTP/2 eliminate the need for CDNs? A: No. HTTP/2 reduces per-request overhead and improves parallelism, but it doesn't reduce geographic distance. A CDN cache 10ms from the user is faster than an origin server 150ms away regardless of HTTP version. HTTP/2 and CDNs are complementary.

Q: How is HTTP/3 different from HTTP/2? A: HTTP/3 replaces the TCP transport with QUIC, which runs over UDP. QUIC implements reliability, multiplexing, and encryption in userspace per stream — so a lost packet only affects its own stream, not all concurrent streams. HTTP/3 also reduces connection setup to 0–1 RTTs (vs. 2–3 for TCP+TLS) for known hosts.

Q: What's the impact on server push? A: HTTP/2 server push allowed the server to proactively send resources. In theory this sounds great; in practice it often sent resources the browser already had cached, wasting bandwidth. Chrome removed support for HTTP/2 server push in 2022. For preloading, <link rel="preload"> in HTML is the recommended alternative.