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.
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:
#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.