What is Stream Multiplexing

Stream multiplexing sends multiple independent data streams over a single connection so that if one stream stalls, the others keep flowing. It is the mechanism that eliminates head-of-line blocking at the transport layer.

How does HTTP/2 do it?

HTTP/2 introduced the idea of multiplexing multiple requests as numbered streams over one TCP connection. Each request gets a stream ID, and the server can interleave responses — sending a chunk of stream 1, then a chunk of stream 3, then more of stream 1. At the HTTP layer, streams are independent.

The problem is underneath. TCP sees all of this as one ordered byte stream. If a single packet is lost, TCP holds back all data until the missing packet is retransmitted. Stream 3's data might be sitting in the kernel buffer, fully received, but the application can't read it because TCP is waiting for a packet that only stream 1 needs. This is head-of-line blocking at the transport layer.

How does QUIC fix it?

QUIC moves stream multiplexing into the transport protocol itself. Each stream has its own sequence numbers and its own flow control. When a packet carrying stream 1 data is lost, only stream 1 stalls. Streams 2, 3, and 4 continue delivering data to the application without delay.

Each stream is identified by a stream ID. The client and server can create streams independently — odd-numbered IDs for client-initiated streams, even-numbered for server-initiated. Streams can be opened and closed without any round-trip negotiation.

Why not just open multiple connections?

Opening multiple TCP connections (what HTTP/1.1 does) avoids head-of-line blocking but wastes resources. Each connection requires its own handshake, its own TLS session, and its own congestion control state. Multiplexing gives you the isolation of separate connections with the efficiency of a single one.

Why it matters

Stream multiplexing is the reason HTTP/3 over QUIC performs better than HTTP/2 over TCP on lossy networks. It solves the fundamental tension between connection efficiency and stream independence that TCP could never resolve.