HTTP's Greatly Exaggerated Death By Bruce Robertson   An undertaker's cart moves through the decrepit streets of England in the Middle Ages. Filth covers everything. On the cart lie a few departed souls. Down the street comes a dirty, scrawny, old man with an even dirtier, scrawnier, older man over his shoulder--his father. As he is heaved up onto the cart, the father cries out, "I'm not dead yet!" The son looks at the grave digger and nods, and hastens the father's demise with a club. Imagine this Monty Python scenario played out with Web technologies. It's been only a few years and already the streets are covered in filth. Besides the smut, the Web is littered with sites, cluttered with advertising and generally bloated. This slippery footing presents a very big problem to the network and, therefore, Web applications. Although Internet service providers (ISPs) and carriers continue to shore up infrastructures (America Online is adding mo dems and points of presence, while others like MCI are expanding backbone capacity) or limit subscriptions and raise rates, the applications still use all available bandwidth. Consequently, we see lots of proprietary solutions that are content-centric and middleware- or protocol-centric and that promise to fix the Web's problems--HTTP in particular. I've looked at a few of these in past columns (see "Web Middleware Tolls the Death Knell of HTTP," at techweb.cmp.com/ nc/714/714colrobertson.html and "Still More Web Middleware (Still Less HTTP)," at techweb.cmp.com/ nc/716/716colrobertson.html), and suggested that HTTP may indeed deserve a ride on the grave digger's cart. But is HTTP really dead? Vital Signs Recently, there's been some work on a successor to HT TP (1.0 is described in RFC 1945). Anointed as RFC 2068, HTTP 1.1 offers persistent connections, request pipelining, byte ranges and other improvements, such as hierarchical proxies, caching and virtual hosts. A recent column by Robert Moskowitz focuses on HTTP 1.1 performance enhancements (see "Take Two and Call Me in the Morning," March 15, page 39). He's concerned about the HTTP traffic impact on servers and routers. HTTP 1.1's persistent connections certainly mean that the overhead of re-initiating TCP connections for a multitude of HTTP requests per page is lowered. This means that the cycles and memory resources required to track the highly transient connections are off-loaded from the servers. But I bet we'll also get messages from Web servers in the same way we get them from FTP servers, stating: "No more connections are available, try again later." Is that a good solution? Will this make users happy, or only system administrators? The network load is reduced because retrieving multiple objects (pipelining) over the same connection (in parallel rather than serially) makes it more likely that TCP's normal slow-start windowing behavior will be overcome for data moving toward the client. While existing browsers like Netscape Navigator send up to four parallel HTTP requests, each is conducted over a separate TCP connection with new windowing for each. With requests pipelined over a single TCP connection, rather than starting with a new single packet window for each new object, previous objects may have already widened the window so that a new object may begin downloading with an efficient window size. As more data must be moved to show increasingly slicker pages, optimization of window size pays dividends. Large window size means that more data moves between client and server without waiting for each packet to be acknowledged (ACKed) at the TCP level. Round-trips, or ACKs, kill application performance on high-latency networks. More critically, it means many fewer packets. The World Wide Web Conso rtium's (W3C) recent testing results of the Web certainly shows this reduction for a "typical" single page access (see www.w3.org/pub/WWW/Protocols/HTTP/Performance/Pipeline.html). Over Ethernet, which is characterized by high bandwidth and low latency, HTTP 1.0 required 455 packets, while HTTP 1.1 (with pipelining) required only 168. In a WAN configuration (at T1 speed), version 1.0's 443 packets became 200 packets with version 1.1. For 28.8-Kbps modem connections, 339 dropped to 284. Cache validation packet reduction results were even more drastic: Ethernet went from 362 to 27, WAN from 338 to 28, and modem from 108 to 30. HTTP 1.1 is clearly a much better network citizen protocol than its older sibling.

On The Edge by Art WIttmann FreeWire by Bill Frezza ICorporate VIew by Brian Walsh On The Wire by Bill Alderson and J. Scott Haugdahl Updated May 23, 1997