The TCP/IP Guide  9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)       9  TCP/IP Key Applications and Application Protocols            9  TCP/IP File and Message Transfer Applications and Protocols (FTP, TFTP, Electronic Mail, USENET, HTTP/WWW, Gopher)                 9  TCP/IP World Wide Web (WWW, "The Web") and the Hypertext Transfer Protocol (HTTP)                      9  TCP/IP Hypertext Transfer Protocol (HTTP)                           9  HTTP General Operation and Connections

HTTP Transitory and Persistent Connections and Pipelining 1 2 HTTP Messages, Message Formats, Methods and Status Codes

Connection Termination

The flow of requests and responses continues for as long as the client has requests. The connection can be gracefully terminated by the client by including the Connection: close header in the last request it needs to send to the server. All requests are filled in order, so the server will satisfy all outstanding requests and then close the session.

Since HTTP/1.1 supports pipelining of requests, there is usually no need for a client to establish more than one simultaneous connection to the same server. Clients occasionally do this anyway to allow them to get information from a server more quickly. This is considered by many to be “anti-social”, because it can lead to a busy server's resources being monopolized by one client to the exclusion of others that want to access it.

Under special circumstances, either the client or the server may unexpectedly close an active persistent connection. For example, if the client detects that too much time has elapsed since the server last replied, it may conclude that the server has crashed and terminate the connection. Similarly, the server might receive a shutdown command from its administrator or for other reasons end a session with a client abruptly. Servers normally avoid closing down a link during the middle of sending a response.

Both clients and servers must be able to handle abrupt session termination. For servers, there is not much to do; if the client terminates the connection the server simply “cleans up” any resources associated with the connection, and goes on to service the next client.

Clients have more to do when a server prematurely terminates a session, and this is especially the case when requests are pipelined. The client must keep track of all requests sent to the server to ensure that each is filled. If the server closes the session unexpectedly, the client will usually attempt to establish a new connection to retransmit the unfilled requests. Since an abrupt session close is often a sign of a busy server, the HTTP standard specifies that clients use a binary exponential backoff algorithm to wait a variable but increasing amount of time before submitting re-requests for files (similar in concept to the method used to deal with collisions in Ethernet). This helps prevent clients from “piling on” requests to a device that is already overwhelmed.

HTTP Transitory and Persistent Connections and Pipelining 1 2 HTTP Messages, Message Formats, Methods and Status Codes