News Archive
PhpRiot Newsletter
Your Email Address:

More information

This site now runs on SPDY

Note: This article was originally published at Planet PHP on 21 June 2012.
Planet PHP

SPDY?ASPDY is an aoupgradea to HTTP 1.1 proposed by Google to circumvent some of the shortcomings of HTTP 1.1. It's one of the canditates for aoHTTP 2.0a 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 aofakea 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)Aand 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 criticismsA 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 aoold HTTPa 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 ^/*(.*)$$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

Truncated by Planet PHP, read more at the original (another 2758 bytes)