Under the older 1.0 version of HTTP, each 'client browser/remote server' 'request/reponse' required a brand new logical/physical connection to be established between the two (local client browser and remote web server). The client browser would make a request (causing a logical connection to the remote server to be opened), and once the logical connection was established, the client browser would send the request to the remote server upon this open connection, and the remote server would send the corresponding response back to it along this same connection.
Once the request was complete, however, the logical connection would then be closed, and any subsequent requests to the very same remote server would then need to create a brand new logical connection to service that request on. If a web page had, for example, many images -- all of which happened to reside on the same server -- the constant opening and closing of logical connections would cause an undue strain on overall network resources, decreasing overall efficiency and increasing the amount of overhead each end would require in order to satisfy the series of requests to retrieve all of those images.
HTTP/1.1 Persistent Connections was designed to overcome this inherent inefficiency by allowing more than one client browser request (and corresponding remote server response) to be made over a single logical connection. The client browser opens a connection to the remote server and sends the first request. Once the remote server finishes sending the response back, however, the connection is not closed. Instead, the client browser simply reuses the already open connection to send the next request. The server would then, of course, send the corresponding response back on the same connection.
Only after all of the many requests to the same server are serviced in this manner is the logical connection to the remote server actually closed. This efficient use of logical network connections reduces overall network resource usage and increases efficiency by reducing the amount of overhead required to service many requests to the same remote server.
More and more browsers and remote web servers are now being (or have already been) modified to take advantage of this new HTTP/1.1 Persistent Connections feature, and it is strongly encouraged that if your browser supports it, to enable the option that does so.
Microsoft's Internet Explorer browser, as it turns out, does have a configuration option that allows you to specify whether or not to use HTTP/1.1 both when communicating through proxies and when not. On its "Internet Options" dialog's "Advanced" tab, scroll down to the end of the list of options to the "HTTP 1.1 Settings" section. You should see two options: "Use HTTP 1.1" and "Use HTTP 1.1 through proxy connections" (each with a checkbox beside them). Simply click the checkbox so it contains a checkmark in order to enable this highly recommended option.
For Netscape Communicator users, however, there doesn't appear to be any preferences option that allows you to specify which protocol version to use. In fact, it appears the protocol version Netscape uses is hard coded within the program itself. Fortunately, however, this shouldn't make much of a difference if you're using AdCruncher™ since AdCruncher™ itseld does use the more efficient HTTP/1.1 protocol when talking to remote servers. (See the next section.)
As previously mentioned, even though Netscape appears to use the older and less efficient 1.0 version of the HTTP
protocol (or at least the older versions did anyway; see the footnote further below), you can still enjoy
most of the advantages of HTTP/1.1 Persistent Connections if you use AdCruncher™ along with it.
This is because a proxy sits between your client browser and the remote server and manages each side of the logical connection separately. Thus, while Netscape may indeed use the less efficient HTTP/1.0 protocol to talk to the proxy, the proxy (AdCruncher™) is still able to use the newer and more efficient HTTP/1.1 protocol when it talks to the remote servers.
That is to say, while logical connections may be opening and closing at a furious rate (one for each request that Netscape makes to AdCruncher™), these logical connections are only local connections (usually) between the browser and the proxy and thus are of little impact. (This assumes of course that AdCruncher™ is running on the same computer that Netscape is running on, or at least on the same local area network).
But even though AdCruncher™ must open a new logical connection for each of Netscape's requests to it for the very same remote server, AdCruncher™ only actually opens one logical connection for itself to the remote server in question to service the entire series of requests on. It opens the logical connection between itself and the remote server on the first request Netscape sends it, and then keeps that connection open (persistent) and simply reuses it for all of the remaining requests Netscape makes for the very same server.
This makes AdCruncher™ very "Internet Friendly" and the server admins out there on the World Wide Web will love you for using AdCruncher™ rather than an older, less efficient, browser like Netscape. Unless, of course, those server admins happen to work for some company that provides a banner ads service in which case they'll hate you for using AdCruncher™. :)
* Versions older than 5.x. Newer versions of Netscape (5.x and greater) appear to have been fixed to use the new HTTP/1.1 protocol so the above discussion does not apply to them.