Side by side
| Dimension | HTTP/1.1 | HTTP/2 |
|---|---|---|
| Wire format | Text-based headers and message framing | Binary frames grouped into streams |
| Concurrency | Usually multiple connections | Multiple concurrent streams per connection |
| Connection reuse | Persistent connections supported | Persistent, multiplexed connections |
| Head-of-line blocking | Pipelined responses must stay ordered | Independent HTTP streams; TCP blocking remains |
| Headers | Repeated headers sent without HPACK | HPACK compression across requests |
| Flow control | TCP flow control; application buffering | Stream and connection flow control for data |
| Deployment | Broad legacy and tooling compatibility | Requires support on each protocol hop |
| Load balancing | Connection pools distribute concurrent work | L4 balancing can concentrate multiplexed work |
The differences that matter
Concurrency changes connection management. HTTP/1.1 supports persistent connections, but clients generally avoid pipelining and send one active request per connection. HTTP/2 interleaves frames from independent streams, so a slow response need not prevent another response from progressing. Stream concurrency limits still apply.
Multiplexing does not eliminate every shared bottleneck. Both protocols normally run over TCP, whose ordered delivery means a missing packet can delay later bytes. With HTTP/2, that delay can affect multiple streams sharing the connection. A connection failure also interrupts every active stream on it.
HTTP/2 compresses headers with HPACK, which can reduce repeated metadata for requests carrying cookies or authorization headers. This is separate from response-body compression. The benefit depends on request volume, header sizes, and connection reuse; it does not make a large media payload inherently smaller.
Protocol choice is per hop, not an end-to-end switch. A browser can use HTTP/2 to a CDN or reverse proxy while that proxy uses HTTP/1.1 to the origin. Browsers generally negotiate HTTP/2 over TLS using ALPN. At a service boundary, check upstream protocol support, stream limits, buffering, and whether balancing happens per connection or per request.
Choose HTTP/1.1 when
- A required client, upstream service, or intermediary lacks reliable HTTP/2 support.
- The workload has low concurrency or mostly sequential requests, and persistent HTTP/1.1 connections already meet latency and resource goals.
- An existing HTTP/1.1 deployment meets its SLOs, and measurements do not justify the operational cost of changing it.
- You need a compatibility fallback while rolling out HTTP/2 at the edge or between services.
Choose HTTP/2 when
- Clients fetch many independent resources or make concurrent API calls to the same origin.
- Repeated request headers are substantial, making HPACK compression useful.
- High-concurrency service calls would otherwise require large HTTP/1.1 connection pools, and the infrastructure supports HTTP/2 correctly.
- You are using standard gRPC transport, which relies on HTTP/2 streams and framing.
A worked example
A gallery page with many thumbnail requests
Suppose a gallery page fetches 60 thumbnails from one origin over an 80 ms round-trip path. With an HTTP/1.1 client configured for six connections and no pipelining, only six requests can be active at once. With HTTP/2 and a negotiated limit of at least 60 concurrent streams, the client can send all 60 requests without waiting for earlier responses to finish. That can reduce request queuing, but it does not multiply available bandwidth or remove image-generation time. Packet loss can still stall the shared TCP connection. In an interview, also verify whether the CDN fetches origin images over HTTP/2 or a separate HTTP/1.1 pool.
In the interview
- Start with the traffic shape: concurrent requests per client, payload sizes, network latency, and streaming requirements. Do not promise a fixed speedup from a protocol upgrade.
- Draw the client-to-edge and edge-to-origin hops separately. State the protocol, TLS termination point, and connection-pool ownership on each hop.
- Explain both kinds of blocking: HTTP/1.1 pipelined response ordering and TCP-level blocking that still affects HTTP/2. Expect a follow-up about how HTTP/3 changes transport-level blocking.
- Discuss stream limits, flow-control windows, and bounded queues. Multiplexing is not admission control, so servers still need request limits, deadlines, and load shedding.
- Explain the load-balancing unit. An L4 balancer cannot redistribute streams within an established connection; an HTTP/2-aware L7 proxy can route requests across upstreams. Expect questions about connection draining, retries, and idempotency.
Common mistakes
- Saying HTTP/1.1 opens a new TCP connection for every request. Persistent connections are supported and commonly reused.
- Claiming HTTP/2 eliminates head-of-line blocking entirely. It removes HTTP response-order blocking between streams, not TCP's ordered-delivery constraint.
- Assuming enabling HTTP/2 at a CDN or load balancer automatically enables it on origin connections.
- Treating one multiplexed connection as unlimited capacity, or assuming fewer connections always produce lower latency.
Where it comes up
Interview questions where choosing between HTTP/1.1 and HTTP/2 comes up.
- Design InstagramConcurrent thumbnail delivery makes client-to-CDN multiplexing and separate origin connection pools relevant.
- Design a web crawlerCrawler workers must manage per-origin connection pools and HTTP/2 stream concurrency while preserving politeness limits.
- Design a video streaming service like YouTubeCDN delivery requires distinguishing protocol overhead from media bandwidth and checking client-to-edge versus edge-to-origin behavior.
- Design a distributed tracing systemAn HTTP/2-based gRPC ingestion path requires explicit stream limits, backpressure, and balancing across collector connections.
Questions people ask
Is HTTP/2 always faster than HTTP/1.1?
No. HTTP/2 often helps with concurrent requests and repeated headers, but gains depend on latency, packet loss, payload sizes, and server behavior. A single large download or sequential API workload may gain little from multiplexing.
Does HTTP/2 require HTTPS?
The protocol supports cleartext operation, commonly called h2c, but browsers generally use HTTP/2 only over TLS. For browser-facing designs, assume HTTPS with ALPN negotiation. Internal cleartext deployments require explicit support from clients, servers, and intermediaries.
Can REST APIs use HTTP/2, or is it only for gRPC?
REST APIs can use HTTP/2 without changing their resource model or HTTP methods. HTTP/2 changes transport framing and connection behavior, not REST semantics. Standard gRPC uses HTTP/2, but using HTTP/2 does not make an API gRPC.