HTTP Keep-Alive Connections
HTTP keep-alive, or persistent connections, keeps a TCP connection open after a response so subsequent requests to the same host reuse it. This avoids repeating TCP and TLS handshakes for every request, significantly reducing latency for clients that call the same API repeatedly.
Technical Architecture & Deep-Dive
HTTP/1.0 closed the connection after each response by default. HTTP/1.1 made persistent connections the default, and HTTP/2 extended reuse with multiplexing.
On mobile devices, connections are often dropped by idle timeouts or network changes, forcing fresh handshakes. Terminating connections at a nearby edge location makes these handshakes short, while the edge maintains long-lived connections to upstream APIs.
Key Architectural Benefits
Implement HTTP Keep-Alive Connections at the Edge
Deploy lightweight API aggregation, edge caching, and secret injection in minutes without Docker containers or complex servers.
Frequently Asked Questions
Q:Do keep-alive connections stay open forever?
No. Servers and clients close idle connections after a timeout to free resources, typically between a few seconds and a few minutes.
Related Architecture Concepts
Connection pooling is maintaining a set of open, reusable connections to a database or upstream service so requests can borrow an existing connection instead of opening a new one. It avoids repeated TCP and TLS handshakes and prevents exhausting server connection limits.
TLS handshake latency is the delay caused by negotiating an encrypted HTTPS connection before any application data is sent. The client and server exchange messages to agree on ciphers and verify certificates, costing one or more network round trips on top of TCP setup.
Mobile network latency is the delay data experiences traveling between a mobile device and a server over cellular or wireless networks. Radio wake-up time, high round trip times, packet loss, and network switching make mobile requests significantly slower and less predictable than wired connections.