HTTP persistent connection

Last updated

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.

Contents

Operation

HTTP 1.0

Under HTTP 1.0, connections should always be closed by the server after sending the response. [1]

Since at least late 1995, [2] 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. [3] [4]

If the client supports keep-alive, it adds an additional header to the request:

Connection: keep-alive

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 "Connection:" header from the last message sent or, better, they add the keyword "close" to it:

Connection: close

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. [5]

HTTP 1.1

In HTTP 1.1, all connections are considered persistent unless declared otherwise. [5] 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 [6] [7] and just 5 seconds for Apache httpd 2.2 and above. [8] [9] 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. [10]

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. [11] This is a serious problem when Content-Length cannot be used due to streaming. [12] To solve this problem, HTTP 1.1 introduced a chunked transfer coding that defines a last-chunk bit. [13] The last-chunk bit is set at the end of each response so that the client knows where the next response begins.

Advantages

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. [14]

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. [15] 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. [16] Not all clients will re-send the request, and many that do will only do so if the request has an idempotent HTTP method.

Use in web browsers

Schema of multiple vs. persistent connection. HTTP persistent connection.svg
Schema of multiple vs. persistent connection.

All modern web browsers including Google Chrome, Firefox, Internet Explorer (since 4.01), Opera (since 4.0) [17] and Safari use persistent connections.

By default, Internet Explorer versions 6 and 7 use two persistent connections while version 8 uses six. [18] Persistent connections time out after 60 seconds of inactivity which is changeable via the Windows Registry. [19]

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. [20]

Implementation

Python's requests library contains requests.Session(), which establishes a persistent HTTP connection, thereby allowing the underlying TCP connection to be reused, which can result in a significant performance increase. [21]

See also

Related Research Articles

<span class="mw-page-title-main">HTTP</span> Application protocol for distributed, collaborative, hypermedia information systems

HTTP is an application layer protocol in the Internet protocol suite model for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web, where hypertext documents include hyperlinks to other resources that the user can easily access, for example by a mouse click or by tapping the screen in a web browser.

<span class="mw-page-title-main">Web server</span> Computer software that distributes web pages

A web server is computer software and underlying hardware that accepts requests via HTTP or its secure variant HTTPS. A user agent, commonly a web browser or web crawler, initiates communication by making a request for a web page or other resource using HTTP, and the server responds with the content of that resource or an error message. A web server can also accept and store resources sent from the user agent if configured to do so.

httpd Index of articles associated with the same name

HTTPd is a software program that usually runs in the background, as a process, and plays the role of a server in a client–server model using the HTTP and/or HTTPS network protocol(s).

In computer science and networking in particular, a session is a time-delimited two-way link, a practical layer in the TCP/IP protocol enabling interactive expression and information exchange between two or more communication devices or ends – be they computers, automated systems, or live active users. A session is established at a certain point in time, and then ‘torn down’ - brought to an end - at some later point. An established communication session may involve more than one message in each direction. A session is typically stateful, meaning that at least one of the communicating parties needs to hold current state information and save information about the session history to be able to communicate, as opposed to stateless communication, where the communication consists of independent requests with responses.

<span class="mw-page-title-main">HTTP pipelining</span> Computer communication technique

HTTP pipelining is a feature of HTTP/1.1, which allows multiple HTTP requests to be sent over a single TCP connection without waiting for the corresponding responses. HTTP/1.1 requires servers to respond to pipelined requests correctly, with non-pipelined but valid responses even if server does not support HTTP pipelining. Despite this requirement, many legacy HTTP/1.1 servers do not support pipelining correctly, forcing most HTTP clients to not use HTTP pipelining.

A keepalive (KA) is a message sent by one device to another to check that the link between the two is operating, or to prevent the link from being broken.

<span class="mw-page-title-main">Digest access authentication</span> Method of negotiating credentials between web server and browser

Digest access authentication is one of the agreed-upon methods a web server can use to negotiate credentials, such as username or password, with a user's web browser. This can be used to confirm the identity of a user before sending sensitive information, such as online banking transaction history. It applies a hash function to the username and password before sending them over the network. In contrast, basic access authentication uses the easily reversible Base64 encoding instead of hashing, making it non-secure unless used in conjunction with TLS.

Push technology, also known as server Push, refers to a communication method, where the communication is initiated by a server rather than a client. This approach is different from the "pull" method where the communication is initiated by a client.

Real-Time Messaging Protocol (RTMP) is a communication protocol for streaming audio, video, and data over the Internet. Originally developed as a proprietary protocol by Macromedia for streaming between Flash Player and the Flash Communication Server, Adobe has released an incomplete version of the specification of the protocol for public use.

Comet is a web application model in which a long-held HTTPS request allows a web server to push data to a browser, without the browser explicitly requesting it. Comet is an umbrella term, encompassing multiple techniques for achieving this interaction. All these methods rely on features included by default in browsers, such as JavaScript, rather than on non-default plugins. The Comet approach differs from the original model of the web, in which a browser requests a complete web page at a time.

<span class="mw-page-title-main">HTTP compression</span> Capability that can be built into web servers and web clients

HTTP compression is a capability that can be built into web servers and web clients to improve transfer speed and bandwidth utilization.

Chunked transfer encoding is a streaming data transfer mechanism available in Hypertext Transfer Protocol (HTTP) version 1.1, defined in RFC 9112 §7.1. In chunked transfer encoding, the data stream is divided into a series of non-overlapping "chunks". The chunks are sent out and received independently of one another. No knowledge of the data stream outside the currently-being-processed chunk is necessary for both the sender and the receiver at any given time.

mod_qos is a quality of service (QoS) module for the Apache HTTP server implementing control mechanisms that can provide different priority to different requests.

<span class="mw-page-title-main">Byte serving</span> HTTP facility to fetch a specific part of a file

Byte serving is the process introduced in HTTP protocol 1.1 of sending only a portion of a message from a server to a client. Byte serving begins when an HTTP server advertises its willingness to serve partial requests using the Accept-Ranges response header. A client then requests a specific part of a file from the server using the Range request header. If the range is valid, the server sends it to the client with a 206 Partial Content status code and a Content-Range header listing the range sent. If the range is invalid, the server responds with a 416 Requested Range Not Satisfiable status code.

<span class="mw-page-title-main">WebSocket</span> Computer network protocol

WebSocket is a computer communications protocol, providing a simultaneous two-way communication channel over a single Transmission Control Protocol (TCP) connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011. The current specification allowing web applications to use this protocol is known as WebSockets. It is a living standard maintained by the WHATWG and a successor to The WebSocket API from the W3C.

The Ident Protocol, specified in RFC 1413, is an Internet protocol that helps identify the user of a particular TCP connection. One popular daemon program for providing the ident service is identd.

FastCGI is a binary protocol for interfacing interactive programs with a web server. It is a variation on the earlier Common Gateway Interface (CGI). FastCGI's main aim is to reduce the overhead related to interfacing between web server and CGI programs, allowing a server to handle more web page requests per unit of time.

HTTP/2 is a major revision of the HTTP network protocol used by the World Wide Web. It was derived from the earlier experimental SPDY protocol, originally developed by Google. HTTP/2 was developed by the HTTP Working Group of the Internet Engineering Task Force (IETF). HTTP/2 is the first new version of HTTP since HTTP/1.1, which was standardized in RFC 2068 in 1997. The Working Group presented HTTP/2 to the Internet Engineering Steering Group (IESG) for consideration as a Proposed Standard in December 2014, and IESG approved it to publish as Proposed Standard on February 17, 2015. The initial HTTP/2 specification was published as on May 14, 2015.

Gemini is an application-layer internet communication protocol for accessing remote documents, similar to HTTP and Gopher. It comes with a special document format, commonly referred to as "gemtext", which allows linking to other documents. Started by a pseudonymous person known as Solderpunk, the protocol is being finalized collaboratively and as of October 2022, has not been submitted to the IETF organization for standardization.

References

  1. ↑ Hypertext Transfer Protocol (HTTP/1.0): Overall Operation
  2. ↑ Gildor, Dan. "HTTP_Connection?". Google Groups. Retrieved 17 November 2023.
  3. ↑ "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.
  4. ↑ David Gourley; Brian Totty; Marjorie Sayer; Anshu Aggarwal; Sailu Reddy (2002). HTTP: The Definitive Guide. (excerpt of chapter: "Persistent Connections"). O'Reilly Media, inc. ISBN   9781565925090 . Retrieved 2021-10-18.
  5. 1 2 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing, Persistence
  6. ↑ "Apache HTTP Server 1.3 – KeepAliveTimeout Directive". Archived from the original on 2015-10-26. Retrieved 2015-01-28.
  7. ↑ Apache HTTP Server 2.0 – KeepAliveTimeout Directive
  8. ↑ Apache HTTP Server 2.2 – KeepAliveTimeout Directive
  9. ↑ Apache HTTP Server 2.4 – KeepAliveTimeout Directive
  10. ↑ Multiple (wiki). "Httpd/KeepAlive". Docforge. Archived from the original on January 6, 2010. Retrieved 2010-01-30.
  11. ↑ "HTTP: What are the relations between pipelining, keep alive and server sent events".
  12. ↑ "HTTP Streaming (or Chunked vs Store & Forward)".
  13. ↑ "Chunked Transfer Coding". June 1999.
  14. ↑ 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", ACM SIGCOMM Computer Communication Review, 27 (4), ISSN   0146-4833
  15. ↑ "How do browsers handle HTTP keepalive race condition?". Stack Overflow. Mar 6, 2017.
  16. ↑ Fielding, Roy T.; Reschke, Julian (June 2014). Fielding, R.; Reschke, J. (eds.). "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content". IETF Datatracker. doi:10.17487/RFC7231. S2CID   14399078.
  17. ↑ "Opera 4.0 Upgrades File Exchange: Includes HTTP 1.1". Opera Software. 2000-03-28. Retrieved 2009-07-08.
  18. ↑ "IE8 speeds things up". Stevesouders.com. 2008-03-10. Retrieved 2009-07-17.
  19. ↑ "How to change the default keep-alive time-out value in Internet Explorer". Microsoft. 2007-10-27. Retrieved 2009-07-17.
  20. ↑ "Network.http.keep-alive.timeout". Mozillazine.org. Retrieved 2009-07-17.
  21. ↑ "Requests.AdvancedUsage.SessionObjects". ©MMXVIX. A Kenneth Reitz Project. Retrieved 2023-04-22.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.