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