While architects have only ivy to cover their errors, programmers have next year's hardware. Today's dreadfully slow and inefficient software becomes tolerable with the next generation of computers and networks.
The World Wide Web is a case in point. Right now, even if you're using a high-end Pentium and have a T-1 line running into your bedroom, the Web can seem overloaded and painfully slow. According to conventional wisdom, the solution lies in new network technologies like ATM and fibre optics - technologies that are still a few years away. Fortunately, there's another solution: improve the software. Change how we use the network to squeeze out every last bit of performance.
Researchers are investigating two main techniques for speeding up the Web: "caches" and optimised protocols. Based on the tests and simulations done so far, both methods will dramatically improve Web response times. It's a telling example of the kind of inherent inefficiencies that are routinely hidden by fast hardware.
The easiest way to improve Web performance is to not use the network at all. That's the idea behind caches, which store nearby local copies of frequently accessed data. For example, browsers such as Mosaic and Netscape remember the last few websites you've accessed. This way, if you go back to a page, the data can be read straight from memory instead of from a computer across the world. This helps, but the ideal caching scheme would also store the pages you are most likely to visit, not just the ones you have already seen.
That's why researchers are building caching schemes that operate farther downstream - at special geographically distributed caching points or at Internet service-provider nodes. Prodigy, for example, provides Web access to thousands of users. Since many are interested in the same sites - such as www.yahoo.com and www.penthouse.com - Prodigy keeps copies of them in a cache. When someone requests a popular page, Prodigy can immediately send out its local copy.
But caching has one nagging problem. If the content of a website changes frequently, the cached version will quickly become out of date. So, to make sure users always receive the current version of a page, some sites send a special note that says, in essence, "Don't cache me." In which case you're back to using the network again.
This is where optimised protocols come into play. The idea is to change how computers communicate on the Web to minimise pauses, stutters, and false starts. After all, using the Internet isn't just a matter of shouting, "Hey, A HREF="HTTP://www.hotwired.com">www.hotwired.com, shoot me that gif!" The Net has rigid protocols that define how to communicate. Not just one, either, but a stack of protocols, each relying on the one underneath.
For the Web, the top of the stack is HTTP, the hypertext transfer protocol. It specifies the operations specific to the Web, such as hyperlinking. Below HTTP is TCP (transmission control protocol), which acts as a traffic cop for reliably sending and receiving blocks of data. And below TCP is IP (Internet protocol), which provides the basic service of moving data packets across the Net.
Protocol stacks make it easy to create new application protocols, since all the building blocks are provided. But building with prefabricated parts can be dangerous: if you don't have an understanding of how each piece works, you can end up with unexpected inefficiencies. Just look, for example, at what happens when you point your Web browser to www.hotwired.com/index.html.
The client, in this case your browser, first opens a TCP connection to www.hotwired.com. Once the connection is established, the client sends an HTTP request for the specified file. After the data comes back, the client closes the TCP connection. Then, the entire process is repeated six times to fetch the six gifs used by index.html.
Sure, it works. But too much time is spent murmuring polite hellos and goodbyes rather than transmitting data. This kind of handshaking, which exposes the latency of a network, is exactly what good protocols try to avoid. As network designers like to say, you can buy more bandwidth, but you can't change the speed of light.
Part of the problem is that HTTP opens a new TCP connection for each request. This requires the client to send out a connection request and then wait for an acknowledgement to return. That's an extra handshake for each hypertext object.
A second problem is more subtle. To prevent a host from being flooded with more data than it can handle, TCP uses a technique known as slow start. At first, TCP allows only one packet (usually 536 bytes) to be sent in a single burst. The amount slowly increases, until a maximum limit is reached or the receiver complains. Unfortunately, because HTTP connections are so short-lived, they are usually in the slowest possible mode.
Luckily, a proposed standard called HTTP-Next Generation addresses these problems. Developed by Simon Spero at Enterprise Integration Technologies, HTTP-NG uses a single, persistent connection so that the cost of opening a connection is paid only once and the effects of slow start aren't nearly as painful. The result? Improvements in the order of 400 percent. Pretty impressive for a modification that doesn't entail millions of dollars of hardware.
This is not to say the physical infrastructure of the Internet doesn't require an upgrade. It does. But by improving the Web's software instead of waiting for the deus ex machina of progress, we can make sure we get every last mile out of today's - and tomorrow's - technology.
Steve G. Steinberg (steve@wired.com) is a Wired US section editor.