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 Operational Model and Client/Server Communication 1 2 3 HTTP Persistent Connection Establishment, Management and Termination

The basic HTTP communication process is a simple “two-step dance”: a client sends a request to a server and the server replies back to the client. Since this was all that HTTP was intended to do, the first version of the protocol was designed so that after a TCP connection was established between the client and server, a single request/response exchange was performed. The request satisfied, the TCP connection would then be terminated.

These connections, called transitory due to their short-lived nature, were the only type supported by the original HTTP/0.9, and the same model was maintained in the more widely-deployed HTTP/1.0. The advantage of this connection model is its conceptual simplicity; the problem with it is that it is inefficient when the client needs to make many requests to the same server. This is often the case with modern hypertext documents, which usually carry inline references to images and other media. A typical client request for the home page of a Web site begins with a single request for an HTML file, but then leads to subsequent requests for each of the other related files that go with that document.

With transitory connections, each of these requests made by the client requires a new, distinct TCP connection to be set up between the client and server. Every connection takes server resources and network bandwidth, so having to establish a new one for each file is woefully inefficient. Suppose that you were having a conversation with someone whom you needed to ask a series of questions. Now imagine that after answering each question, the other person hung up the phone and you had to call them up again! You get the picture.

There are some people who consider the temporary nature of HTTP/0.9 and HTTP/1.0 connections to be a “design flaw” of these early versions of HTTP, but I don't think that this is necessarily very fair. In the early days, this model of operation was really not a big issue; it only became problematic when the use of the Web and hypertext evolved.

For the first few years of its existence, hypertext was primarily that: text. Having an HTTP session only last long enough for one request/response was generally sufficient since the whole resource was in one file. It was only in the 1990s that hypertext became hypermedia, with a heavy emphasis on embedded graphics and other files. When Web pages changed from simple text to multimedia marvels sporting dozens or even hundreds of embedded images, the limitations of HTTP/1.0 really became obvious.

HTTP Operational Model and Client/Server Communication 1 2 3 HTTP Persistent Connection Establishment, Management and Termination