imported>OAbot: Open access bot: url-access updated in citation with #oabot.

2025-05-26T04:38:40Z

Open access bot: url-access updated in citation with #oabot.

New page

{{Short description|Using a single TCP connection to send and receive multiple HTTP requests/responses}}
{{HTTP}}
'''[[HTTP]] persistent connection''', also called '''HTTP keep-alive''', or '''HTTP connection reuse''', is the idea of using a single [[Transmission Control Protocol|TCP]] connection to send and receive multiple [[Hypertext Transfer Protocol|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 should always be '''closed''' by the server after sending the response.<ref>[https://datatracker.ietf.org/doc/html/rfc1945#section-1.3 Hypertext Transfer Protocol (HTTP/1.0): Overall Operation]</ref>

Since at least late 1995,<ref>{{cite web |last1=Gildor |first1=Dan |title=HTTP_Connection? |url=https://groups.google.com/g/comp.infosystems.www.authoring.cgi/c/hGxfGUtAX8M |website=Google Groups |access-date=17 November 2023}}</ref> developers of popular products (browsers, web servers, etc.) using HTTP/1.0, started to add an unofficial extension (to the protocol) named "keep-alive" in order to allow the reuse of a connection for multiple requests/responses.<ref>{{Cite web|url=http://www.tcpipguide.com/free/t_HTTPPersistentConnectionEstablishmentManagementand.htm|title=The TCP/IP Guide - HTTP Persistent Connection Establishment, Management and Termination|website=www.tcpipguide.com|archive-url=https://web.archive.org/web/20170521090116/http://www.tcpipguide.com/free/t_HTTPPersistentConnectionEstablishmentManagementand.htm|archive-date=2017-05-21|access-date=2017-12-31}}</ref><ref>{{Cite book|url=https://www.oreilly.com/library/view/http-the-definitive/1565925092/ch04s05.html|title=HTTP: The Definitive Guide. (excerpt of chapter: "Persistent Connections")|author1=David Gourley|author2=Brian Totty|author3=Marjorie Sayer|author4=Anshu Aggarwal|author5=Sailu Reddy|language=en|publisher=O'Reilly Media, inc.|isbn=9781565925090|year=2002|access-date=2021-10-18}}</ref>

If the client supports keep-alive, it adds an additional header to the request:
<pre>
Connection: keep-alive
</pre>
When the server receives this request and generates a response, if it supports keep-alive then it also adds the same above header to the response. 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 in this case they omit the <code>"Connection:"</code> header from the last message sent or, better, they add the keyword "close" to it:
<pre>
Connection: close
</pre>
After that the connection is closed following specified rules.

Since 1997, the various versions of HTTP/1.1 specifications acknowledged the usage of this unofficial extension and included a few caveats regarding the interoperability between HTTP/1.0 (keep-alive) and HTTP/1.1 clients / servers.<ref name="RFC-7230-6.3" />

=== HTTP 1.1 ===
In HTTP 1.1, all connections are considered persistent unless declared otherwise.<ref name="RFC-7230-6.3">[https://datatracker.ietf.org/doc/html/rfc7230#section-6.3 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing, Persistence]</ref> 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<ref>{{Cite web |url=https://httpd.apache.org/docs/1.3/mod/core.html#keepalivetimeout |title=Apache HTTP Server 1.3 – KeepAliveTimeout Directive |access-date=2015-01-28 |archive-date=2015-10-26 |archive-url=https://web.archive.org/web/20151026020841/http://httpd.apache.org/docs/1.3/mod/core.html#keepalivetimeout |url-status=dead }}</ref><ref>[https://httpd.apache.org/docs/2.0/mod/core.html#keepalivetimeout Apache HTTP Server 2.0 – KeepAliveTimeout Directive]</ref> and just 5 seconds for Apache httpd 2.2 and above.<ref>[https://httpd.apache.org/docs/2.2/mod/core.html#keepalivetimeout Apache HTTP Server 2.2 – KeepAliveTimeout Directive]</ref><ref>[https://httpd.apache.org/docs/2.4/mod/core.html#keepalivetimeout Apache HTTP Server 2.4 – KeepAliveTimeout Directive]</ref> 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.<ref>{{cite web|url=http://docforge.com/wiki/Httpd/KeepAlive |title=Httpd/KeepAlive |author=Multiple (wiki) |work=Docforge |access-date=2010-01-30 |url-status=dead |archive-url=https://web.archive.org/web/20100106140535/http://docforge.com/wiki/Httpd/KeepAlive |archive-date=January 6, 2010 }}</ref>

==== 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.<ref>{{cite web | url=https://stackoverflow.com/questions/17295939/http-what-are-the-relations-between-pipelining-keep-alive-and-server-sent-events | title=HTTP: What are the relations between pipelining, keep alive and server sent events}}</ref> This is a serious problem when <code>Content-Length</code> cannot be used due to streaming.<ref>{{cite web | url= https://gist.github.com/CMCDragonkai/6bfade6431e9ffb7fe88 | title=HTTP Streaming (or Chunked vs Store & Forward)}}</ref> To solve this problem, HTTP 1.1 introduced a [[chunked transfer coding]] that defines a <code>last-chunk</code> bit.<ref>{{cite web | url=http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.3.6.1 | title = Chunked Transfer Coding| date = June 1999}}</ref> The <code>last-chunk</code> bit is set at the end of each response so that the client knows where the next response begins.

== Advantages ==
* Reduced [[Latency (engineering)|latency]] in subsequent requests (no [[Handshake (computing)|handshaking]] and no [[TCP congestion control#Slow start|slow start]]).
* Reduced [[CPU]] usage and round-trips because of fewer new connections and [[Transport Layer Security#TLS handshake|TLS handshakes]].
* Enables [[HTTP pipelining]] of requests and responses.
* Reduced [[network congestion]] (fewer [[Transmission Control Protocol|TCP connection]]s).
* Errors can be reported without the penalty of closing the TCP connection.

According to [http://tools.ietf.org/html/rfc7230#section-6.4 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 [http://tools.ietf.org/html/rfc2616#section-8.1.4 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.<ref>{{Citation|last1 = Nielssen|first1 = Frystyk Henryk|last2 = Gettys|first2 = James|last3 = Baird-Smith |first3=Anselm |last4=Prud’hommeaux |first4=Eric |last5=Wium Lie |first5=Håkon |last6=Lilley |first6=Chris |title = Network Performance Effects of HTTP/1.1, CSS1, and PNG|journal = ACM SIGCOMM Computer Communication Review |volume = 27|issue = 4|date = October 1997|url = http://conferences.sigcomm.org/sigcomm/1997/papers/p102.html|issn = 0146-4833}}</ref>

== 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.

Also a [[race condition]] can occur where the client sends a request to the server at the same time that the server closes the TCP connection.<ref>{{Cite web|url=https://stackoverflow.com/questions/42631273/how-do-browsers-handle-http-keepalive-race-condition|title=How do browsers handle HTTP keepalive race condition? |date=Mar 6, 2017 |website=Stack Overflow }}</ref> A server should send a 408 Request Timeout status code to the client immediately before closing the connection. When a client receives the 408 status code, after having sent the request, it may open a new connection to the server and re-send the request.<ref>{{Cite journal|url=https://tools.ietf.org/html/rfc7231#section-6.5.7|title=Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content|date=June 2014|last1=Fielding|first1=Roy T.|last2=Reschke|first2=Julian|editor-first1=R. |editor-first2=J. |editor-last1=Fielding |editor-last2=Reschke |doi=10.17487/RFC7231 |s2cid=14399078 |website=IETF Datatracker |url-access=subscription}}</ref> Not all clients will re-send the request, and many that do will only do so if the request has an [[Hypertext Transfer Protocol#Idempotent methods and web applications|idempotent HTTP method]].

== Use in web browsers ==
[[File:HTTP persistent connection.svg|thumb|300px|Schema of multiple vs. persistent connection.]]
All modern web browsers including [[Google Chrome]], [[Firefox]], [[Microsoft Edge]], [[Opera (web browser)|Opera]] (since 4.0)<ref>{{cite web | url=http://www.opera.com/press/releases/2000/03/28/ | title=Opera 4.0 Upgrades File Exchange: Includes HTTP 1.1 | date=2000-03-28 | publisher=Opera Software | access-date=2009-07-08}}</ref> and [[Safari (web browser)|Safari]] use persistent connections.

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.<ref>{{cite web | url=http://kb.mozillazine.org/Network.http.keep-alive.timeout | title=Network.http.keep-alive.timeout | publisher=Mozillazine.org | access-date=2009-07-17}}</ref>

== Implementation ==
Python's <code>requests</code> library contains <code>requests.Session()</code>, which establishes a persistent HTTP connection, thereby allowing the underlying TCP connection to be reused, which can result in a significant performance increase.<ref>{{cite web | url=https://requests.readthedocs.io/en/latest/user/advanced/#session-objects | title=Requests.AdvancedUsage.SessionObjects | publisher=©MMXVIX. A Kenneth Reitz Project. | access-date=2023-04-22}}</ref>

== 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 [[HTTP/2 Server Push|pushing]] of content before it has been requested

==References==
{{Reflist}}

== External links ==
* [http://tools.ietf.org/html/rfc7230#section-6.3 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing, Connection Management, Persistence]
* [http://www.cs.wisc.edu/~cao/papers/persistent-connection.html Persistent Connection Behavior of Popular Browsers (dated)]
* [http://httpd.apache.org/docs/current/mod/core.html#keepalive Apache HTTPD Keep-Alive Support]
* [http://conferences.sigcomm.org/sigcomm/1997/papers/p102.html Network Performance Effects of HTTP/1.1, CSS1, and PNG]

{{DEFAULTSORT:Http Persistent Connection}}
[[Category:Hypertext Transfer Protocol]]

HTTP persistent connection - Revision history

imported>OAbot: Open access bot: url-access updated in citation with #oabot.