Connection Management

Before any HTTP message can travel, the client and server must establish a TCP connection through a three-way handshake:

Only after this exchange can data flow. The handshake adds one full round-trip of latency before the first byte of the request is even sent. Between New York and London, that round-trip takes roughly 56 milliseconds over fiber. For a small resource—​a 304 Not Modified response, a tiny icon—​the handshake can consume more than half the total time.

TCP also starts slowly on purpose. A new connection uses slow start, throttling the amount of data in flight until the network proves it can handle more. Each successful acknowledgment doubles the sender’s congestion window. A fresh connection cannot send data at full speed; it needs time to ramp up. A connection that has already exchanged a modest amount of data is significantly faster than a new one.

These two costs—​handshake delay and slow start—​make opening a new connection surprisingly expensive. Every optimization in this section exists to avoid paying them more than necessary.

The original HTTP/1.0 protocol treated every request as an isolated event. The client opened a TCP connection, sent one request, received one response, and the connection was torn down. Loading a web page with an HTML document and three images required four separate TCP connections:

Each connection paid the handshake cost. Each started with a fresh slow-start window. As web pages grew richer—​dozens of images, stylesheets, and scripts—​the accumulated overhead became the dominant source of latency. Users stared at blank screens while their browsers quietly opened and closed connections.

The fix was obvious: keep the connection open. Rather than hanging up after each response, the client and server could reuse the same TCP connection for multiple requests.

HTTP/1.0 introduced this informally through a Connection: Keep-Alive header. If the client included this header, and the server echoed it back, the connection stayed open after the response:

Both sides had to agree. If the server did not return Connection: Keep-Alive, the client assumed the connection would close. Every request that wanted persistence had to ask for it explicitly.

HTTP/1.1 reversed the default. Persistent connections became automatic. An HTTP/1.1 connection stays open after every response unless one side explicitly signals otherwise with Connection: close:

This single change eliminated enormous overhead. With connection reuse, the handshake cost is paid once, TCP slow start ramps up once, and all subsequent requests on that connection benefit from a warmed-up pipe. For a page requiring N resources from the same server, persistent connections save (N-1) round trips—​often seconds of real-world latency.

Either side can close a persistent connection at any time, even without sending Connection: close first. Servers close idle connections to free resources. Clients close connections they no longer need. The protocol requires that both sides tolerate unexpected closes and be prepared to retry requests.

The Connection header controls per-hop connection behavior. It is a hop-by-hop header, meaning it applies only to the immediate link between two participants and must not be forwarded by proxies.

The header carries three kinds of values:

The Keep-Alive header (when present alongside Connection: Keep-Alive) can include hints about how long the sender expects to hold the connection open and how many more requests it anticipates. These are advisory, not guarantees. A server that says timeout=30 may still close the connection after five seconds if it needs the resources.

A critical rule for intermediaries: proxies must parse the Connection header, remove it and every header it names, and then forward the message. A proxy that blindly relays Connection: Keep-Alive to an origin server creates a well-known failure called the "dumb proxy" problem—​the server believes the proxy wants persistence, the proxy does not understand persistence, and the connection hangs.

While persistent connections eliminated repeated handshakes, they did not solve another problem: serialization. On a single persistent connection, each request had to wait for the previous response to finish. If the server took 500 milliseconds to generate one resource, everything behind it queued up.

Browsers worked around this by opening multiple TCP connections in parallel. Instead of one pipe, they opened several—​typically six per host in modern browsers:

Parallel connections overlap the delays. While one connection waits for a response, others are already transferring data. Users see images loading simultaneously across the page, which feels faster even when the wall-clock time is similar.

The downsides are real:

Parallel connections are a pragmatic workaround, not an elegant solution. They exist because HTTP/1.x lacks multiplexing.

HTTP/1.1 introduced pipelining as an attempt at better concurrency within a single connection. With pipelining, a client can send several requests in a row without waiting for responses:

By dispatching requests early, the client eliminates the dead time between sending a request and receiving the previous response. The server can even begin processing requests in parallel internally.

But pipelining has a fatal constraint: responses must arrive in the same order as the requests. HTTP/1.1 messages carry no sequence numbers, so neither side can match responses to requests if they arrive out of order. This requirement creates head-of-line blocking.

Connection management is not just about opening and keeping connections alive. Knowing when and how to close them correctly is equally important.

HTTP/2 addressed HTTP/1.1’s connection limitations at the protocol level. Rather than opening multiple TCP connections or attempting fragile pipelining, HTTP/2 introduced multiplexing over a single connection.

An HTTP/2 connection breaks messages into small binary frames, each tagged with a stream identifier. Multiple streams flow concurrently over the same TCP connection, and their frames can interleave freely:

Because each frame identifies its stream, responses can arrive in any order and be reassembled correctly. Head-of-line blocking at the HTTP layer is eliminated. A slow response on stream 1 no longer blocks a fast response on stream 3.

The consequences for connection management are dramatic:

However, HTTP/2 still runs over TCP, which imposes its own ordering constraints. If a TCP packet is lost, the entire connection stalls until that packet is retransmitted—​even streams whose data was not in the lost packet. This is transport-layer head-of-line blocking, and it is the problem that HTTP/3, built on QUIC over UDP, was designed to solve. But that is a story for a later section.

The evolution of HTTP connection management follows a clear arc toward doing more with fewer connections:

The lesson running through all of this is that connections are expensive, and the protocol’s history is a series of increasingly elegant solutions to that single economic fact. Keep connections open. Reuse them. And when one connection is not enough, multiplex rather than multiply.

You now understand how HTTP connections are opened, reused, and closed, and why each generation of the protocol refined the strategy. The next section covers the mechanism that prevents the Web from doing the same work twice: