HTTP/2 Multiplexing: How It Works

HTTP/2 Multiplexing in Detail

Multiplexing is HTTP/2's most impactful feature. It allows multiple requests and responses to be interleaved on a single TCP connection, eliminating the need for multiple connections per origin.

Binary Framing Layer

Unlike HTTP/1.1's text-based protocol, HTTP/2 uses a binary framing layer. All communication is split into frames, each tagged with a stream ID:

HTTP/2 Binary Frame:
+-----------------------------------------------+
|  Length (24 bits)  |  Type (8)  |  Flags (8)   |
+-----------------------------------------------+
|              Stream Identifier (31 bits)        |
+-----------------------------------------------+
|              Frame Payload (variable)           |
+-----------------------------------------------+

Frame types include:

• HEADERS: HTTP request/response headers
• DATA: HTTP body content
• PRIORITY: Stream priority information
• RST_STREAM: Cancel a stream
• SETTINGS: Connection parameters
• PUSH_PROMISE: Server push notification

How Multiplexing Works

Each request/response pair is a stream. The client assigns odd stream IDs (1, 3, 5...), and server-initiated streams use even IDs (2, 4, 6...).

Multiple streams can be active simultaneously. The sender interleaves frames from different streams:

Frame sequence on the wire:
[HEADERS stream=1] [HEADERS stream=3] [DATA stream=1]
[DATA stream=3] [DATA stream=1] [HEADERS stream=5]
[DATA stream=3] [DATA stream=5]

Stream Prioritization

HTTP/2 supports a dependency tree where streams can declare dependencies on other streams and assign weights. However, the priority scheme proved too complex, and many servers implement it poorly. HTTP/3 adopted a simpler Extensible Priorities system (RFC 9218).

Limitations

Despite multiplexing at the HTTP layer, all streams share a single TCP connection. TCP-level head-of-line blocking means a single lost packet can stall all streams simultaneously. HTTP/3 solves this with QUIC's independent streams.