HTTP/2 Multiplexing

HTTP/2 multiplexing allows multiple request and response streams to share one TCP connection. This reduces the need for multiple parallel connections and lets independent streams make progress concurrently.

HTTP/2 represents an HTTP connection as a collection of independent streams. A browser can send requests for multiple resources over the same connection instead of creating a separate connection for each resource.

Each stream is divided into binary frames, and frames from different streams can be interleaved. The receiver uses stream identifiers to associate each frame with the correct request or response.

Multiplexing can reduce connection setup overhead and improve resource utilization, especially when a page needs many assets from the same origin. It also removes the HTTP/1.1 practice of relying heavily on multiple connections to achieve parallelism.

HTTP/2 still commonly runs over TCP, so packet loss can affect the connection as a whole at the transport layer. Although HTTP/2 avoids HTTP-level head-of-line blocking between streams, TCP-level head-of-line blocking can remain.

Key points

• Multiple HTTP/2 streams share one TCP connection.
• Streams are carried as interleaved binary frames.
• Stream IDs let endpoints associate frames with the correct request or response.
• Multiplexing reduces the need for multiple TCP connections to the same origin.
• TCP packet loss can still cause transport-level head-of-line blocking.

Interview questions

What problem does HTTP/2 multiplexing solve?

It allows multiple HTTP requests and responses to share a single connection. Frames from different streams can be interleaved rather than waiting for one complete response before another can progress at the HTTP layer. This reduces the need to open several connections to achieve concurrency and can lower connection-management overhead.

How does HTTP/2 multiplexing work internally?

HTTP/2 breaks messages into binary frames and assigns frames to numbered streams. Frames belonging to different streams can be interleaved on the same connection. The receiver uses each frame's stream identifier to reconstruct the corresponding request or response.

Does HTTP/2 eliminate head-of-line blocking?

It removes the HTTP/1.1-style application-level blocking where one response can prevent another request from being interleaved on the same connection. However, HTTP/2 normally runs over TCP, and TCP delivers bytes in order. A lost TCP packet can therefore prevent later bytes from being delivered to the HTTP/2 layer until the missing data is recovered.

Why might HTTP/2 perform poorly on a lossy network?

HTTP/2 multiplexes many streams over one TCP connection, so packet loss affects the shared transport. TCP requires ordered delivery, meaning later data may wait for a missing segment before the HTTP/2 layer can process it. Consequently, multiple otherwise independent HTTP/2 streams can experience delay from a single transport-level loss event.

If a page uses many resources, should a frontend engineer manually create multiple HTTP/2 connections?

Usually, application code should not try to defeat HTTP/2 multiplexing by opening extra connections. The browser manages connection reuse and protocol negotiation for ordinary HTTP requests. Multiple connections may have specific uses in some architectures, but they are not generally a frontend optimization to apply simply because a page has many resources.