Keep-Alive Connection
Reusing one TCP (and TLS) connection for many requests — the difference between paying handshake latency once and paying it on every call.
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)
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.