HTTP/2 Multiplexing: Mermaid Sequence Diagram

About Source

HTTP/2 multiplexing is the ability to send multiple concurrent HTTP requests and responses over a single TCP connection simultaneously, using a framing layer with stream IDs to interleave request and response data without head-of-line blocking at the HTTP layer.

HTTP/1.1's primary performance limitation is that each TCP connection can handle only one outstanding request at a time (without pipelining, which was poorly supported). Browsers worked around this by opening 6 TCP connections per origin — each requiring its own TCP and TLS handshake. HTTP/2 solves this at the protocol level.

Binary Framing Layer: HTTP/2 replaces HTTP/1.1's text-based request/response format with a binary framing layer. All communication is split into frames (HEADERS, DATA, SETTINGS, WINDOW_UPDATE, etc.) with a fixed 9-byte frame header containing the stream ID.

Streams: A stream is a bidirectional sequence of frames within an HTTP/2 connection. Each request/response pair occupies one stream with a unique integer ID (client-initiated streams use odd IDs; server push uses even IDs). Streams are independent — a slow response on stream 3 doesn't block streams 5 and 7.

Header Compression (HPACK): HTTP headers are compressed using a static and dynamic table indexed dictionary, significantly reducing overhead for requests with large or repeated headers (e.g., cookies, Authorization).

Server Push: The server can proactively send resources (CSS, JS, images) to the client before they're explicitly requested, using even-numbered stream IDs. In practice, this feature was complex and saw limited adoption; it was removed from HTTP/3.

TCP Head-of-Line Blocking: HTTP/2 eliminates HTTP-level HOL blocking, but TCP-level HOL blocking remains: a single lost TCP segment stalls all streams until retransmission. HTTP/3 resolves this by using QUIC streams over UDP.

Frequently asked questions

HTTP/2 multiplexing is the ability to send multiple HTTP requests and receive multiple responses concurrently over a single TCP connection, using a binary framing layer that assigns each request/response pair a unique stream ID. This eliminates the need for browsers to open multiple parallel TCP connections per origin.

HTTP/2 splits all communication into binary frames (HEADERS, DATA, SETTINGS, etc.), each carrying a 9-byte header with a stream ID. Multiple streams are interleaved on the wire — frame from stream 3, then stream 7, then stream 5 — and reassembled at the receiver by stream ID. A slow or blocked response on one stream does not prevent progress on other streams.

HTTP/2 eliminates the need for connection pooling (typically 6 TCP connections per origin in HTTP/1.1), reduces header overhead via HPACK compression, and allows responses to be received as soon as they are ready rather than waiting for sequential request/response cycles. Page load times improve particularly for resource-heavy pages.

HTTP/2 eliminates HTTP-level head-of-line blocking, but TCP-level blocking persists. If a single TCP segment is lost, all HTTP/2 streams on that connection stall while TCP retransmits the missing segment. This can make HTTP/2 perform worse than HTTP/1.1 on high-loss networks. HTTP/3 over QUIC solves this by making each stream independent at the transport layer.

mermaid

sequenceDiagram
    participant Client
    participant Server

    note">Note over Client,Server: Single TCP+TLS connection established

    note">Note over Client,Server: Stream 1: HTML request
    Client->&gt;Server: HEADERS frame (stream 1)\nGET /index.html

    note">Note over Client,Server: Stream 3: CSS request (concurrent)
    Client->&gt;Server: HEADERS frame (stream 3)\nGET /style.css

    note">Note over Client,Server: Stream 5: JS request (concurrent)
    Client->&gt;Server: HEADERS frame (stream 5)\nGET /app.js

    note">Note over Client,Server: Responses interleaved — no blocking
    Server-->&gt;Client: HEADERS frame (stream 1)\n200 OK, content-type: text/html
    Server-->&gt;Client: DATA frame (stream 3)\nCSS content chunk 1
    Server-->&gt;Client: DATA frame (stream 1)\nHTML content
    Server-->&gt;Client: DATA frame (stream 5)\nJS content
    Server-->&gt;Client: DATA frame (stream 3)\nCSS content chunk 2

    note">Note over Client,Server: Server push: proactive resource
    Server-->&gt;Client: PUSH_PROMISE (stream 2)\nPushing /logo.png
    Server-->&gt;Client: DATA frame (stream 2)\nImage data