Persistent Connections, Pipelining, and Multiplexing

An HTTP request might take only a few milliseconds of server work, yet creating the connection that carries it can require much more:

Repeating that entire sequence for every small request wastes latency and endpoint resources. A persistent connection stays open long enough to carry multiple HTTP exchanges, allowing later requests to reuse work that has already been completed.

Persistence alone does not provide concurrency. With ordinary HTTP/1.1 use, one connection normally carries one active exchange at a time. HTTP/1.1 pipelining allows several requests to be outstanding, but responses still have to arrive in request order. HTTP/2 and HTTP/3 use multiplexed streams so that multiple exchanges can make progress independently on one connection.

These ideas sound similar because they all reduce connection overhead, but they solve different problems. Understanding the distinction is essential when configuring an HTTP client, diagnosing intermittent connection resets, or deciding why a pool has idle sockets while requests are still waiting.