What is Connection Multiplexing and How Does HTTP/2 Use It?
Learn what connection multiplexing is, how HTTP/2 interleaves streams on one connection, and why HTTP/3 fixes remaining blocking.
Expected Interview Answer
Connection multiplexing is sending multiple independent logical streams of data over a single shared physical or transport connection instead of opening a separate connection per stream, and HTTP/2 uses it to run many concurrent request/response exchanges over one TCP connection to the same host.
In HTTP/1.1, browsers typically open several parallel TCP connections per host (often capped around six) because each connection can only carry one request at a time before the next can start, and head-of-line blocking makes a slow response stall everything behind it on that connection. HTTP/2 introduces binary framing: each request and response is broken into frames tagged with a stream ID, and frames from many concurrent streams are interleaved onto a single TCP connection, then reassembled by stream ID on the other end. This removes the need for multiple connections per host, cuts down on repeated TCP and TLS handshake overhead, and lets the server push responses back interleaved as they become ready rather than strictly in request order. The remaining weakness is that HTTP/2 multiplexing still sits on top of a single TCP connection, so a lost TCP packet blocks all streams until it is retransmitted (TCP-level head-of-line blocking) — which is exactly the problem HTTP/3 solves by multiplexing over independent QUIC streams instead.
- Eliminates per-host connection limits and repeated handshake overhead
- Removes application-level head-of-line blocking present in HTTP/1.1 pipelining
- Lets responses be interleaved and returned in whatever order they finish
- Reduces total resource usage on both client and server for high request-count pages
AI Mentor Explanation
Connection multiplexing is like a single stadium PA system carrying commentary for several matches happening on adjacent grounds at once, each match’s updates tagged with its own channel number so listeners can tune to the right one. Instead of running a separate speaker wire to every ground, one shared line carries interleaved updates for all of them simultaneously. A commentator on match three finishing a sentence does not block match one’s update from going out next. That single shared channel carrying many tagged streams is exactly what connection multiplexing does for network requests.
Step-by-Step Explanation
Step 1
Establish one connection
Client and server complete a single TCP (and TLS) handshake to the host instead of opening several.
Step 2
Break requests into framed streams
Each request/response is split into binary frames tagged with a unique stream ID.
Step 3
Interleave frames on the wire
Frames from many concurrent streams are sent interleaved over the one connection as they become ready.
Step 4
Reassemble by stream ID
The receiving side groups incoming frames back into their original streams using the stream ID.
What Interviewer Expects
- Contrasts HTTP/1.1’s per-host connection limits with HTTP/2’s single-connection model
- Explains binary framing and stream IDs as the mechanism enabling interleaving
- Identifies remaining TCP-level head-of-line blocking and how HTTP/3/QUIC addresses it
- Connects multiplexing to reduced handshake overhead and better resource usage
Common Mistakes
- Confusing HTTP/2 multiplexing with simply opening more parallel connections
- Not mentioning that TCP-level head-of-line blocking still exists under HTTP/2
- Forgetting stream prioritization as part of how HTTP/2 schedules interleaved frames
- Assuming multiplexing eliminates the need for any connection at all
Best Answer (HR Friendly)
“Connection multiplexing lets many separate requests and responses share a single connection at the same time, instead of each one needing its own dedicated connection. HTTP/2 uses this so a browser does not need to open a bunch of separate connections to load one page, which makes pages load faster and more efficiently.”
Code Example
connection: single TCP+TLS to api.example.com
streams:
- streamId: 1
request: GET /api/users/42
priority: high
- streamId: 3
request: GET /api/orders/42
priority: medium
- streamId: 5
request: GET /api/recommendations/42
priority: low
framesOnWire:
# frames from all three streams interleaved, tagged by streamId
- { streamId: 1, frameType: HEADERS }
- { streamId: 3, frameType: HEADERS }
- { streamId: 1, frameType: DATA, final: true }
- { streamId: 5, frameType: HEADERS }
- { streamId: 3, frameType: DATA, final: true }
- { streamId: 5, frameType: DATA, final: true }Follow-up Questions
- What is TCP-level head-of-line blocking and why does HTTP/2 still suffer from it?
- How does HTTP/3 over QUIC solve the head-of-line blocking that remains in HTTP/2?
- How does stream prioritization work within a single multiplexed HTTP/2 connection?
- Why did browsers cap HTTP/1.1 to roughly six parallel connections per host?
MCQ Practice
1. What does connection multiplexing allow in HTTP/2?
HTTP/2 multiplexes many concurrent request/response streams over one shared TCP connection using stream IDs.
2. What limitation still affects HTTP/2 despite multiplexing?
Because HTTP/2 multiplexes over one TCP connection, a single lost packet blocks all streams until retransmitted.
3. How does HTTP/3 address the remaining head-of-line blocking problem in HTTP/2?
QUIC (used by HTTP/3) gives each stream independent loss recovery, so one stream’s packet loss does not block the others.
Flash Cards
What is connection multiplexing? — Sending multiple independent streams over one shared connection instead of one connection per stream.
How does HTTP/2 achieve it? — Binary framing tags each stream with a stream ID so frames can be interleaved and reassembled.
What head-of-line blocking remains in HTTP/2? — TCP-level: a lost packet stalls all multiplexed streams until it is retransmitted.
What fixes that remaining blocking? — HTTP/3 over QUIC, which gives each stream independent loss recovery.