6 ms·

Firefox 11 Targeted for SPDY Support

175 points by johnbender 15y ago

thurn 15y ago
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 15y ago
  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 15y ago
    Do you have links on that? Legitimately curious.
    - untog 15y ago
      Anandtech did a good rundown: http://www.anandtech.com/show/5139/amazons-silk-browser-tested-less-bandwidth-consumed-but-slower-performance http://www.anandtech.com/show/5139/amazons-silk-browser-test...
  - nextparadigms 15y ago
    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.
dhotson 15y ago
This is great news! Now we just need better support for SPDY web servers.. Edit: This looks promising https://github.com/indutny/node-spdy https://github.com/indutny/node-spdy
- LeafStorm 15y ago
  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.
  - dhotson 15y ago
    Excellent point. A SPDY->HTTP proxy or SPDY support in tools like perlbal, squid and Varnish would go a long way.
  - wycats 15y ago
    Apache already has a mod-spdy (https://code.google.com/p/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/2011-April/006084.html 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.
  - pingswept 15y ago
    Nginx reports that it is in the works, but no ETA: http://forum.nginx.org/read.php?2,217299,217325 http://forum.nginx.org/read.php?2,217299,217325
andrewgodwin 15y ago
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 15y ago
  SPDY absolutely was intensively specified: http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-s...
  - patrickmcmanus 15y ago
    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.
dlitz 15y ago
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.
- ComputerGuru 15y ago
  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.
- wmf 15y ago
  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 15y ago
    Doubles? TLS/SPDY barely registers in the vast expanses of attack surface that all the browser supported protocols, media formats, flash, javascript etc expose.
azakai 15y ago
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 15y ago
  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/ http://nightly.mozilla.org/ [2] https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Networking https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&...
  - nknight 15y ago
    > 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.
    - DiabloD3 15y ago
      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.
itechnofuture 15y ago
Thanks for nice info
cpeterso 15y ago
If SPDY is adopted by Chrome and Firefox; Google and Facebook; and Apache, ngnix, varnish, and squid, then HTTP's days seem numbered.
- est 15y ago
  Not if you are behind some nasty corporate squid gateway or limited http channel to get online.
- rmgraham 15y ago
  To clarify, SPDY started at Google (in Chromium) http://www.chromium.org/spdy http://www.chromium.org/spdy
- nextparadigms 15y ago
  Google made SPDY and it's already in Chrome. Gmail and some other of their services use it.
  - patrickmcmanus 15y ago
    https://www.google.com/ 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..
- Tobu 15y ago
  And how is IPv6 adoption coming along?
  - eggnet 15y ago
    Compared to spdy, it is standing still.
    - Tobu 15y ago
      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.
RyanKearney 15y ago
Too little too late :)
jhealy 15y ago
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.
J_Darnley 15y ago
If you want the web to be "speedy", use less javascript.

175 points by johnbender 15y ago

thurn 15y ago

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 15y ago
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 15y ago
  Do you have links on that? Legitimately curious.
  - untog 15y ago
    Anandtech did a good rundown: http://www.anandtech.com/show/5139/amazons-silk-browser-tested-less-bandwidth-consumed-but-slower-performance http://www.anandtech.com/show/5139/amazons-silk-browser-test...
- nextparadigms 15y ago
  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.

dhotson 15y ago

This is great news! Now we just need better support for SPDY web servers.. Edit: This looks promising https://github.com/indutny/node-spdy https://github.com/indutny/node-spdy

LeafStorm 15y ago
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.
- dhotson 15y ago
  Excellent point. A SPDY->HTTP proxy or SPDY support in tools like perlbal, squid and Varnish would go a long way.
- wycats 15y ago
  Apache already has a mod-spdy (https://code.google.com/p/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/2011-April/006084.html 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.
- pingswept 15y ago
  Nginx reports that it is in the works, but no ETA: http://forum.nginx.org/read.php?2,217299,217325 http://forum.nginx.org/read.php?2,217299,217325

andrewgodwin 15y ago

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 15y ago
SPDY absolutely was intensively specified: http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-spdy-00.xml http://mbelshe.github.com/SPDY-Specification/draft-mbelshe-s...
- patrickmcmanus 15y ago
  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.

dlitz 15y ago

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.

ComputerGuru 15y ago
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.
wmf 15y ago
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 15y ago
  Doubles? TLS/SPDY barely registers in the vast expanses of attack surface that all the browser supported protocols, media formats, flash, javascript etc expose.

azakai 15y ago

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 15y ago
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/ http://nightly.mozilla.org/ [2] https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Networking https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&...
- nknight 15y ago
  > 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.
  - DiabloD3 15y ago
    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.

itechnofuture 15y ago

Thanks for nice info

cpeterso 15y ago

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

est 15y ago
Not if you are behind some nasty corporate squid gateway or limited http channel to get online.
rmgraham 15y ago
To clarify, SPDY started at Google (in Chromium) http://www.chromium.org/spdy http://www.chromium.org/spdy
nextparadigms 15y ago
Google made SPDY and it's already in Chrome. Gmail and some other of their services use it.
- patrickmcmanus 15y ago
  https://www.google.com/ 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..
Tobu 15y ago
And how is IPv6 adoption coming along?
- eggnet 15y ago
  Compared to spdy, it is standing still.
  - Tobu 15y ago
    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.

RyanKearney 15y ago

Too little too late :)

jhealy 15y ago

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.

J_Darnley 15y ago

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