First, Google wanted to reinvent email with Wave. Now it wants to reinvent the web protocol and replace it with SPDY.
First Google wanted to change the way we communicate with its Google Wave environment. Now, the Web behemoth wants to make your Internet run faster – and all it's going to take is a new protocol that will fundamentally change the way Web sites are delivered.
Already well known for its game-changing technological innovations, Google this week put up not only a vision for speeding the Web – but published real source code and a draft specification for SPDY (pronounced "speedy"). This new data transport protocol, Google says, has proven capable of pushing Web sites across the intertubes up to 64% faster than HTTP (HyperText Transport Protocol). All we have to do to see those benefits, Google is arguing, is to replace HTTP.
Easier said than done: that's like saying we can communicate faster if we ditch English for Esperanto. Carried along via the Internet's TCP (Transmission Control Protocol), HTTP protocol has been part and parcel with the World Wide Web since its inception. But in laying down its case (white paper, including comparative benchmarks, here [http://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper]), Google argues that HTTP is showing signs of age. Among the issues:
- HTTP can only fetch one file from a server at a time. Modern browsers run up to six simultaneous connections, but the process is still less than ideal. To see why, load a complex Web site and watch the status-bar indicator churn through dozens or hundreds of page elements one after the other.
- HTTP requests must all be initiated by the Web browser; this means servers have no choice but to sit waiting for the client to ask for each individual piece. Think of that old lady counting out $9 in 5c pieces in front of you at the 7-Eleven, and you get a pretty good picture of what's going on.
- HTTP isn't compressed or tokenised, with headers from between 200 bytes to 2000 bytes resulting in lots of wasted bandwidth – and severely impacted performance over modems and slower ADSL connections.
- Data cannot be natively compressed using HTTP, which also has a habit of overcompensating by sending too many packet requests per channel.
SPDY, by contrast allows servers to push down bits of the site it knows the browser will need, much like the gas station attendant helping the customer finish faster by pulling her coins across the counter several at a time. SPDY also compresses headers and data packets, and overcomes HTTP's problematic open design by securing all data and user sessions using SSL. This does, Google concedes, introduce a performance overhead but the company also argues that it improves session integrity and security.
Most important from a speed perspective, SPDY can manage multiple sessions at once – allowing it to pull down content faster in a method not dissimilar to that used by BitTorrent, which transmits large files as loads of tiny packets from many sources.
"We believe that there is much low-hanging fruit to be gotten by addressing the shortcomings at the application layer," Google engineers wrote in its blog. "Such an approach requires minimal changes to existing infrastructure, and (we think) can yield significant performance gains."
And how would you use it? SPDY would most likely be implemented as a new type of Web address. For example, http://apcmag.com would become spdy://apcmag.com. Updates to current browsers – no points for guessing that Google's Chrome may be the first to support it – would allow them to parse a spdy:// address.
Widespread support for SPDY in Apache and other Web servers would make the transition relatively smooth: since the data that comprises the Web sites themselves wouldn't change, the only new technology needed would be a way to detect SPDY compatibility and then the SPDY engine itself.
To hasten the adoption of SPDY, Google has published a draft SPDY protocol specification and released the source code as well.
What do you think? Is HTTP due for a revamp? Is Google the one to make it happen?