HTTP Keep-Alive
Keep-alive reuses one TCP connection for many sequential HTTP requests, amortizing handshake and slow-start costs; it is the default persistence model behind every modern connection pool.
Definition
Keep-alive is the HTTP/1.1 default that keeps a TCP connection open after a response so the next request on the same origin reuses it. It saves the TCP handshake, avoids TLS renegotiation cost, and preserves congestion-window state. Idle connections are closed by timeout, signaled by Connection headers in HTTP/1.0 terms.
Context and scope
Tuned on API clients, database-over-HTTP gateways, and reverse proxies, where per-request handshake cost dominates. Also the reason idle timeouts between load balancers and backends must be coordinated.
Common misconceptions
- Keep-alive makes requests concurrent — reuse is strictly sequential per connection; parallelism needs multiple connections
- Longer idle timeouts are always safer — they hold sockets, memory, and file descriptors on both ends
- Keep-alive and HTTP/2 multiplexing are the same idea — multiplexing removes the sequential limitation
Anti-patterns
- Setting client keep-alive timeout higher than the load balancer idle timeout and racing resets
- Opening a fresh connection per request in server-to-server calls and paying TLS handshake every time
- Keeping thousands of idle connections open without a cap and exhausting backend worker slots
Related concepts
Related examples
Authoritative source
What it is
A TCP connection is expensive: three-way handshake, TLS round trips, and a congestion window that starts cold. Keep-alive spreads those costs across many requests by leaving the connection warm. The Connection header governs persistence in HTTP/1.x semantics.
How it works
The server keeps the socket open after responding, until an idle timeout or an explicit close. Clients track which connections are reusable. Any party can signal closure, and half-closed connections must be detected and pruned. Pools add policy on top: maximum size, idle eviction, and health checks.
When to use it
Server-to-server API traffic should always reuse connections; handshake cost per call is pure waste. Browsers do this automatically. Backend timeout coordination matters: client idle timeouts should be shorter than the upstream timeout to avoid reuse races.
Pitfalls
A reused connection that the peer just closed produces a race on the next request; robust clients retry idempotent requests once. Unbounded idle pools consume server memory and accept slots. Load balancers that silently drop idle TCP state without RST cause intermittent stalls that look like application hangs.