6 ms·

Facebook announces SPDY support

120 points by igrigorik 14y ago

mcpherrinm 14y ago
It's great to see how such a fundamental change in how browsers and servers communicate can get rolled out so quickly! I would have guessed that this sort of thing would require many more years of effort than it did. The author of the post, however, does seem to misunderstand SPDY's server push feature. He states that Facebook requires a substitute for long-polling for low-latency message delivery, and seems to think SPDY provides this. Unless I'm mistaken and there's some Javascript API available, server push is merely for cache-priming and reducing latency of requested objects alongside a regular pageload (eg, push the CSS and images along with an html page).
- igrigorik 14y ago
  I believe that comment by Doug is not referring to "SPDY server push" specifically, but is instead making a broader argument for a need to standardize a push mechanism for HTTP 2.0. In theory, SSE/WebSockets should be able to fill in that gap (based on his described use case).
- snprbob86 14y ago
  I think this is a beautiful example of competition at work. Google Chrome enabled them to forge ahead of the other browsers to scratch their own itch. Facebook evaluated their work and it checked out, so it will become the defecto standard as others join in using it. Thus, standardiztions committees avoid clean room engineering and instead formalize proven implementations for broader distribution.
  - mnutt 14y ago
    As a side note, "defecto standard" is a great turn of phrase which seems to never have been used intentionally. Googling it results in pages and pages of very serious documents which intended to use "de facto standard".
    - snprbob86 14y ago
      Really, that was just my iPad and autocorrect, followed by poor editing.
      - mnutt 14y ago
        Yeah, I didn't mean to give you a hard time for the ipad autocorrect, I just thought the end result was funny.
kristofferR 14y ago
Forced SSL is not a problem for big sites like FB and medium size sites, but it is incredibly problematic for the small sites with less than a couple of thousand visitors per month, in effect it means that SPDY (and eventually HTTP 2.0 unfortunately) will remain a bonus for the elite web sites while the majority of the smaller web sites will remain on HTTP 1.1 "forever". Yeah, I'm aware that some providers like StartSSL hands out free SSL certificates, but I don't think it's a good sign of things to come that you need to hand over sensitive personal information in order to use the latest generation of a fundemental web technology. You'll also need a dedicated IP, which costs money and is becoming increasingly scarce and expensive. I actually run a small web host for my clients and all of them have denied my offer to install a free SSL from StartSSL in order to get SPDY because of the privacy concerns and the extra cost of the dedicated IP they're required to get. It's a shame that a large majority of the web sites on the net will become stuck on an old technology just because of an arbitrary requirement for encryption even though they have nothing to secure anyway.
- smiler 14y ago
  IP issues will go away when IPv6 catches on and things like this will only increase adoption.
  - tonfa 14y ago
    What is the IP issue with SPDY?
    - JonnieCache 14y ago
      Serving multiple SSL websites on different domains on the same IP address requires the SNI extension and much fiddling around; it is ill-supported by old browsers. This is needed because with HTTPS, the header that tells the server which site to serve is still encrypted when the server needs to direct the request to the relevant application code. IPv6 will fix this by allowing you to easily give each application on your server its own IP as well as its own domain. This is simply because IPv6 creates a lot more addresses so we won't have to ration them like we do now. Sorry, that's a poorly worded explanation, but its sunday morning. Have a look at https://secure.wikimedia.org/wikipedia/en/wiki/Server_Name_Indication https://secure.wikimedia.org/wikipedia/en/wiki/Server_Name_I...
sathappan 14y ago
That's great news. But why is that FB's SPDY session never gets captured in chrome net-internals?
- ehsanu1 14y ago
  From the link: 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.
  - sathappan 14y ago
    That's great.. Looking forward to it..
- rmc 14y ago
  This HN title is misleading. If you read the article, it says that Facebook have investigated SPDY and plan to roll it out, but haven't yet.
metabrew 14y ago
And here's Twitter's response to the same Expression of Interest too: http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0250.html http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/...
- Tobu 14y ago
  Twitter is already running SPDY, by the way. Here's a Firefox extension that shows a little icon on SPDY-enabled sites: https://addons.mozilla.org/firefox/addon/spdy-indicator/ https://addons.mozilla.org/firefox/addon/spdy-indicator/
eliben 14y ago
It is not what the linked post announces. Quoting: We currently are implementing SPDY/v2, due to the availability of browser support and the immediate gains we expect to reap. 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.
tysons 14y ago
a massive gain for FB would be pushing data to the browser rather than pinging for new data no? SPDY allows this
jebblue 14y ago
I'm actually a fan of the Trac software linked to in the article. It's hard to beat a combined Wiki, source browser and ticket management.
wickedchicken 14y ago
On a side note: if you use Google AppEngine, you already have SPDY support (as long as you visit your app via SSL, which usually requires the .appspot.com domain). Of course, if some services you use aren't served via SSL (I'm looking at you, Disqus!), then you get the big ugly 'mixed content' warning. Moral of the story: if you run a web service with an API or embedded javascript module, make sure the entire stack can be run over SSL!
- tonfa 14y ago
  I thought they released ssl for custom domains at IO.
nuclear_eclipse 14y ago
> "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." What's more lightweight than gzip? DEFLATE?
- reacocard 14y ago
  Snappy is faster than gzip/zlib: "For instance, compared to the fastest mode of zlib, Snappy is an order of magnitude faster for most inputs, but the resulting compressed files are anywhere from 20% to 100% bigger." https://code.google.com/p/snappy/ https://code.google.com/p/snappy/

120 points by igrigorik 14y ago

It's great to see how such a fundamental change in how browsers and servers communicate can get rolled out so quickly! I would have guessed that this sort of thing would require many more years of effort than it did. The author of the post, however, does seem to misunderstand SPDY's server push feature. He states that Facebook requires a substitute for long-polling for low-latency message delivery, and seems to think SPDY provides this. Unless I'm mistaken and there's some Javascript API available, server push is merely for cache-priming and reducing latency of requested objects alongside a regular pageload (eg, push the CSS and images along with an html page).

igrigorik 14y ago
I believe that comment by Doug is not referring to "SPDY server push" specifically, but is instead making a broader argument for a need to standardize a push mechanism for HTTP 2.0. In theory, SSE/WebSockets should be able to fill in that gap (based on his described use case).
snprbob86 14y ago
I think this is a beautiful example of competition at work. Google Chrome enabled them to forge ahead of the other browsers to scratch their own itch. Facebook evaluated their work and it checked out, so it will become the defecto standard as others join in using it. Thus, standardiztions committees avoid clean room engineering and instead formalize proven implementations for broader distribution.
- mnutt 14y ago
  As a side note, "defecto standard" is a great turn of phrase which seems to never have been used intentionally. Googling it results in pages and pages of very serious documents which intended to use "de facto standard".
  - snprbob86 14y ago
    Really, that was just my iPad and autocorrect, followed by poor editing.
    - mnutt 14y ago
      Yeah, I didn't mean to give you a hard time for the ipad autocorrect, I just thought the end result was funny.

kristofferR 14y ago

Forced SSL is not a problem for big sites like FB and medium size sites, but it is incredibly problematic for the small sites with less than a couple of thousand visitors per month, in effect it means that SPDY (and eventually HTTP 2.0 unfortunately) will remain a bonus for the elite web sites while the majority of the smaller web sites will remain on HTTP 1.1 "forever". Yeah, I'm aware that some providers like StartSSL hands out free SSL certificates, but I don't think it's a good sign of things to come that you need to hand over sensitive personal information in order to use the latest generation of a fundemental web technology. You'll also need a dedicated IP, which costs money and is becoming increasingly scarce and expensive. I actually run a small web host for my clients and all of them have denied my offer to install a free SSL from StartSSL in order to get SPDY because of the privacy concerns and the extra cost of the dedicated IP they're required to get. It's a shame that a large majority of the web sites on the net will become stuck on an old technology just because of an arbitrary requirement for encryption even though they have nothing to secure anyway.

smiler 14y ago
IP issues will go away when IPv6 catches on and things like this will only increase adoption.
- tonfa 14y ago
  What is the IP issue with SPDY?
  - JonnieCache 14y ago
    Serving multiple SSL websites on different domains on the same IP address requires the SNI extension and much fiddling around; it is ill-supported by old browsers. This is needed because with HTTPS, the header that tells the server which site to serve is still encrypted when the server needs to direct the request to the relevant application code. IPv6 will fix this by allowing you to easily give each application on your server its own IP as well as its own domain. This is simply because IPv6 creates a lot more addresses so we won't have to ration them like we do now. Sorry, that's a poorly worded explanation, but its sunday morning. Have a look at https://secure.wikimedia.org/wikipedia/en/wiki/Server_Name_Indication https://secure.wikimedia.org/wikipedia/en/wiki/Server_Name_I...

sathappan 14y ago

That's great news. But why is that FB's SPDY session never gets captured in chrome net-internals?

ehsanu1 14y ago
From the link: 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.
- sathappan 14y ago
  That's great.. Looking forward to it..
rmc 14y ago
This HN title is misleading. If you read the article, it says that Facebook have investigated SPDY and plan to roll it out, but haven't yet.

metabrew 14y ago

And here's Twitter's response to the same Expression of Interest too: http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0250.html http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/...

Tobu 14y ago
Twitter is already running SPDY, by the way. Here's a Firefox extension that shows a little icon on SPDY-enabled sites: https://addons.mozilla.org/firefox/addon/spdy-indicator/ https://addons.mozilla.org/firefox/addon/spdy-indicator/

eliben 14y ago

It is not what the linked post announces. Quoting: We currently are implementing SPDY/v2, due to the availability of browser support and the immediate gains we expect to reap. 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.

tysons 14y ago

a massive gain for FB would be pushing data to the browser rather than pinging for new data no? SPDY allows this

jebblue 14y ago

I'm actually a fan of the Trac software linked to in the article. It's hard to beat a combined Wiki, source browser and ticket management.

wickedchicken 14y ago

On a side note: if you use Google AppEngine, you already have SPDY support (as long as you visit your app via SSL, which usually requires the .appspot.com domain). Of course, if some services you use aren't served via SSL (I'm looking at you, Disqus!), then you get the big ugly 'mixed content' warning. Moral of the story: if you run a web service with an API or embedded javascript module, make sure the entire stack can be run over SSL!

tonfa 14y ago
I thought they released ssl for custom domains at IO.

nuclear_eclipse 14y ago

> "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." What's more lightweight than gzip? DEFLATE?

reacocard 14y ago
Snappy is faster than gzip/zlib: "For instance, compared to the fastest mode of zlib, Snappy is an order of magnitude faster for most inputs, but the resulting compressed files are anywhere from 20% to 100% bigger." https://code.google.com/p/snappy/ https://code.google.com/p/snappy/