Keep-Alive Connection

What is a keep-alive connection?

A keep-alive (persistent) connection stays open after a request completes so subsequent requests reuse it. The savings are concrete: a fresh HTTPS request pays a TCP handshake (1 RTT) plus TLS negotiation (1–2 RTTs) before any data — 100–300 ms to a cross-region endpoint. Reused connections skip all of it. HTTP/1.1 made persistence the default; HTTP/2 goes further, multiplexing many concurrent streams over one connection, which makes that single connection’s health matter even more.

Where it bites in modern stacks

Serverless cold paths: a Lambda that constructs a new HTTP or database client per invocation pays full handshakes every time — initializing clients outside the handler is the canonical fix, worth 10× on downstream latency. Database pools are keep-alive institutionalized: connection creation with auth is so expensive that pooling is mandatory, and serverless’s pool-per-instance explosion is why RDS Proxy-style poolers exist. Idle timeout mismatches cause the classic intermittent 502: a load balancer holding idle connections longer than the backend does will reuse a connection the backend already closed. The rule: every hop’s idle timeout must exceed the hop in front of it.

Tuning that actually matters

Set backend keep-alive timeout above your LB’s (e.g., ALB default 60 s → backend 65 s+); enable TCP keep-alive probes for long-lived internal connections crossing NATs (which silently drop idle flow state); and monitor connection reuse rate — a fleet doing one request per connection is burning latency invisibly.

What people get wrong

• Disabling keep-alive to “save resources” — idle connections are cheap; handshakes are not.
• Infinite reuse: connections should recycle periodically (requests served or age) to allow rebalancing after scale-out — old connections pin traffic to old backends.
• Ignoring it in TLS cost math — session resumption helps cold starts, but reuse beats resumption.

Primary source: RFC 9112 — HTTP/1.1 (persistent connections)

The Compounding Cost of Repeated Handshakes

For an HTTPS connection specifically, avoiding a repeated handshake means avoiding not just the TCP three-way handshake but also the more expensive TLS handshake, which itself involves cryptographic operations and, pre-TLS-1.3, multiple additional round trips — for a client making dozens of requests to the same server (loading a typical modern web page with many assets, or a client library making many sequential API calls), the cumulative latency saved by connection reuse can be substantial compared to establishing a fresh connection for every single request. This is why HTTP/1.1 made keep-alive the default behavior (reversing HTTP/1.0’s default of closing connections after each request), and why HTTP/2 and HTTP/3 go even further, multiplexing many concurrent requests over a single connection rather than merely reusing one connection sequentially.