For those not keeping score, Twitter, and Facebook have both come out publicly in favor of SPDY. Twitter is already using it in production. It sounds like Facebook will be soon. Mozilla implemented it in Firefox. Opera has SPDY. Google, the author of SPDY is using it in production.
This leaves Microsoft and Apple as the holdouts. Microsoft’s HTTP + Mobility is SPDY at it’s core. Microsoft hasn’t started supporting SPDY in any products, but it seems inevitable at some point. They are a holdout in implementation but not opposed to SPDY it seems.
Apple is the last major holdout. SPDY hasn’t been announced for iOS 6 or Mac OS X 10.8. As far as I’m aware Apple hasn’t made any statement suggesting support or opposition to SPDY. However I can’t see why they would oppose it. There’s nothing for them to disapprove of, other than it’s not using their IP. I’d be surprised if they don’t want to implement it.
However given SPDY is a rather backwards compatible thing to support, I don’t see this holding back adoption. Nginx is adding support for SPDY (thanks to WordPress creator Automattic), and Google is working on mod_spdy for Apache. That makes adoption for lots of large websites possible.
While the details of SPDY and the direction it will go are still in flux, it seems nearly certain that SPDY is the future of the web. Time to start digging into how to adopt it and ease the transition. The primary concerns I see are as follow:
- TLS Required – While not explicitly required, SPDY essentially builds on TLS and virtually any real world application needs it. This means purchasing SSL certificates for any website you wish to use SPDY with. Some have argued performance and scalability, but Google, Facebook and Twitter use SSL extensively on commodity hardware.
- IP Address – Unless you use Server Name Indication (SNI), which almost no websites do because of compatibility, you need an IP address for every hostname that you use TLS with. That means until IPv6 is widely adopted, it will be putting further strain on the remaining IPv4 pool.
Both of the above concerns increase complexity and cost of building websites at scale and for those who are on a very tight budget (the rest of us will manage). Because of this, I don’t think we’ll see a 100% SPDY or HTTP 2.0 web for quite some time. Don’t expect SPDY for shared hosting sites anytime soon.
In a world of increasing surveillance and user data being integrated into everything, the benefits of TLS will be realized. Both Facebook and Twitter acknowledge it’s importance in preventing user data from getting into the wrong hands.
I, For One, Welcome Our New SPDY overlord.
7 replies on “Full SPDY Ahead”
Wouldn’t any client that supports SPDY also support SNI? So you’d only have to worry about having an individual IP address if you were supporting https TLS *and* SPDY, right? If you were just supporting SPDY, you could rely on SNI.
You’d loose backwards compatibility. For example a non-SPDY/non-SNI capable browser accessed a site with IP based hosting would still get SSL over HTTP. The site would load fine. If you’re using SNI and that same client accessed it, it wouldn’t work.
IP based hosting is almost 100% ironclad. SNI isn’t. You’d have to sacrifice some of you’re audience.
SNI is widely deployed.
In fact the only (current, largeish) audience you might loose is Internet Explorer (any version) on Windows XP.
Android / Blackberry might be concerns in the future, but it is not clear what % of users *only* use those browsers.
SNI is widely deployed.
For the unusual case of Android 2.x and Blackberry; they can always use the unencrypted site. Given that phones has a 6 – 9 month life-cycle, the phone problem will solve itself by the end of the year.
Windows XP has entered extended support, it is completely de-supported in 2014. Also, anyone on Windows XP using *any* *other* *browser* can use SNI.
You forget lots of corporate “security” proxies MITM users and have their own root cert installed on desktops. Not all of these support SNI (similar problem for http pipelining). These would all break.
Lastly, no dropping XP isn’t an option in the US yet. Lots of corporate and even some gov usage.
There are two issues here.
1. Windows XP
IE on Windows XP does not support SNI.
Firefox on Windows XP works.
Chrome on Windows XP works.
Chrome frame on Windows XP works.
Opera on Windows XP works.
Safari on Windows XP works.
If a corporate / government has felt it necessary to tie themselves to a particular IE version for a particular application – they are just as likely to have (at least) one other browser installed.
ALSO Windows XP, itself, will not be supported for Corporates / Government from Aug 2014.
Less than 2 years away.
2. MitM / Proxy
MitM / Proxy bring up a different issue. I’m not familiar with them, so I would have assumed that a CONNECT call will pass the hostname through to the origin server?
If that is how they work (I’m speculating), then it will not actually even matter if the actual client (e.g. IE on Windows Xp) supports SNI – since the MitM / Proxy may do it for them.
I’d would love to see *any* data on this to backup what you’ve indicated.
Do you have links on how they work; or which support (do not support) SNI?
Phones usually have 2 years life cycle – that’s the typical contract time at this moment. And Android 2.x is on the majority of the phones, 4.0 has about 10% market share.
Windows XP + IE is also a significant share. So, until 2014 I don’t think it’s feasible to assume that SNI is widely deployed – not widely enough.
1. Mobile life-cycle.
The life-cycle of a phone and the contract length are wholly separate.
If you look at the phones on offer from your carrier today, record the devices. Now go and look in 6 months time. They will be different.
Remember the customer for phones are the carriers — that is why *they* and not you get to decide what is pre-installed.
2. Mobile browsers.
Whilst Android 2.x has a majority market share, the great thing about Android is that you can not install another browser. Everything is locked down.
You can install another browser.
Both Firefox and Opera exist for Mobile devices. Both of them support SNI.
3. Windows XP + IE market share.
According to Wikipedia, “As of June 2012, Windows XP market share is at 26.2%”.
And according to Wikipedia, the current average of IE marketshare is ~30%
So, that equates to roughly 7.86% of Windows XP users using IE who can not use SNI.
And, of course, the possibility exists that they might use any other browser on Windows XP and they all support SNI.
Anyway, I’m bored of proving my point.
SNI can already be widely deployed, and is.
You can find reports citing the deployment of SNI, I’ll leave that as an exercise for further commenters though.