persistent connection
What is a persistent connection?
A persistent connection, also known as a Hypertext Transfer Protocol (HTTP) persistent connection, refers to a network communication channel that remains open for further HTTP requests and responses instead of closing after a single exchange. Persistent connections are also called HTTP keep-alive and HTTP connection reuse.
An example of where a persistent connection is important can be found in an internet user's request to open a webpage. Accessing the page requires multiple content elements to be downloaded, including images, text and scripts. Without a persistent connection, each of those elements would require a new connection to the web server, leading to delays in displaying the full page. With the system providing a persistent connection, the download is accelerated.
Persistent connection function in HTTP
HTTP is an application-level protocol that typically runs on port 80. It uses Transmission Control Protocol (TCP) as an underlying transport protocol. TCP is a connection-oriented protocol: It starts a connection after confirmation from both ends that they are available and open to a data exchange.
A persistent connection function in HTTP 1.1, introduced in 1997, and later versions allowed the channel to remain open rather than closing after a requested exchange of data. The goal is to use a single TCP connection to send multiple HTTP requests and receive multiple HTTP responses, instead of opening a new connection for every request-response pair.
In early web technology based on HTTP 1.0, the server always closed connections after sending the response. Persistent connections added to this protocol used an extra header to request the client keep the connection alive. HTTP 1.1 assumes all connections to be persistent unless otherwise specified. In other words, persistent connections are the default behavior of any connection in HTTP 1.1. The HTTP/2 protocol expands the idea to enable multiple requests and returns of data to be exchanged simultaneously, or multiplexed, over a single connection.
Persistent connections vs. nonpersistent connections
The difference between persistent and nonpersistent connections becomes most obvious in terms of round-trip time (RTT). RTT is the duration in milliseconds from when a web browser first sends a request to when it receives a response from a web server. As a key performance metric for web applications, a lower RTT is always desirable. The RTT value is two times the value of the packet propagation time.
In persistent connections, the server leaves the connection open after sending a response. TCP keep-alive packets are sent to maintain the connection and prevent it from timing out. Subsequent HTTP messages between the server and clients are sent over this open connection. Further, the client sends a request to the server as soon as it encounters a referenced object -- for example, an image or text file. All of this reduces the RTT.
In a nonpersistent connection, the channel closes when one host signals that it wants to end communications or when a certain amount of time has elapsed with no exchange of data. There is some additional overhead for each TCP connection, so the RTT is higher. In addition, browsers often open parallel TCP connections to fetch referenced objects. This again increases the RTT and introduces latency into the network.
Benefits of persistent connections
An open and persistent connection is faster for frequent data exchanges. A connection that stays open rather than opening and closing sessions for each request also saves communications overhead. Persistent connections can be used with application programming interfaces to enable servers to push data to clients.
Other benefits of persistent connections include the following:
- reduced network congestion due to fewer TCP connections and lower network traffic;
- lower latency for subsequent requests because the initial TCP handshake is avoided;
- less processor and memory usage due to the lower number of connections and fewer Secure Socket Layer/Transport Layer Security handshakes; and
- support for HTTP pipelining of both requests and responses.
In addition, transmission errors can be reported without closing the persistent connection. And with long-lasting connections, the TCP gets sufficient time to determine the network's congestion state and then react appropriately.
Drawbacks of persistent connections
One drawback of a persistent connection is that if one client does not close the connection after receiving all its required data, other clients will be unable to access the resources needed to keep the connection open on the server. This can affect resource and server availability for these clients. The period of unavailability depends on the server's architecture and configuration.
Another problem is that when a client sends a request to the server at the same time that the server closes the TCP connection, it can result in what is known as a race condition. To avoid this issue, the server should send a "408 Request Timeout" status code to the client before closing the connection. On receiving this code, the client can open a new connection to the server and resend the request. However, not all clients will resend the request, leading to unexpected or undesirable results.
If proxy servers are in place, they must correctly signal all persistent or nonpersistent connections separately with all clients, origin servers and other proxy servers. This is because persistent connections apply to only one transport link.
Persistent connections for webpage requests
Persistent connections are frequently used for webpage requests. First, the web browser requests the page, parses it and identifies the resources -- such as images, cascading style sheets and scripts -- it will need to render that page. Since the browser requests these resources one by one, it is most efficient to maintain a persistent connection, which reduces the overhead and associated delays when new connections are created and destroyed.
From the perspective of the web server, a persistent connection allows the server to push content to the client's web browser. The webpage requests many different resources on the same server. When the server doesn't close the socket after it finishes pushing out one response, but instead reuses it for further requests, the browser can make other requests on the same socket, thus reducing the overall latency. The latency would be much higher if the original socket was closed and a new socket had to be opened for every follow-on request from the browser.
Persistent connections in web browsers
All modern web browsers such as Google Chrome, Mozilla Firefox and Microsoft Edge use persistent connections. However, these connections typically time out after a predefined period of inactivity. For most browsers, the timeout period can be modified from the Windows Registry.
For example, in Edge, this period is 1 minute. The browser will reuse the same TCP/IP socket that was used for the initial request until the socket is idle for 1 minute. After the minute has passed, it will reset the connection for additional requests, and a new TCP/IP socket will be used.