HTTP persistent connection
| HTTP |
|---|
 |
| Request methods |
| Header fields |
| Response status codes |
| Security access control methods |
| Security vulnerabilities |
HTTP persistent connection, also called HTTP keep-alive, or HTTP connection reuse, is the idea of using a single TCP connection to send and receive multiple HTTP requests/responses, as opposed to opening a new connection for every single request/response pair. The newer HTTP/2 protocol uses the same idea and takes it further to allow multiple concurrent requests/responses to be multiplexed over a single connection.
Operation
HTTP 1.0
Under HTTP 1.0, connections are not considered persistent unless a keep-alive header is included,[1] although there is no official specification for how keepalive operates. It was, in essence, added to an existing protocol. If the client supports keep-alive, it adds an additional header to the request:
Connection: keep-alive
Then, when the server receives this request and generates a response, it also adds a header to the response:
Connection: keep-alive
Following this, the connection is not dropped, but is instead kept open. When the client sends another request, it uses the same connection. This will continue until either the client or the server decides that the conversation is over, and one of them drops the connection.
HTTP 1.1
In HTTP 1.1, all connections are considered persistent unless declared otherwise.[2] The HTTP persistent connections do not use separate keepalive messages, they just allow multiple requests to use a single connection. However, the default connection timeout of Apache httpd 1.3 and 2.0 is as little as 15 seconds[3][4] and just 5 seconds for Apache httpd 2.2 and above.[5][6] The advantage of a short timeout is the ability to deliver multiple components of a web page quickly while not consuming resources to run multiple server processes or threads for too long.[7]
Keepalive with chunked transfer encoding
Keepalive makes it difficult for the client to determine where one response ends and the next response begins, particularly during pipelined HTTP operation.[8] This is a serious problem when Content-Length cannot be used due to streaming.[9] To solve this problem, HTTP 1.1 introduced a chunked transfer coding that defines a last-chunk bit.[10] The last-chunk bit is set at the end of each response so that the client knows where the next response begins.
Advantages
- Reduced latency in subsequent requests (no handshaking).
- Reduced CPU usage and round-trips because of fewer new connections and TLS handshakes.
- Enables HTTP pipelining of requests and responses.
- Reduced network congestion (fewer TCP connections).
- Errors can be reported without the penalty of closing the TCP connection.
According to RFC 7230, section 6.4, "a client ought to limit the number of simultaneous open connections that it maintains to a given server". The previous version of the HTTP/1.1 specification stated specific maximum values but in the words of RFC 7230 "this was found to be impractical for many applications... instead... be conservative when opening multiple connections". These guidelines are intended to improve HTTP response times and avoid congestion. If HTTP pipelining is correctly implemented, there is no performance benefit to be gained from additional connections, while additional connections may cause issues with congestion.[11]
Disadvantages
If the client does not close the connection when all of the data it needs has been received, the resources needed to keep the connection open on the server will be unavailable for other clients. How much this affects the server's availability and how long the resources are unavailable depend on the server's architecture and configuration.
Use in web browsers
All modern web browsers including Google Chrome, Firefox, Internet Explorer (since 4.01), Opera (since 4.0)[12] and Safari use persistent connections.
By default, Internet Explorer versions 6 and 7 use two persistent connections while version 8 uses six.[13] Persistent connections time out after 60 seconds of inactivity which is changeable via the Windows Registry.[14]
In Firefox, the number of simultaneous connections can be customized (per-server, per-proxy, total). Persistent connections time out after 115 seconds (1.92 minutes) of inactivity which is changeable via the configuration.[15]
See also
- HTTP pipelining, whereby multiple requests can be sent without waiting for a response
- HTTP/2, which allows out-of-order pipelining of requests and responses, and also predictive pushing of content before it has been requested
References
- ^ "The TCP/IP Guide - HTTP Persistent Connection Establishment, Management and Termination". www.tcpipguide.com. Archived from the original on 2017-05-21. Retrieved 2017-12-31.
- ^ Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing, Persistence
- ^ Apache HTTP Server 1.3 – KeepAliveTimeout Directive
- ^ Apache HTTP Server 2.0 – KeepAliveTimeout Directive
- ^ Apache HTTP Server 2.2 – KeepAliveTimeout Directive
- ^ Apache HTTP Server 2.4 – KeepAliveTimeout Directive
- ^ Multiple (wiki). "Httpd/KeepAlive". Docforge. Archived from the original on January 6, 2010. Retrieved 2010-01-30.
- ^ "HTTP: What are the relations between pipelining, keep alive and server sent events".
- ^ "HTTP Streaming (or Chunked vs Store & Forward)".
- ^ "Chunked Transfer Coding".
- ^ Nielssen, Frystyk Henryk; Gettys, James; Baird-Smith, Anselm; Prud’hommeaux, Eric; Wium Lie, Håkon; Lilley, Chris (October 1997), "Network Performance Effects of HTTP/1.1, CSS1, and PNG", Computer Communication Review, 27 (4), ISSN 0146-4833
- ^ "Opera 4.0 Upgrades File Exchange: Includes HTTP 1.1". Opera Software. 2000-03-28. Retrieved 2009-07-08.
- ^ "IE8 speeds things up". Stevesouders.com. 2008-03-10. Retrieved 2009-07-17.
- ^ "How to change the default keep-alive time-out value in Internet Explorer". Microsoft. 2007-10-27. Retrieved 2009-07-17.
- ^ "Network.http.keep-alive.timeout". Mozillazine.org. Retrieved 2009-07-17.