HTTP/2 Multiplexing
HTTP/2 multiplexing carries many concurrent request and response streams as interleaved frames over one TCP connection, removing the per-request queuing that limits HTTP/1.1.
Definition
Multiplexing is the core transport feature of HTTP/2. Each request and response exchange becomes a stream made of frames, and frames from all active streams are interleaved on a single connection, so a slow response no longer blocks the requests behind it.
Context and scope
Used by browsers fetching dozens of resources from one origin, by mobile clients where extra handshakes are expensive, and by proxies multiplexing upstream connections under limited file descriptors.
Common misconceptions
- Multiplexing removes all head-of-line blocking — only the HTTP layer is fixed, packet loss still stalls the whole TCP connection
- Unlimited streams always help — flow-control windows and stream limits decide real concurrency
- A single connection is automatically faster — without prioritization, tail latency can get worse
Anti-patterns
- Opening many parallel connections per host instead of reusing one multiplexed connection
- Sending huge unbounded streams that exhaust the shared connection flow-control window
- Ignoring stream prioritization and assuming the server orders work optimally by default
Related concepts
Related examples
Authoritative source
What it is
HTTP/1.1 runs one request at a time per connection, so browsers open six or more connections per origin to parallelize. HTTP/2 instead splits each exchange into a numbered stream and interleaves its frames with other streams on one connection. The result is full request concurrency without connection sprawl.
How it works
Every frame header carries a stream identifier; the receiver reassembles frames per stream until the stream closes with END_STREAM. Flow control applies per stream and per connection, with SETTINGS frames announcing initial window sizes. Priority signals indicate which streams deserve bandwidth first when the connection saturates.
When to use it
Multiplexing pays off when many small resources share one origin, on high-latency mobile networks where opening connections is costly, and behind load balancers that keep upstream connections alive. File descriptor pressure also drops because one connection replaces dozens.
Pitfalls
A lost TCP packet stalls every stream sharing the connection because TCP delivers bytes in order, which is what later motivated HTTP/3 over QUIC. A single huge upload can consume the whole connection window. Measure stream concurrency and connection saturation rather than assuming multiplexing alone improves latency.