HTTP Persistent Connections: Difference between revisions
Line 28: | Line 28: | ||
Both HTTP/1.1 client and server implementation must implement persistent connections, and assume persistent connections are the default. | Both HTTP/1.1 client and server implementation must implement persistent connections, and assume persistent connections are the default. | ||
Both the client and the server may chose to close connection, by signaling that with the use of the [[HTTP | Both the client and the server may chose to close connection, by signaling that with the use of the [[HTTP Entity Header Connection|Connection]] header. | ||
==The Client== | ==The Client== |
Revision as of 04:36, 8 January 2017
External
- RFC 2616 - Connections https://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html
- Wikipedia - Persistent Connections https://en.wikipedia.org/wiki/HTTP_persistent_connection
- HTTP Keepalive http://web.archive.org/web/20100813132504/http://www.io.com/~maus/HttpKeepAlive.html
- Akamai Support of Persistent Connections https://community.akamai.com/thread/1192
- O'Reilly HTTP: The Definitive Guide - Persistent Connections https://www.safaribooksonline.com/library/view/http-the-definitive/1565925092/ch04s05.html
Internal
Overview
By connection, we understand the TCP/IP connection opened between a HTTP client and a HTTP server. Prior to the introduction of the persistent connections by HTTP/1.1, there was no official specification on how to establish and maintain persistent connections. In most cases, a separate TCP connection was established to fetch each URL. This article assumes HTTP/1.1 and it does not apply to HTTP/1.0.
In HTTP/1.1, persistent connection is the default behavior.
Measurements of actual HTTP/1.1 connections had shown that persistent connections are preferable, for several reasons: resources (CPU time, memory, and network bandwidth) are saved on routers and hosts by opening and closing fewer TCP connections, network congestion is reduced by eliminating the packets caused by TCP open, latency on subsequent requests is reduced since there is no time spent in TCP's connection opening handshake. This last point is even more important in the case of SSL connections. Persistent connections can be used to pipeline requests.
Persistent connections may also present disadvantages, for heavily loaded servers by clients that stay idle for a long time. That is why implementing timeout on persistent connections is important. The higher the timeout, more server processes will be kept occupied waiting on connections with the idle clients.
A Persistent Connection is a Point to Point Affair
Client/Origin Server Connection
Both HTTP/1.1 client and server implementation must implement persistent connections, and assume persistent connections are the default.
Both the client and the server may chose to close connection, by signaling that with the use of the Connection header.
The Client
The client must assume that the server will maintain a persistent connection, even after an error response.
Connection via a Proxy
HTTP/1.1 proxy implementation must implement persistent connections, and assume persistent connections are the default.
Timing Out a Persistent Connection
Pipelining Requests
Configuration
For details on how to configure HTTP persistent connections with httpd, see:
Related
TO deplete
A HTTP persistent connection is a TCP/IP connection between the client and server that allows more that one request per connection.
It is the client that initially requests the connection to be kept alive. In HTTP 1.1, a persistent connection is initiated by specifying a "Keep-Alive" value for the "Connection" request header:
GET ... HTTP/1.1 Host: ... Connection: Keep-Alive
The server may or may not support persistent connections. If the server does support them, it will confirm that by including with the response a "Connection" response header:
200 OK Content-Length: ... Connection: Keep-Alive
Once both the client and the server have agreed on using persistent connections, they will keep the underlying TCP/IP connection open, and subsequent requests from that client will be sent over the persistent connection.