Google’s desire to speed up the web via a new protocol is laudable, but the SPDY protocol would require massive changes across networks to support

google-logoArsTechnica had an interesting article on one of Google’s latest projects, a new web protocol designed to replace HTTP called SPDY.

blockquote SPDY uses a single SSL-encrypted session between a browser and a client, and then compresses all the request/response overhead. The requests, responses, and data are all put into frames that are multiplexed over the one connection. This makes it possible to send a higher-priority small file without waiting for the transfer of a large file that's already in progress to terminate. Compressing the requests is helpful in typical ADSL/cable setups, where uplink speed is limited. For good measure, unnecessary and duplicated headers in requests and responses are done away with. SPDY also includes real server push and a "server hint" feature.

Having recently emerged from a trip into the world of service-providers and its associated protocols, the description of SPDY immediately brought to mind other asynchronous, message-oriented protocols such as SIP and DIAMETER. It therefore made me seriously consider the kind of massive changes that would be required to support such a protocol across all data center components: security, load balancing, acceleration, web servers, application servers, caches. Basically any network intermediary based on the premise of a strict request-reply, synchronous behavior would likely need radical changes to its core protocol handling systems.


SPDY, as described, is asynchronous and message-oriented. Like DIAMETER, SPDY would allow multiple requests per connection, effectively turning a single connection designed to be used and then closed into a long-lived connection. This is more along the lines of a SIP connection which is initiated and held open until the session is terminated.This is very different from the HTTP model in which connections are opened and closed within fairly short time intervals and are not expected to be held open for exceedingly long periods of time. SPDY thus eliminates the overhead associated with opening and closing many connections and the negative impact that has on application performance.

The current draft of the SPDY protocol states that “from the perspective of the server business logic or application API, nothing has changed”. But from the perspective of the infrastructure that needs to process the protocol, everything changes.