

Firefox 11 Targeted for SPDY Support - johnbender
https://bugzilla.mozilla.org/show_bug.cgi?id=528288

======
andrewgodwin
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)

~~~
wycats
SPDY absolutely _was_ intensively specified: [http://mbelshe.github.com/SPDY-
Specification/draft-mbelshe-s...](http://mbelshe.github.com/SPDY-
Specification/draft-mbelshe-spdy-00.xml)

~~~
patrickmcmanus
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.

------
azakai
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).

~~~
briansmith
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&...](https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Networking)

~~~
nknight
> _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.

~~~
stock_toaster
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.

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

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

~~~
LeafStorm
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.

~~~
wycats
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...](https://www.varnish-
cache.org/lists/pipermail/varnish-misc/2011-April/006084.html) "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.

------
jhealy
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.

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

~~~
icebraining
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.

~~~
wmf
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.

~~~
icebraining
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.

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

------
thurn
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.

~~~
untog
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.

~~~
DavidChouinard
Do you have links on that? Legitimately curious.

~~~
untog
Anandtech did a good rundown:

[http://www.anandtech.com/show/5139/amazons-silk-browser-
test...](http://www.anandtech.com/show/5139/amazons-silk-browser-tested-less-
bandwidth-consumed-but-slower-performance)

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

------
dlitz
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.

~~~
wmf
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.

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

