Firefox 11 Targeted for SPDY Support | Hacker News Reader

Firefox 11 Targeted for SPDY Support

bugzilla.mozilla.org

175 pointsjohnbender39 comments

I like that once again the approach of "build it and deploy something on it" seems to work more effectively than "specify it over a five-year intensive period".

I imagine that's just my inner lazy engineer talking, though; there are some protocols that would definitely have been better off specified properly from the start (I'm looking at you, SMB)

SPDY absolutely was intensively specified: http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-s...

The link above is to a version being specified, not yet deployed. (v3).

Its fair to say that v2 is deployed and was well documented and that google was very responsive to technical inquiries about it. The firefox and chrome implementations are v2.

But open specification is important. Google and Mozilla have been working together to bring this into the IETF.

As mentioned in the bug, this landed but is pref'ed off for now. I don't know what the process is there, no idea when it will be switched on. It might or might not be on for FF11 (which the title of the submission here states).

We've landed an implementation of a draft of the SPDY spec, and that will be available in Firefox Nightly builds [1] tomorrow (or so). In order to test it out, you must change change the network.http.spdy.enabled preference to true in about:config; the default configuration does not have SPDY enabled.

There is no concrete plan for enabling support for any particular draft SPDY spec in any particular version of Firefox yet. There's no way it will be enabled by default in Firefox 11. Our implementation needs a lot more testing, especially since there are already very important SPDY-enabled sites live on the Internet. Even if we spit out a perfect implementation of the latest draft spec on the first attempt, it might be the case that these existing sites depend on behavior undefined by the spec and/or bugs in Chrome. These kinds of issues still need to be found and addressed.

There is also still work that needs to be done on the spec itself. I suspect there will be many rounds of divergence and convergence in SPDY implementations as more people experiment with implementing it, and as the protocol improves.

[1] http://nightly.mozilla.org/ [2] https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&...

> already very important SPDY-enabled sites live on the Internet

Certainly Google's sites qualify as important, but are any other major sites using it? Chrome doesn't seem to setup SPDY sessions for anything I visit regularly other than Google sites.

I'd also like to know.

BTW, I heard an unsubstantiated rumor Netflix has added SPDY, although this might be due to the Chromebook plugin.

While also Google products, Google analytics (ssl.google-analytics.com) and their ajax cdn (ajax.googleapis.com) both support it. Lots of other sites rely on those.

> Firefox 11 Targeted for SPDY Support

Apologies, but I'm not seeing where that suggests that it will be on by default.

Most people reading the headline would interpret it that way.

This is great news! Now we just need better support for SPDY web servers..

Edit: This looks promising https://github.com/indutny/node-spdy

Yeah, but you don't need SPDY as much on the application servers as you do the frontline servers (Apache, nginx, lighttpd...) where its benefits are more pronounced.

Excellent point. A SPDY->HTTP proxy or SPDY support in tools like perlbal, squid and Varnish would go a long way.

Apache already has a mod-spdy (https://code.google.com/p/mod-spdy/), and varnish is in wait-and-see mode (https://www.varnish-cache.org/lists/pipermail/varnish-misc/2... "SPDY isn't even an official IETF draft yet")

I agree. Getting SPDY into Apache, ngnix, varnish, squid etc. would be all we need to get the benefits of this new protocol.

The front-end SPDY server could then communicate via HTTP via a low-latency connection.

Nginx reports that it is in the works, but no ETA: http://forum.nginx.org/read.php?2,217299,217325

As an Australian sitting 210ms+ from most web servers I use regularly, this is great news. Muxing all assets for a each page load into a single TCP stream will make page loads oodles faster.

As others have said, this won't help much until common servers (nginx, varnish, etc) also support SPDY, but it's a move in the right direction.

If SPDY is adopted by Chrome and Firefox; Google and Facebook; and Apache, ngnix, varnish, and squid, then HTTP's days seem numbered.

Not if you are behind some nasty corporate squid gateway or limited http channel to get online.

To clarify, SPDY started at Google (in Chromium) http://www.chromium.org/spdy

Google made SPDY and it's already in Chrome. Gmail and some other of their services use it.

https://www.google.com/ for a little thing called "google search" using spdy!

Spdy actually shines brightest on things like plus.google.com or picasa because of all the little icons.. images.google.com is also a very big beneficiary.

It would be an excellent fit for things that look like facebook, ebay, twitter..

And how is IPv6 adoption coming along?

Compared to spdy, it is standing still.

Google exposes a lot more services to IPv6 than SPDY, though traffic might be another matter. I am merely poking fun at any hopes of a replacement, for as long as HTTP still works; even a protocol with a death warrant and a significantly better alternative doesn't get displaced but merely coexists. On the other hand, SPDY can be enabled on the edges, and become useful without waiting for network support.

Considering that SPDY requires SSL/TLS and therefore the webmaster will have to get and set up a certificate for his domain, I bet most websites will use HTTP for years to come.

There was some discussion about using self-signed certs with SPDY which would be treated as insecure (no lock). I don't know if a decision has been made.

SSL rules remain the same, and SPDY runs over SSL.

My opinion - get a real signed cert. A basic free one from startssl.com is available.

The PKI has problems to be sure and needs to evolve. But simple forms of eavesdropping and MITM attacks need to stop. Its great that SPDY is SSL based.

It's not about the money. As patrick said you can get free certs from StartSSL, and companies like namecheap offer 1-year free certs if you buy a domain. It's about 1) lack of knowledge, 2) lack of support by shared hosting companies and 3) laziness.

That was my point; the server could automatically generate a self-signed cert even if the administrator is lazy or ignorant.

Someone in that thread mentioned that SPDY is used to achieve the speedups in Amazon's Silk browser. It does look like we're seeing the beginnings of something big.

Haven't all the benchmarks shown that Silk is actually slower?

In any case, I'd imagine the benefits are from the cloud caching than any other factor.

Do you have links on that? Legitimately curious.

Anandtech did a good rundown:

http://www.anandtech.com/show/5139/amazons-silk-browser-test...

Yes, but that doesn't necessarily mean it's SPDY's fault. I think SPDY has a pretty small impact. The biggest slowdown comes from routing the whole site through Amazon's servers in the first place, and then converting it to whatever file it sends to the tablet. So it happens that just connecting directly to the site is faster. Clearly Amazon is not as experience in this as Opera with Opera Mini/Turbo.

If you want the web to be "speedy", use less javascript.

What does the SPDY protocol do that the SSH2 protocol doesn't aside from being completely HTTP-specific?

This seems to me to be yet another unnecessary new protocol.

Unless you're talking about some SSH2 completely different from Secure Shell Protocol v2, then I think you need to read up on SPDY... If you are, please correct me.

Browsers aren't going to implement both SSH and SSL, since that doubles security surface area. You could rip out the mux layer from SSH and run it over SSL, but that doesn't sound any easier than SPDY. And SPDY has special HTTP header compression.

Doubles? TLS/SPDY barely registers in the vast expanses of attack surface that all the browser supported protocols, media formats, flash, javascript etc expose.

Reply on news.ycombinator.com