SPDY and Its Relation to WebSockets
When SPDY was first announced I didn’t pay too much attention as history has shown it takes years before these things become widely adopted, if ever. Recently though, Twitter launched support for the protocol and I noticed (via this Chrome plugin) that quite a few of the sites I visit on a regular basis (mostly Google properties) are actually using SPDY in production.
Interesting. I guess it’s time to pay attention.
My first question, without knowing too much about SPDY, was what its relation was to WebSockets — are they two competing implementations solving the same problem? The short of it is: No, they are complimentary and will coexist. Here’s my best attempt to relate the two:
SPDY is an augmentation to HTTP with the goal of making synchronous HTTP requests faster.
WebSockets is an alternative to HTTP with the goal of facilitating real time communication.
The big point here being that SPDY shouldn’t require too much application-level refactoring, whereas supporting WebSockets means building an application specifically for bi-directional communication.
A word often bandied about is push and it has two different meanings with these technologies.
SPDY Push is a technique where more than just the requested resource is sent down the pipe to a browser, but within the context of a single request. Example: on a given HTML page there’s a good assumption that the corresponding .js and .css and a few images will be requested. SPDY can send all of these in a single request, eliminating quite a bit of RTT (round trip time).
WebSockets Push facilitates asynchronous communication between the server and browser. The server receives new data from another source and rather than waiting for the browser to request the new data, it is simply pushed through an already-open connection.
The two protocols are actually complimentary. WebSockets makes its initial handshake with servers over HTTP to discover if the
ws:// protocol is supported, and one of SPDY’s primary methods of optimization is compressing and caching HTTP request headers.
From the SPDY Whitepaper
Header compression resulted in an ~88% reduction in the size of request headers and an ~85% reduction in the size of response headers… We found a reduction of 45 – 1142 ms in page load time simply due to header compression.
So, in an ideal future the RESTful request-based web is driven by SPDY, and all of the real-time communication and “app-ifying” is handled via WebSockets. Two peas in a pod!