HTTP is Getting SPDY

On New Year's Day, I found myself explaining to an old friend how the web works. The question started with "so ... what do you do exactly?" and after explaining Aten's process and talking about TCP/IP, I ended up talking about the address bar in her browser, and explained what happens when she opens "http://example.com/page.html". The first thing that happens is a DNS lookup. But after that we got into HTTP, which is always fun to explain because it inevitably elicits an "aha!" moment from people who have seen "http://" thousands of times and never knew why. HTTP is the foundation of the web. It's so pervasive that we tend to not even think about it, even as web professionals who work with it all day. And because we rarely need to think about it, few of us have noticed that it's starting to be replaced. Remember when Folgers did those "let's see if they notice" commercials (and spoofs)? Google is doing that right now, with the whole web. But instead of replacing your favored coffee with Folgers, they're replacing your favored HTTP with SPDY. What is SPDY? The goal of SPDY is to do what HTTP does, but faster, hence the name (pronounced "speedy"). You haven't noticed it because it doesn't exactly replace HTTP. Instead, it uses HTTP (more specifically, HTTPS) and makes some slight alterations to the way HTTP requests are sent. So your browser looks and works exactly the same, just faster. SPDY uses a combination of compression, multiplexing, and prioritization to significantly reduce both actual and perceived waiting when loading websites. Let's start with compression. Gzip is an encoding commonly used to make data smaller. Netscape 5 was the last browser that didn't support gzip compression. But because HTTP was created before Netscape 5, every browser still has to say that gzip compression is supported on every request. They do this in HTTP headers, with Accept-Encoding: gzip. SPDY improves this by assuming everything is gzip, which not only removes the overhead of saying "I support gzip," but also allows headers themselves to be compressed with gzip. Next, multiplexing. With HTTP, every resource is a separate request. Your browser says "I want this HTML document," and then it gets it and sees all the images referenced and it says "I want this image" and "I want that image" and "I want that other image," all completely separate requests. SPDY allows all these requests to be combined in a single "I want all these images." This is faster not only because it's less to say, but also because it allows servers to send a combined result, rather than processing each request individually. Finally, prioritization allows browsers using SPDY to say "I want these images, but this one first." If you're showing a rotating slideshow, for example, you want to show the first image as quickly as possible and the other images can wait their turn. You don't want to wait for every image to load before you show anything. This isn't really a use case anyone had in mind when HTTP was created, but it's incredibly common on today's web, so SPDY enables it. This makes the initial page load appear faster, because it can happen with only the minimal resources required, while additional elements follow. You're probably wondering now where you can see all that speed in action. If you're spending any significant time on the web, you've very likely already seen it. As I said before, Google is pushing SPDY. All of Google's server's today return 90% of responses over SPDY (so they can compare to the other 10%). And Google's browser, Chrome, sends requests over SPDY to capable servers. Firefox has also supported SPDY since version 15. So if you're using either of those browsers (and if you're not, you should be) and you're visiting Google sites (and if you're not, how?), you're using SPDY. If you'd like to see this in action beyond speed, you can peak under the hood of both Chrome and Firefox. In Chrome, you can see all your SPDY connections at chrome://net-internals/#spdy. In Firefox, inspected HTTP responses using SPDY will have an added X-Firefox-Spdy:3 header. It's not only Google servers doing SPDY today, so you may be surprised by how much of your web traffic is no longer using simple HTTP. SPDY, like HTTP, is something we can (and do) generally ignore. It should just work. But also like HTTP, SPDY promises to impact the way we work on the web in unplanned ways. Many of the features in SPDY designed for speed have some potentially large side effects. SPDY-enabled capabilities like server push, DNS over HTTP, and bandwidth throttling are just starting to be explored. These ideas will likely end up changing the web far beyond speed improvements. It's exciting that over 20 years after HTTP was created, the web has made such huge progress, but we're only barely getting started on the next big step. Interesting times ahead.

Photo used under Creative Commons license from U.S. Navy