HTTP Keep-Alive Churn

Why opening and closing network connections is the slowest thing your server does.

The idea

Before two computers can send an HTTP request, they must perform a TCP Handshake (and a TLS Handshake for HTTPS). This requires sending multiple packets back and forth just to establish the connection, which takes time. If you open a connection, send one small API request, and immediately close it, you spend 90% of your time just shaking hands. In high-traffic systems, this constant opening and closing is called Connection Churn, and it wastes massive amounts of CPU and network bandwidth.

How it works (Connection: keep-alive)

HTTP/1.1 introduced Connection: keep-alive. It tells the server: "After you send the response, don't close the TCP socket. I'm going to send another request on this exact same wire in a second." This allows you to reuse the established tunnel, completely bypassing the handshake penalty for subsequent requests.

// 1. First request pays the penalty (TCP + TLS Handshake)
// Request headers include "Connection: keep-alive"
GET /api/users HTTP/1.1
Connection: keep-alive

// 2. Second request is instantly sent down the open tube!
// No handshake required. Latency drops from 150ms to 20ms.
GET /api/posts HTTP/1.1
Connection: keep-alive

Cost

Keep-alive trades CPU/Network for RAM. If a server has 10,000 clients connected, and it keeps all 10,000 TCP sockets open "just in case" they send another request, the OS has to allocate memory for 10,000 idle sockets. To prevent memory exhaustion, servers use a Keep-Alive Timeout (e.g., if a connection is idle for 60 seconds, gracefully close it).

Watch out for

• Serverless Functions (AWS Lambda): Serverless functions tear down their environment after every request. If your Lambda connects to a database, it cannot use Keep-Alive effectively between invocations. It will suffer connection churn, destroying database performance. You must use a persistent Connection Proxy (like AWS RDS Proxy) to maintain the keep-alive pool.