| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
HTTP Persistent Connection Establishment, Management and Termination (Page 1 of 2) The introduction of persistent connections greatly improved the efficiency of HTTP by cutting out most of the overhead involved in a sequence of HTTP/1.0 requests between a client and server pair. These connections have now become the standard for client/server communication on the Web. Like most TCP/IP client/server protocols, the server in HTTP plays the passive role by listening for requests on a particular port number. The default port number for HTTP is well-known TCP port number 80, and is used by Web browsers for most HTTP requests, unless a different port number is specified in the URL. The client initiates an HTTP connection by opening a TCP connection from itself to the server it wishes to contact.
Once the TCP connection is active, the client sends its first request message. As we will see in the next section, the request specifies what version of HTTP the client is using. If this is HTTP/0.9 or HTTP/1.0, the server will automatically work in the transitory connection model, and will only send one reply and then close the link. If it is HTTP/1.1, the assumption is that a persistent connection is desired. An HTTP/1.1 client can override this by including the special Connection: close header in its initial request, which tells the server it does not want to keep the session active after the request it is sending has been fulfilled. Assuming that a persistent connection is being used, the client may begin pipelining subsequent requests after sending its first request, while waiting for a response from the server to the initial query. As the server starts to respond to requests, the client processes them and takes action such as displaying the data retrieved to the user. The data received from the server may also prompt the client to request more files on the same connection, as in the case of an HTML document that contains references to images. The server will generally buffer a certain number of pipelined requests from the client. In the case where the client sends too many requests too quickly, the server may throttle back the client using the flow control mechanism built into TCP. In theory, the server could also just decided to terminate the connection with the client, but it is better for it to use TCPs existing features. Closing the connection will cause the client to initiate a new connection, potentially exacerbating any overloading problem.
Home - Table Of Contents - Contact Us The TCP/IP Guide (http://www.TCPIPGuide.com) Version 3.0 - Version Date: September 20, 2005 © Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved. Not responsible for any loss resulting from the use of this site. |