HTTP/2 Multiplexing and Connection Management

The HTTP/1.1 Problem

HTTP/1.1 has two key limitations:

1. One request at a time per connection — the client must wait for the server's response before sending the next request. This causes head-of-line blocking: if a large image loads slowly, every small file behind it waits.
2. Text-based protocol — headers are sent as readable text, adding overhead. A typical request sends 800+ bytes of headers, even if only a few are unique.

HTTP/2 Improvements

Binary Framing Layer

HTTP/2 encodes all data in a binary format instead of text. This makes parsing faster and eliminates ambiguity (no need to guess whether \n or \r\n separates headers).

Multiplexing

Multiple request/response pairs can travel simultaneously over a single TCP connection. Each request gets a unique stream ID, and the client and server interleave frames belonging to different streams. A slow response on one stream does not block fast responses on others.

Header Compression (HPACK)

HTTP/2 compresses headers using HPACK. Common headers (like User-Agent, Accept-Encoding) are stored in a shared dynamic table and referenced by index, reducing header overhead from ~800 bytes to ~10–20 bytes.

Server Push

The server can proactively send resources the client will need (e.g., CSS when sending HTML) without waiting for a separate request. The client can cancel pushes it doesn't need.

Connection Pooling and Reuse

Browsers limit connections per host (6 in HTTP/1.1, effectively 1 in HTTP/2 due to multiplexing). Connection reuse — keeping a TCP+TLS connection open for multiple requests — avoids the cost of repeated handshakes. Each new TLS connection adds 1 round trip (or 2 for TLS 1.2), so reuse significantly reduces latency.

HTTP/3 and QUIC

HTTP/3 runs over QUIC, a transport protocol built on UDP. QUIC combines the TLS handshake with the transport handshake, reducing connection setup from 2 round trips to 0–1. It also eliminates TCP's head-of-line blocking — packet loss only affects the stream that lost the packet, not the whole connection.

Read the full request lifecycle · Learn about CDNs