The Keep-Alive Connection means that the server won't close the Connection after fulfilling the request. In HTTP 1.1, all connections are considered persistent unless declared otherwise. The HTTP 1.0 clients request persistent Connection by sending the "Connection: keep-alive" request header to the server. The servers inform the clients about persistent connections by including the "Connection: keep-alive" header in the response. Clients may specify the persistent connection options in a separate "Keep-Alive: [options]" HTTP header. In this Keep-Alive Connection example, we are sending Connection and Keep-Alive headers to the ReqBin echo URL.
Hypertext Transfer Protocol (HTTP) is a data transfer protocol that enables the communication between HTTP clients and servers. HTTP is based on a "request-response" architecture between a client and the server. The client makes a connection and initiates a request. The server receives the request, executes it, and sends the result to the client. Each HTTP message consists of a request line (status line for a response), HTTP headers, and a message body.
What is Connection header?
The Connection header that allows a single TCP connection to remain open for multiple HTTP requests/responses. Persistent connections allow sending multiple requests without opening a new connection for every single transaction. The connections are persistent by default for HTTP/1.1 clients. For HTTP/1.0 connections, you must pass the "Connection: keep-alive" request header to indicate that you explicitly want persistent connection.
Connection Header Example
What is Keep-Alive header?
The Keep-Alive header allows you to set persistent connection options such as connection timeout and the maximum number of requests in a single connection.
Keep-Alive header Example
Keep-Alive: timeout=5, max=100
timeout: sets the maximum timeout to 5 seconds
max: sets the maximum number of requests per 100
How to make a Keep-Alive request?
An example of sending a request to establish a persistent connection to the server using the Connection and Keep-Alive headers for the HTTP/1.0 protocol:
Keep-Alive Connection Example
GET /echo HTTP/1.0
Keep-Alive: timeout=5, max=100
Persistent connection in the HTTP versions
The table shows the difference between persistent connections in HTTP versions.
In HTTP/1.0, connections are not considered persistent unless the client sends a Connection: keep-alive header with the request. When the server accepts a persistent connection request, it sends a Connection: keep-alive header back to the client in response. After that, the connection remains open, and the client sends other requests using the same connection. The connection will remain open until the client or server drops the connection.
In HTTP/1.1, all connections are considered persistent unless otherwise specified and do not require additional Connection: keep-alive headers to establish a persistent connection. For example, the default connection timeout for Apache httpd 1.3 and 2.0 is 15 seconds and only 5 seconds for Apache httpd 2.2 and above. The advantage of a short timeout is to quickly deliver multiple web page components without using resources for too long running multiple server processes or threads.
Connection and Keep-Alive headers are not allowed in HTTP/2. Chrome and Firefox ignore these headers in HTTP/2 responses, but Safari will not load the web page if the server returns these headers in error.
What are the benefits of a Keep-Alive connection?
Persistent HTTP connections reduce the time to serve requests by reducing the number of TCP and SSL/TLS connection requests. This results in shorter round-trip times (RTT). To establish TCP connections, the client must first exchange SYN and ACK packets between the client and server before transferring data. When a Keep-Alive connection is used, this means that there is no need to repeat this process with every new request, as there is already an active connection to the server. This leads to:
Conserving network resources: Using one connection for multiple requests reduces the load on network resources.
Reduced network congestion: Fewer TCP connections between your servers and clients can result in less network congestion.
Reduced Latency: Reducing the number of 3-way handshakes can result in less site latency. This is especially true for SSL/TLS connections, which require additional round-trip cycles to encrypt and validate connections.