SPDY?Ā SPDY is an ā€œupgradeā€ to HTTP 1.1 proposed by Googleto circumvent some of the shortcomings of HTTP 1.1. It's one of the canditates for ā€œ HTTP 2.0ā€ and is already supported by Chrome and Firefox. It's goal is to make the web experience faster (and more secure).

The main feature from my point of view is that with SPDY the browser only has to open one TCP connection to the server and all resources are delivered through that connection. No need anymore to ā€œfakeā€ different servers with different hostnames just that the browser fetches more than the default 4 to 6 resources at once from one server. This also saves resources on the server as it also has only to keep one connection open. This especially helps, if you have lots of little resources on your webpage, eg. lots of small images.

SPDY also adds features that a lost package doesn't stop the whole delivery and other requests still can get through fast called multi-plexing (compared to HTTP Pipelining, which is First-In-First-Out) and since everything is going over one TCP connection, SPDY can much better handle congestion and better use the available bandwidth (see also this post for more info)

Furthermore it also compresses the HTTP Headers (something HTTP doesn't by design and can sum up to quite some traffic, especially if you have many small requests)

You don't have to change anything in your websites and web applications to make use of SPDY, only the browser and the webserver have to support it, on the other layers it still works like HTTP.

All this together should especially help on mobile devices, where latency, packet loss and bandwidth still is a problem and any improvements in that area helps a lot in making a more responsive web experience.

SPDY on this blog

There was actually no real need for having SPDY on our blog. We don't have that many requests on a single page to the same server and our server isn't really overloaded with open TCP connection (currently it's an AWS micro instance, not the most powerfull machine in the world ;)). But it is a little playground for us to try out new things, get some experience with those and to be able to make an informed decision if we should/could use them in our projects. So I went ahead.

Google provides packages for Apache SPDY modules, so that was installed fast. But our server was running mod_php5 and that doesn't work very well with mod_spdy (which is somehow obvious, since SPDY just opens one TCP connection for all (parallel) requests, something hard to do with the pre-fork model mod_php5 needs). So I had to move my PHP needs to PHP-FPM and use FastCGI and the Worker MPM of apache. There wasn't anything special I had to do. It's the usual setup of using PHP-FPM with apache (see for example here)Ā and since the mod_rewrite rules still work, I didn't even have to change them. After that and installing mod_spdy_beta.deb I basically had a running SPDY site on our SSL port.

This is also one of the issues and main criticismsĀ  about SPDY. It only runs with SSL (currently). That has the advantage that the future HTTP may be secure by default, but also the disadvantage that you need certificates and all that to set it up. This wasn't difficult for this site since we already had SSL running for the admin interface. The next question was how to bring visitors to the SPDY version of the blog. Just send everyone to SSL didn't sound like a good idea, because with ā€œold HTTPā€ SSL has more overhead in setting up a connection and since you will have many of those connections, that really will be a penalty. One trick is to send the following header to all clients connecting on port 80

Alternate-Protocol: 443:npn-spdy/2

Then SPDY-enabled clients will use SPDY for the upcoming requests. This works fine on Chrome, on Firefox I had the problem that our webfont somehow wasn't loaded and displayed. So I added this to our mod_rewrite rules:

RewriteCond  %{HTTP_USER_AGENT}  Firefox/[0-9]{2}.
RewriteCond  %{SERVER_PORT}  ^80$
RewriteRule ^/*(.*)$ https://blog.liip.ch/$1 [L,R=301]

This redirects all Firefox versions >= 10. to SSL. Not the best solution, since the redirect adds latency, but for the sake of it, it's good enough for me here. I will revisit the webfont issue later, maybe it is indeed a bug in Firefox which will be fixed later.

That was basically it, if you now go to our blog with Chrome or Firefox, you should be served by SPDY. You can check that by installing one of the SPDY indicator plugins ( Chrome, Firefox) or in Chrome go toĀ  chrome://net-internals/#spdyĀ and see which sites you have open use SPDY (twitter and google are 2 major sites already using SPDY).

One thing you have to also keep an eye on is that once you deliver your site in SSL, you should deliver all content over SSL. Otherwise you may get warnings in the browser (I didn't change all the externals URLs in the individual posts on this blog, so you may hit that warning from time to time)

What about nginx?

This all could be done also with nginx (apart from our very customized mod_rewrite rules which prevent a totally easy move), but SPDY support was only published last week and you have to patch and recompile nginx (no binaries yet). Not something I was very keen to do. But support is coming and certainly a standard in the near future.

Outlook

I really hope SPDY (or something similar) will gain widespread adoption in the near future. Everything which makes delivering web resources faster, especially on high-latency, packet-lossy and limited-bandwidth environments is worth pursuing and it's obvious that SPDY does solve some problems in that area (if you ever tried to surf the web on a full Swiss train you know what I'm talking about ;))

And with the compiled packages by google it's easy to set it up on your server, provided you use apache, some fastcgi for PHP and have a decent SSL certificate already (many ifsā€¦). If that's the case, why not playing with it and gain some experience.

I also can't wait the day when varnish supports SPDY natively. There are no plans as far as I know and it doesn't look like they're willing to do it soon. But if it gains more widespread adoption, I'm sure they will support it some day. Until then your only way to have SPDY and varnish is to put an nginx/apache in front of varnish. Which solves the problems mentioned above for mobile networks, but not the ā€œtoo many open connections on the server sideā€ problem. But that's mitigated somehow anyway if you use varnish.

And last but not least, for me as an Apple follower, I can't wait until it's built-in in iOS ;)