HTTP/2
HTTP/2 multiplexes many requests over one TCP connection using binary framing and header compression, removing head-of-line blocking at the application layer.
Definition
HTTP/2 is a binary, multiplexed revision of HTTP. Rather than one request per connection or serialised pipelining, it carries many concurrent streams over a single TCP connection, each frame tagged with a stream id. It compresses headers with HPACK, supports server push and stream prioritisation, and eliminates the per-request connection overhead that dominated HTTP/1.1. Its weakness is that all streams share one TCP connection, so a lost packet still stalls them together.
Context and scope
The default for HTTPS servers and CDNs today, adopted without application change because it negotiates via ALPN during TLS.
Common misconceptions
- HTTP/2 removes all head-of-line blocking — it removes it at the application layer; TCP-level loss still blocks all streams sharing the connection, which HTTP/3 addresses
- Domain sharding still helps — sharding was an HTTP/1.1 workaround; with HTTP/2 it fragments the connection and hurts multiplexing
- Server push is always beneficial — push sends resources the client may already have; it is often disabled or used narrowly
Anti-patterns
- Keeping many small domains purely for parallelism, defeating multiplexing
- Bundling aggressively to reduce requests, a HTTP/1.1-era habit HTTP/2 makes unnecessary
- Pushing resources broadly with server push and wasting bandwidth on cached content
Related concepts
Related examples
Authoritative source
What it is
HTTP/2 replaces the textual, one-message-at-a-time model of HTTP/1.1 with a binary framing layer. A connection carries multiple streams, each a sequence of frames labelled with a stream id, so requests and responses interleave without blocking one another. Headers are compressed with HPACK, which exploits repetition across requests. The protocol keeps HTTP semantics — methods, status codes, headers — but changes how they travel.
Why it matters
HTTP/1.1 forced browsers and servers into workarounds: many connections, domain sharding, sprites, and aggressive bundling, all to hide latency from serialised requests. HTTP/2 removes the need for most of them by multiplexing over one connection and compressing the repeated header bytes. Pages load with fewer round trips and less connection setup, and the application code barely changes because negotiation happens in TLS.
How to use it well
Stop sharding domains and reduce over-bundling, and let the protocol do what those tricks approximated. Be conservative with server push, or disable it, since it can send data the client already has. Keep in mind that a single TCP connection means packet loss stalls all streams, so on lossy mobile networks HTTP/3 over QUIC can outperform it. Monitor per-connection stream counts and tune server concurrency limits accordingly.