SPDY

This post is 4 years old. (Or older!) Code samples may not work, screenshots may be missing and links could be broken. Although some of the content may be relevant please take it with a pinch of salt.

I can't help it but to think about Speedy Gonzales when I read about SPDY - you know the charming mouse cartoon character that goes ¡Ándale! ¡Ándale! ¡Arriba! ¡Arriba! ¡Epa! ¡Epa! ¡Epa! Yeehaw!

If you didn't know, Speedy Gonzales is the fastest mouse in all Mexico but of course this article is not going to be about him, but it's going to be about speed, protocols and the web.

SPDY is a networking protocol developed by a few organisations (although most of the development is done by Google) and it's intending to overcome the various challenges posed by HTTP/1.1 - a protocol that is about 15 years old. As you can imagine the internet was a lot different 15 years ago and HTTP/1.0 as well as HTTP/1.1 served their purpose. Back in the day we only had static websites, very basic HTML pages linked together with a few images here and there, some tables and forms. These days we have web applications running sometimes megabytes worth of JavaScript, external CSS files - there's an incredible amount of interaction going on and we of course consume these web applications not only from our computers but from mobile devices.

With ever growing bandwidth speeds as well people have developed very high expectations from websites - there were various studies conducted that measured how much the average user is willing to wait for a website to load - and the results are in the realm of seconds. Generally speaking if a site loads longer than 10 seconds - it's a no go. (This of course excludes people who would wait for their e-mails to load or they are after a specific site). (For further information on this topic I'd like to refer you to this great paper.)

Just imagine a site like Facebook that receives about 757 million loggings in a month - try to imagine how many synchronous HTTP request does this mean? And the issue lies in the word synchronous. Using Chrome's DevTools we can see monitor these synchronous HTTP requests also for a simple site:

You can see the typical waterfall timeline. Each and every CSS file, custom font and JavaScript file gets loaded one by one, one after the other. At a more technical level the following conversation goes on between the browser and the server:

#Request 1:
Browser: GET index.html
#Response 1:
Server: 200 OK

#Request 2:
Browser: GET main.css
#Response 2:
Server: 200 OK

#Request 3:
Browser: GET app.js
#Response 3:
Server: 200 OK

#Request n:
...
#Response n:
...

But of course heavily utilised sites such as Facebook, Twitter and alike don't load for 10-20 seconds, they load pretty quick. How is that possible? And the answer is simple - hacks. There are various ways of shrinking the amount of requests made to the server for resources, some of these include:

minification of CSS and js files
concatenation of CSS and js files
using data-urls for images
using CSS sprites

And yes, all of these techniques are valid but even if we concatenate all our CSS and js files together, we still make a number of HTTP connections to the server. Which leads us to the second problem - congested HTTP (TCP) connections. Every single TCP request has to go through it's handshake cycle which consists of three steps: SYN, SYN-ACK and ACK. Only after the third step is a connection established. There is a congestion control strategy also used by TCP referred to as "slow-start". Modern day browsers either open multiple connections simultaneously or resue one connection for all the files requested from the server but of course this has it's disadvantages as well.

And comes SPDY for the rescue. The good news is that the official HTTP/2.0 specification is based on the SPDY protocol and it will bring lots of enhancements which will hopefully enlighten all web developers as well as end users.

SPDY implements the existing HTTP API which means that there are no code changes required for web developers, your website will run just fine on HTTP/1.1 as well as on SPDY & HTTP/2.0.

SPDY uses only one, single TCP connection between the browser and the server and this connection is going to be multiplexed. What does this mean you wonder?

It simply means that the browser is able to request all resources at the same time and receive the responses in any order. So to illustrate this, let's see how the previous example would look using SPDY as the protocol:

#Request(s):
Browser: GET index.html
Browser: GET main.css
Browser: GET app.js

#Response(s):
main.css 200 OK
app.js 200 OK
index.html 200 OK

In my opinion this is one of the greatest features of SPDY - there are of course many other things in the protocol definition such as the fact that TLS/SSL is now mandatory, every request is gzip-ed by design. In SPDY HTTP requests are processed, tokenised, simplified and compressed - this also means that the requests can be tracked and therefore resending unchanged headers can be avoided.

This will also change quite a few development practices. There will no longer be a need to concatenate CSS and js files for example in my opinion.

SPDY and HTTP/2.0 is a really exciting development and I really hope that the draft specification will be finalised shortly and therefore become the norm. Browsers and servers are already ready for this protocol. The latest versions of all major browsers have already implemented support for SPDY and the web servers are note falling behind either: at the time of writing this article, both Apache , nginx and node.js support SPDY.