Of all the exciting stuff that’s happening at Google, one of the things I’ve been most excited about is SPDY, Mike Belshe and Roberto Peon’s new protocol that upgrades HTTP to deal with many of the new use-cases that have strained browsers and web servers in the last couple of years.
There are some obvious advantages to SPDY; header compression means that things like cookies get gzipped, not just content, and mutliplexing over a single connection with priority information will allow clients and servers to cooperate to accelerate page layout based on what’s important, not only what got requested first.
But the the really interesting stuff from my perspective is the way SPDY enables server push both for anticipated content and for handling Comet-style workloads. The first bit is likely to have the largest impact for the largest set of apps. Instead of trying to do things like embed images in
And then there are the implications for Comet workloads. First, SPDY multiplexes. One socket, many requests. Statefully. By default. Awwwww yeah. That means that a client that wants to hang on to an HTTP connection (long polling, “hanging GET”,
<term of the week here>) isn’t penalized at the server since SPDY servers are expected to be handling stateful, long-lived connections. At an architectural level, SPDY forces the issue. No one will be fielding a SPDY server that doesn’t handle Comet workloads out of the box because it’ll often be harder to do so than not. SPDY finally brings servers into architectural alignment with how many clients want to use them.
Beyond that, SPDY allows clients to set priority information, meaning that real-time information that’s likely to be small in size can take precedence on the wire over a large image request. Similarly, because it multiplexes, SPDY could be used as an encapsulation format for WebSockets, allowing one TCP socket to service multiple WebSockets. The efficiency gains here are pretty obvious: less TCP overhead and lowered potential for unintentional DoS (think portals with tons of widgets all making socket requests). There’s going to need to be some further discussion about how to make new ideas like WebSockets work over SPDY, but the direction is both clear and promising. SPDY should enable a faster web both now and in the future.