Please Whitelist This Site?
I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)
If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.
If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.
Thanks for your understanding!
Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide
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.