Speeding up the Web

Whatever else you may say about Google, it is difficult to make a case that they are just sitting on their hands watching the money come in.  One of their new efforts, part of a group of open-source projects that includes the Chrome browser and the Chrome OS, is an attempt to speed up the Web with a new protocol that Google calls SPDY.

In order to understand what Google is trying to do, it’s useful to take a step back to consider the Hyper-Text Transfer Protocol [HTTP], the basic application layer protocol of the Web.  HTTP was originally conceived for use with hyper-linked text documents, as in Sir Tim Berners-Lee’s original conception of the Web.  To that end, it is a stateless protocol that is focused on clients requesting pages (files) and servers returning them.  This basic job it does very well.  However, the nature of the Web has evolved; a typical request, rather than asking for a single HTML document, may end up asking for many files, possibly including graphics, audio, and video, perhaps from different servers or even different domains.  Basic HTTP provides for a single-threaded connection between server and client; although modern browsers make use of multiple connections, each one is still a FIFO pipe.  Also, all connections must be initiated by the client; the stateless HTTP server has no concept of a browsing “session”, but just processes page requests.  Web “cookies” are used as a mechanism for passing session state back and forth between server and client, but all the knowledge of how to interpret them must reside in the Web application.

HTTP, as noted above, is an application layer protocol, which runs on top of the transport layer Transmission Control Protocol [TCP].  TCP is a connection-oriented network protocol, which provides reliable, ordered delivery of a byte stream between two endpoints (here, the browser and the Web server).  It in turn is built on the Internet Protocol [IP], which transports packets (datagrams) from point to point.  All of this runs on a physical link layer protocol, such as Ethernet.

What Google is doing with SPDY is to introduce a new session protocol that allows for multiple inter-leaved HTTP streams over a single TCP connection.  As compared to standard HTTP, adding SPDY provides some additional basic features:

• Multiplexed Streams:  Requests can be interleaved on a single TCP connection, reducing overhead
• Request Prioritization: Clients can assign relative priorities to different requests
• HTTP Header Compression: Data in the headers, which can become quite large due to the presence of cookies, for example, is compressed for transmission.

SPDY also provides an optional capability for server-initiated streams.  This can be used to implement a “server push” feature, which allows the server to provide the client with content that the server knows will be needed, without having to wait for a client request.  It is also possible to provide “server hints”, which suggest to the client requests it probably should make, while still waiting for the request to send the content.  For initial visits to a site, particularly with slow links, these are potentially very useful.

The use of a session protocol to do this is a fairly clever idea, because it can potentially be implemented incrementally, while still maintaining the conventional HTTP scheme in parallel.  It might be possible to make significant improvements by modifying the lower-level protocols (e.g., TCP), but the implementation would be a major project, since it would touch so many parts of the Internet.

Google’s white paper on SPDY presents some very early test results, which are encouraging.  In download testing, using a sample of 25 from the most popular 100 Web sites, page load times were decreased from 27-43 %.  The benefit appears to be bigger with slower or lower-quality connections.  (This makes sense because TCP re-transmissions have a high overhead.)   Google has also published a draft specification of the SPDY protocol, as well as the source code for the implementation to date.   Ars Technica also has an article on the project (although it incorrectly implies that Google is “ditching” HTTP).

This is an interesting project from a purely technical perspective.  But it also, I think, helps illuminate aspects of Google’s overall strategy, especially in conjunction with some recent announcements about the Chrome OS project, which I’ll talk about tomorrow.