What is HTTP Keep-Alive?
Learn what HTTP Keep-Alive is, how it reuses TCP connections to avoid handshake overhead, and how it differs from TCP keepalive.
Expected Interview Answer
HTTP Keep-Alive is a mechanism that reuses a single TCP connection for multiple HTTP requests and responses instead of opening a new connection for every request, avoiding the cost of a fresh TCP handshake (and TLS handshake) each time.
Without Keep-Alive, every HTTP/1.0 request opened a new TCP connection, paid the three-way handshake cost, transferred one response, and closed the connection, which is wasteful for pages with dozens of assets. With the `Connection: keep-alive` header (default behavior in HTTP/1.1), the client and server hold the socket open after a response so the next request can reuse it immediately. Servers typically bound this with a timeout and a maximum request count per connection to reclaim idle sockets. Keep-Alive dramatically reduces latency and CPU overhead for sites that load many resources from the same host, and it is the direct ancestor of HTTP/2's single multiplexed connection model.
- Avoids repeated TCP/TLS handshake cost per request
- Reduces page load latency for multi-resource pages
- Lowers server CPU/socket churn under load
- Default behavior in HTTP/1.1, tunable via timeout and max requests
AI Mentor Explanation
Keep-alive is like a commentary booth staying on air between overs instead of the broadcast van driving back to the studio and reconnecting for every single delivery. The line stays open, so the next call goes out instantly rather than paying the setup cost of dialing in again. If the booth sits silent too long, though, the studio eventually hangs up and a fresh connection is needed for the next segment. This is exactly how a kept-alive TCP connection serves many requests before an idle timeout closes it.
Step-by-Step Explanation
Step 1
Connection opens
Client and server complete a TCP (and optionally TLS) handshake once.
Step 2
Header signals reuse
Both sides send `Connection: keep-alive` (default in HTTP/1.1) to agree the socket stays open.
Step 3
Multiple requests reuse the socket
Subsequent requests and responses flow over the same connection without re-handshaking.
Step 4
Timeout or limit closes it
The server closes the idle connection after a configured timeout or max-request count.
What Interviewer Expects
- Explains the handshake cost Keep-Alive avoids
- Knows it is default in HTTP/1.1, opt-in header in HTTP/1.0
- Mentions server-side timeout/max-requests tuning
- Connects it conceptually to HTTP/2 connection multiplexing
Common Mistakes
- Thinking Keep-Alive means requests are sent in parallel on one socket (that is HTTP/2 multiplexing, not HTTP/1.1 pipelining-free reuse)
- Confusing Keep-Alive with TCP keepalive probes (a different, lower-level mechanism)
- Assuming the connection stays open forever with no timeout
- Not knowing it must be negotiated via headers in HTTP/1.0
Best Answer (HR Friendly)
“HTTP Keep-Alive means the browser and server keep talking over the same connection for a batch of requests instead of hanging up and redialing every single time. It is like keeping someone on hold instead of calling them back for every follow-up question — it saves the setup time and makes pages load faster.”
Code Example
# Verbose curl shows the connection reuse headers
curl -v -o /dev/null -s https://example.com
# Look for:
# < Connection: keep-alive
# < Keep-Alive: timeout=5, max=100
# Request twice on the same connection explicitly
curl -v https://example.com/ https://example.com/about \
--next -o /dev/nullFollow-up Questions
- How does HTTP/2 multiplexing replace the need for many kept-alive connections?
- What is the difference between HTTP Keep-Alive and TCP keepalive probes?
- How do connection pools in HTTP clients relate to Keep-Alive?
- What server settings control Keep-Alive timeout and max requests?
MCQ Practice
1. What problem does HTTP Keep-Alive primarily solve?
Keep-Alive reuses one TCP connection across requests to avoid the cost of a new handshake each time.
2. In HTTP/1.1, what is the default Keep-Alive behavior?
HTTP/1.1 treats persistent connections as the default; HTTP/1.0 required an explicit header.
3. What eventually closes an idle Keep-Alive connection?
Servers close idle kept-alive sockets after a timeout or once a max request count is reached.
Flash Cards
What is HTTP Keep-Alive? — Reusing one TCP connection for multiple HTTP requests instead of reconnecting each time.
Default in HTTP/1.1? — Yes — persistent connections are on by default; HTTP/1.0 needed an explicit header.
What closes a kept-alive connection? — A server-configured idle timeout or a maximum request count per connection.
Related HTTP/2 concept? — HTTP/2 multiplexes many requests over one connection, going further than Keep-Alive reuse.