HTTP/1.1 Keep-Alive vs HTTP/2 Multiplexing

From Keep-Alive to Multiplexing

HTTP/1.0: A New Connection Every Time

In the original HTTP/1.0, each request required a new TCP connection. For a page with 50 resources, the browser opened 50 separate TCP connections, each requiring a full handshake.

HTTP/1.1: Keep-Alive

HTTP/1.1 introduced persistent connections via the Connection: keep-alive header (enabled by default). The browser reuses a TCP connection for multiple requests. However, requests are still processed sequentially — the client must wait for the response to request 1 before sending request 2 on the same connection.

HTTP/1.1 Keep-Alive:
Connection 1: [Req1] [Res1] [Req2] [Res2] [Req3] [Res3]
Connection 2: [Req4] [Res4] [Req5] [Res5]
(sequential within each connection, parallel across connections)

HTTP/2: True Multiplexing

HTTP/2 allows multiple requests and responses to be interleaved on a single TCP connection using binary frames. Each request/response pair is a "stream" identified by a stream ID. The server can send frames from any stream in any order.

HTTP/2 Multiplexing:
Connection: [Req1][Req2][Req3][Res1-part1][Res2][Res1-part2][Res3]
(all interleaved on a single connection)

Performance Impact

HTTP/2 multiplexing eliminates the need for:

• Domain sharding (splitting resources across subdomains)
• Image sprites (combining images into single files)
• CSS/JS concatenation (bundling all scripts into one file)

These were HTTP/1.1 workarounds that added complexity. With HTTP/2, smaller individual files are often more efficient because they can be cached independently and streamed in parallel.