Facebook endorses Google's SPDY networking protocol
SPDY, short for "speedy," is a faster and more secure successor to HTTP that Google, Facebook and Twitter have adopted.
Facebook has settled on a networking protocol for speeding up web content delivery. In a W3 mailing list post titled "HTTP2 Expression of Interest," Facebook engineer Doug Beaver outlined why the company has started implementing the SPDY protocol, which is not an acronym but just a short version for the word "speedy," and why it is not interested in HTTP Speed+Mobility or Network-Friendly HTTP Upgrade.
"We at Facebook are enthusiastic about the potential for an HTTP/2.0 standard that will deliver enhanced speed and safety for Web users," Beaver writes. "Of the three proposals, we recommend the use of SPDY as the basis for development of the HTTP/2.0 specification, but feel that the requirement for a secure transport must be added. We plan to continue developing and optimizing our HTTP, TLS, and SPDY implementations and are deploying them on a global scale. We look forward to sharing our experiences with the community."
SPDY was developed primarily at Google. Assuming you're loading a Web page that supports it, SPDY improves browsing in two ways: it's a more secure successor to HTTP because it forces SSL encryption for all sites, and it's faster.
In fact, SPDY is part of Google's wider "make the Web faster" effort. SPDY speeds up browsing with multiplexing (multiple streams of data can be sent over a single network connection), the ability to assign high or low priorities to Web page resources being requested from a server, and compression of header information that accompanies communications for resource requests and responses.
OK, now that you have the background, let's get back to why Facebook wants to get SPDY, and why it matters. This is a huge win for SPDY because the social network happens to be the world's most popular Web site (Google and Hitwise).
"We currently are implementing SPDY/v2, due to the availability of browser support and the immediate gains we expect to reap," Beaver writes. "Although we have not run SPDY in production yet, our implementation is almost complete and we feel qualified to comment on SPDY from the implementor's perspective. We are planning to deploy SPDY widely at large scale and will share our deployment experiences as we gain them."
It's also worth noting there is another social network that is not only backing SPDY but has already implemented it on its Web site as of March 2012: Twitter. You can read Twitter's response to the discussion, also posted today, here: Fwd: HTTP2 Expression of Interest [twitter].
While Facebook is already implementing SPDY, the company is still looking for improvements and has declared it wants to help move the technology along. While the company isn't 100 percent satisfied with SPDY, the conclusion of the mailing list post is a positive one.
Here's Facebook's full explanation as to why it's going with SPDY:
We are implementing SPDY and plan to deploy it widely in two roles: speaking HTTP directly to users and enabling faster communication between geographically distant Web servers on our network. Of the three proposals, we believe it is the best basis for further work due to the variety of client and server implementations, its proven usage at large scale, and its full support for our HTTP 2.0 criteria.
Assessment using our criteria:
Additional considerations:
Of the three HTTP/2.0 proposals, SPDY currently is the one with the largest user base, due to its inclusion in Firefox 13 and Chrome.
SPDY's header compression is a good, general-purpose solution, and gzip is a good starting point, but we would prefer to see a more lightweight compression algorithm for the HTTP/2.0 standard.
As Facebook mentions, SPDY is of course supported by Google's browser. It was added in Chrome 11, released in April 2011. Given that Chrome is on version 20 now, it's safe to say that essentially all of Chrome's users have SPDY support thanks to the browser's automatic updating system.
As for Mozilla's browser, SPDY support has been added to the most recent version: Firefox 13, which was released just last month. As more and more Firefox users upgrade, the world's third most popular browser will soon be onboard as well.
As you can probably guess, the biggest hurdle for Google's SPDY is Microsoft's browser. The company isn't interested the option as it has developed its own: HTTP Speed+Mobility.
This is where things get interesting. Not only has Menlo Park, Calif.-based company thrown its support behind SPDY, despite that fact it was developed by Google, arguably its biggest competitor, but it has made a point to say that it's better than HTTP Speed+Mobility, which was developed by Microsoft, one of Facebook's key investors. You can read for yourself:
We have not implemented HTTP Speed+Mobility, and we currently do not plan to implement it. There is no sizable deployment of either clients or servers, and it is missing features we feel are required.
Assessment using our criteria:
Additional considerations:
HTTP Speed+Mobility's dependence on the HTTP Upgrade header is a problem for us because it adds an additional network round trip in a very common use case: loading several small, static resources from a CDN. Section 1.4 of the HTTP Speed+Mobility proposal notes the need to tunnel the WebSockets stream over TLS when there is an "incompatible proxy" (i.e. a proxy not known to support HTTP/2.0) between the client and server. We agree, and therefore the following comparison uses TLS:
- SPDY: 4 x RTT minimum elapsed time to fetch N resources on a new connection (without TLS session resumption or False Start) : TCP handshake plus 2 RTT for TLS handshake with NPN, plus 1 RTT to fetch the resources.
- HTTP Speed+Mobility: 5 x RTT minimum elapsed time: TCP handshake, 2 RTT for TLS handshake, 1 RTT to fetch the first resource via HTTP/1.1 with "Upgrade: websocket," and 1 RTT to fetch the remaining N-1 resources.
Ouch. I have to applaud Facebook here. The social networking giant is choosing the technology it actually believes is better and is making a point to ignore its relationships with those who developed each. That's a level of maturity that even Google and Microsoft often fail to display.
Updated at 11:25 a.m. PT to correct reference to version of Chrome.