[HTTP - TCP/IP Bad Match: Solved]
Hi Andreas -
Luckily, the folks at W3C are addressing this problem. Here's a few paragraphs from an article in PC Magazine. The full URL is at the end of this post. Also, you can check out w3c.org for more details.
Steve
HTTP 1.1
One thing you have to say about the HTTP developers is that they're modest. The first version of the protocol was number 0.9, and since early in the Web's popular history (since 1995), we've been using the Web through HTTP 1.0. Now, despite a number of extremely important
enhancements--including one that fundamentally changes the nature of the Web's basic request/response transaction--the number of the
proposed newest version is a mere single decimal point higher. Hardly seems right, somehow.
What does seem right is what HTTP 1.1 promises to achieve. Essentially, it strives to reduce the time needed to access Web pages--not by using the anticipatory read-ahead system employed by such packages as Peak NetJet, nor by improving the caching already available in Web browsers, but rather by drastically improving a few key elements of HTTP through having it work more efficiently with the Internet's primary protocol, TCP/IP (typically shortened to TCP). To date, HTTP and TCP have worked together, but not as efficiently as possible. The fundamental problem is this: TCP reaches full data-transfer efficiency only when the connection between client and server is kept open, but the current HTTP insists on closing it after each request.
HTTP works on a request/response basis. When you click on a hyperlink, HTTP opens a TCP connection with the server and requests particular data. The server then responds, and it closes the connection when the request is satisfied. Simple enough, but efficient with at most a
few transactions per Web document. But in the case of a document with multiple graphics or other multimedia elements, the efficiency is
hindered. Each element requires a separate request and thus a separate connection. If the Web document contains ten separate graphics files,
for example (and many have more), at least 11 TCP connections occur, one for the document itself and one for each graphics file. Watch the
status bar on your browser the next time you click into such a site and you'll see these separate connections taking place.
HTTP 1.1 attempts to solve the two main problems that result from Version 1.0's approach. The first problem is that establishing each
connection takes time (and we're all aware that connection attempts aren't always successful), and what's more, each HTTP request must wait for a response before the next request can be sent. HTTP 1.1 deals with this issue by allowing persistent connections--that is, TCP connections that remain open for multiple requests. In the example above, a single connection could handle all 11 requests, closing only when the final request was fulfilled. Current Web browsers and servers will have to be updated to take advantage of this feature, however. A browser will have to include a tally of all requests when it makes the initial connection, and the server must understand that it is not to close the connection until after sending the data for the last request.
FULL TEXT AT:
zdnet.com |
