HTTP's Greatly Exaggerated Death
Fewer TCP connections also reduce the deluge of TCP session setup packets that are not subject to network congestion control. Once connected, however, TCP flows are easily slowed down or sped up, letting routers manage congestion better.
Clearly, HTTP 1.1's persistent connections and pipelining do offer some relief. I certainly believe that, taken alone, HTTP 1.1 is a big improvement.
Protocol Performance=User Performance?
But, will HTTP 1.1 need to go it alone? If so, it won't be to the satisfaction of all constituencies. Unfortunately, while good for IT professionals and ISPs, this HTTP protocol update may not translate to better performance for users.
Another analysis of H
TTP performance argues that though there are packet reductions, user response time might not be drastically altered for its most typical configuration: 28.8-modem connected (see "An Analysis of HTTP Performance," at www.isi.edu/ lsam/publications/http-perf). For realistic improvement for users, the au
thors of this study suggest halving the time for a transaction as a goal.
Indeed, the W3C results are much more response-time efficient on bigger pipes (for example, 1.2 seconds down to .69 for the same page on Ethernet, 4.8 down to 2.8 on WAN). On the modem results, 58 seconds dropped only to 52--this is far from "twice as fast." (On cache validation, it's more than twice as fast: 14 down to five seconds). The upper boundary is influenced by bandwidth, not just latency. Latency responds very well to fewer packet round-trips, but you can move only so much data over a 28.8-Kbps modem link--no matter how many packets it takes.
Is most traffic to new pages, where modem-connected users won't see a big change
? Or, is it revalidating the cache of already-viewed pages? Or viewing pages with large amounts of data per page? Or small amounts of data? What's needed is more work monitoring real Web traffic. Unfortunately, it's likely to change over time, so theoretical gains on paper may not make for good results tomorrow in real networked configurations. Still, even if HTTP 1.1 doesn't necessarily help users, it does try to help the infrastructure supporting them. It will mean more users are served with the same resources--not necessarily faster per user, but more users.
Beyond protocol enhancements, application changes aim to improve things even more dramatically. For example, the Web world is considering style sheets, dynamic HTML and even more efficient graphic format compression options.
Style sheets and better compression algorithms will reduce the amount of data transferred between a client and a server. The W3C paper also examines proposed changes in these areas and computes that the sample page would sa
ve half of the HTTP requests (any version) while "providing almost another factor of two beyond that provided by persistent connections and pipelining."
Dynamic HTML will change traffic by increasing the amount of data transferred for a given page. For a richer user experience, the page might come with
lots of data that's not initially viewable on the screen, but revealed by user navigation. For example, an outline could be downloaded in full but not expanded. Later, as the user clicked on a topic, the outline would expand for the user without requiring more trips back to a server. This would be true as well for a large query result set. Whole new pages could be downloaded at first touch and revealed later without accessing the server again.
The impact is clear: Once Netscape, Microsoft and the standards community get dynamic HTML standardized, designers will likely create bulkier pages. Modem users won't see help here; more data, no matter how compressed, means slower pages.
Moreover, such a l
arge but single page is a single object download, and thus, wouldn't get big benefits from the persistent TCP connections and request pipelining of HTTP 1.1 (unless the big parts of dynamic HTML pages were separate items like inline images or other URLs). Bigger objects would get even regular HTTP 1.0 sessions into efficient windowing performance. So, if more pages go bigger in single objects, HTTP 1.0 will do just fine (see "Still More Web Middleware" at techweb. cmp.com/nc/716/716colrobertson.html).
Better Off Dead?
In the end, HTTP 1.1's success will depend on its adoption by vendors, users and developers alike. Content providers (application developers) don't have to modify their applications to take advantage of it, but how long must they wait?
Microsoft and Netscape plan to implement HTTP 1.1 in their next server and browser product releases, yet HTTP protocol replacement solutions (such as IBM's new Business Quality Messaging, called MQware, based on MQSeries) or content aggregation a
pproaches (dynamic HTML) will be as likely to prove useful. Most assuredly, we'll see lots of options and lots of confusion over what the right thing to do will be.
HTTP is going to recover from some of its problems, so let's not kill it yet. HTTP 1.1 will grow up as more products and users implement the new pr
otocols. But let's also carefully look at all innovative solutions--protocol and application enhancements--to assess the impact before rushing to implement.
Bruce Robertson is program director with the META Group's Global Networking Strategies service. He can be reached at Bruce.Robertson@metagroup.com.
|
REPORTS
ANALYTICS
Follow 
