Facebook announces SPDY support

http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0251.html

by igrigorik • 14 years ago

120 44 14 years ago

lists.w3.org

mcpherrinm• 14 years 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• 14 years 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).

snprbob862• 14 years 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.

mnutt2• 14 years 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".

kristofferR• 14 years 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• 14 years ago

IP issues will go away when IPv6 catches on and things like this will only increase adoption.

tonfa3• 14 years ago

What is the IP issue with SPDY?

rachelbythebay• 14 years ago

I'd hope that anyone speaking SPDY would also be SNI-capable, thus negating the usual need for one IP+port per certificate.

Granted, it does nothing for your older non-SNI browsers, but they won't be speaking SPDY or HTTP/2.0 or whatever it winds up being called.

http://en.wikipedia.org/wiki/Server_Name_Indication

arunoda• 14 years ago

Yes you are so correct.

SPDY is for the future.

Getting a SSL certificate is not a big issue and not too costly. And for blogs and simple websites SPDY adds less. So don't implemmnt it.

So why anyone needs to worry?

cbr• 14 years ago

On spdy-dev they considered adding SNI to the spec as a requirement but didn't:

https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/...

(At this point implementing SPDY without SNI would be kind of absurd, but it would be spec-conforming.)

notatoad• 14 years ago

Android browser supports SPDY but doesn't support SNI.

icebraining2• 14 years ago

You already have to provide such personal information to register a domain, it's not a new development.

pgeorgi• 14 years ago

I hope that deployment of SPDY with smaller sites (and the problems that appear with that) might help kill the CA extortion scheme in favor of something decentralized (convergence.io is one experiment in that direction).

Every mass hoster (incl. those $9/mo PHP hosts) is affected eventually...

quonn• 14 years ago

SNI or a dedicated IP is not required if you use a single certificate with multiple domain names.

Also you don't really hand over more sensitive personal details than you already provide to most web hosting companies. The only additional requirement was a copy of my personal id.

Finally, Chrome does support self-signed certificates authenticated using DNSSEC and there is work going on to make that a standard (DANE).

Tobu2• 14 years ago

Preventing intermediate routers from screwing with the protocol is a higher priority. Microsoft already has an embrace-extend-extinguish proposal aimed at mobile networks, and that could easily make the protocol unusable. The websocket handshake required a ridiculous number of iterations to not trigger bugs in middleboxes. As a nice side effect, encryption everywhere removes some of the payoff for traffic interception by ISPs, like BT's attempted deployment of Phorm adware.

jedberg3• 14 years ago

The problem is the conflation of security and identity. You need security to guarantee identity, but not the other way around. I see no reason that we can't have encrypted connections without identity.

Ssh has basically solved this. If you're like 99% of ssh users, you just accept the key the server gave you without verification. Your browser could do the same on the web -- just accept the server certificate and then indicate to you that the connection is secure but the servers identity is not verified.

This solves pretty much all the issues you bring up.

And if http 2 required it,then even better, because all the server would support it and all the clients would too.

emmett• 14 years ago

That solution simply does not work. If your browser will accept the certificate that the server presents, anyone can pretend to be anyone and your browser will accept it. Enforcing identity is just as important as encrypting the connection.

You can do that identity enforcement through some scheme (accept-first-time, or web-of-trust, or something else) but they all have significant downsides. It's not an easy problem.

yuhong2• 14 years ago

Yea, Microsoft Speed+Mobility don't have the SSL requirement, because it is based on WebSockets which already have done the work (masking etc.) to deal with bad middleboxes. And SPDY and WebSockets was developed at the same company (Google), yet it is MS that realized both can be combined together.

yuhong2• 14 years ago

In fact, looks like WebSockets was developed by Ian Hickson at Google, while SPDY was developed by Mike Belshe at Google: http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00 http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-...

sathappan2• 14 years ago

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

ehsanu1• 14 years 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.

sathappan2• 14 years ago

That's great.. Looking forward to it..

rmc• 14 years 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• 14 years ago

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

Tobu2• 14 years 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/

eliben• 14 years 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• 14 years ago

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

jebblue• 14 years 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• 14 years 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!

tonfa3• 14 years ago

I thought they released ssl for custom domains at IO.

nuclear_eclipse• 14 years 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• 14 years 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/

Facebook announces SPDY support

Related Stories