Keep-Alive, also called persistent connection, allows multiple HTTP requests and responses over a single TCP connection, reducing latency and overhead compared to opening a new connection per request.

What is Keep-Alive? Definition, examples and how it works

Keep-Alive is an HTTP mechanism that enables a single TCP connection to be reused for multiple request-response exchanges. In HTTP/1.0, connections were closed after each request by default. The Connection: keep-alive header was introduced experimentally to request persistence. HTTP/1.1 made persistent connections the default behavior, as specified in RFC 7230 section 6.3. The client and server negotiate persistence using the Connection header. The connection remains open until either side explicitly closes it, or a server-defined timeout or maximum number of requests is reached. Common timeout values range from 5 to 15 seconds.

Keep-Alive reduces the overhead of repeated TCP three-way handshakes and slow-start phases for each resource. For a web page with many embedded objects (images, scripts, stylesheets), reusing one connection can cut load time significantly. However, HTTP/1.1 persistent connections still serialize requests: each request must complete before the next begins unless HTTP pipelining is used (rarely supported correctly). HTTP/2 supersedes this model with multiplexed streams over a single connection, but Keep-Alive remains essential for HTTP/1.1 traffic, which still constitutes a large portion of web traffic. The mechanism is controlled by the Connection header, with values "keep-alive" or "close", and optional parameters like timeout and max.

Key facts

Introduced as an experimental header in HTTP/1.0, became default in HTTP/1.1 (RFC 7230).
Reduces TCP connection overhead by reusing a single connection for multiple HTTP requests.
Controlled by the Connection header with values 'keep-alive' or 'close'.
Server can impose a timeout and a maximum number of requests per persistent connection.
Persistent connections enable HTTP pipelining, though pipelining is rarely used in practice.

How it works in practice

A browser loading a web page with an HTML document and 10 images. Without Keep-Alive, the browser opens 11 separate TCP connections, each requiring a three-way handshake and slow-start. With Keep-Alive (the default in HTTP/1.1), the browser opens one connection, sends the HTML request, receives the response, then sends requests for each image sequentially over the same connection. This eliminates the handshake and slow-start delays for 10 of the 11 resources, reducing total load time by hundreds of milliseconds on high-latency networks.

Related terms

HTTP/1.1 HTTP/2 Connection header TCP handshake HTTP pipelining multiplexing latency

References

More in Web Protocols

CORS

CORS (Cross-Origin Resource Sharing) is a browser security mechanism that lets servers explicitly allow web pages from one origin to request resources from a different origin via HTTP response headers.

GraphQL

GraphQL is a query language and runtime for APIs that lets clients request exactly the data they need in a single round trip, reducing over-fetching and under-fetching.

gRPC

gRPC is a high-performance, open-source remote procedure call framework initially developed by Google. It uses HTTP/2 for transport, Protocol Buffers as its interface definition language and message serialization format, and supports bidirectional streaming.

HTTP

HTTP is a text-based request-response protocol that defines how web clients and servers exchange resources, forming the foundation of data communication on the World Wide Web.

HTTP Pipelining

HTTP Pipelining is a technique in HTTP/1.1 that sends multiple requests on a single connection without waiting for each response, now largely replaced by HTTP/2 multiplexing.

HTTP Status Code

A three-digit integer in an HTTP response that indicates the result of the server's attempt to process the request, grouped into five classes (1xx through 5xx).

HTTP/1.1

HTTP/1.1 is the persistent-connection version of the Hypertext Transfer Protocol, defined in RFC 2616 and updated by RFCs 7230-7235, enabling multiple requests and responses over a single TCP connection.

HTTP/2

HTTP/2 is a binary, multiplexed version of HTTP that reduces latency through header compression, stream prioritization, and server push, as defined in RFC 7540.

HTTP/3

HTTP/3 is the third major version of the Hypertext Transfer Protocol, which runs over QUIC instead of TCP to reduce latency, eliminate head-of-line blocking, and improve connection setup time.

HTTPS

HTTPS (HTTP Secure) is HTTP traffic encrypted inside a TLS session, protecting data confidentiality, integrity, and server authenticity between a client and a web server.