What are you waiting for?

The future of HTTP is here, or almost here.   It has been 5 years since SPDY was first introduced as a better way to deliver web sites.  A lot has happened since then. 

• Chrome, Firefox, Opera and some IE installations support SPDY.
• SPDY evolved from v2 to v3 to v3.1.
• Sites like Google, Facebook, Twitter, and Wordpress to name just a few are available via SPDY.
• F5 announced availability of a SPDY Gateway.
• The IETF HTTP working group announced SPDY is the starting point for HTTP/2.
• And most recently - Apple has announced that Safari 8, due out this fall,  will support SPDY!  This means that all major browsers will support SPDY by the end of the year.  

By the end of the year all major browsers will support SPDY, and the IETF is scheduled to have the HTTP/2 draft finalized.  This week the IETF working group published the latest draft of the HTTP/2 spec.  The hope is that this will be the version that becomes the proposed RFC.  

The Internet Explorer team  posted a blog at the end of May indicating that they have HTTP/2 in development for a future version of IE, there is no commitment whether this will be in IE 12 or another version but they are preparing for the shift.  We at F5, have been following the evolution of the spec and developing prototypes based on the various interoperability drafts to make sure we are ready as soon as possible to implement an HTTP/2 gateway.   So what are you waiting for, why are you not using SPDY on your site?

Using SPDY today allows you to see how HTTP/2 may potentially impact your applications and infrastructure.   HTTP/2 is not a new protocol, there are no changes to the HTTP semantics and it does not obsolete the existing HTTP/1.1 message syntax.   If it’s not a new protocol and it doesn’t obsolete HTTP/1.1 what is HTTP/2 exactly?  Per the draft’s abstract:

This specification describes an optimized expression of the syntax of
   the Hypertext Transfer Protocol (HTTP).  HTTP/2 enables a more
   efficient use of network resources and a reduced perception of
   latency by introducing header field compression and allowing multiple
   concurrent messages on the same connection.  It also introduces
   unsolicited push of representations from servers to clients.

   This specification is an alternative to, but does not obsolete, the
   HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.

HTTP/2 allows communication to occur with less data transmitted over the network and with the ability to send multiple requests and responses across a single connection, out of order and interleaved – oh yeah and all over SSL.  

Let’s look at these in a little more detail.  Sending less data has always been a good thing but just how much improvement can be achieved by compressing headers.     It turns out quite a bit.    Headers have a lot of repetitive information in them: the cookies, encoding types, cache settings to name just a few.  With all this repetitive information compression can really help.    Looking at the amount of downloaded data for a web page delivered over HTTP and over SPDY we can see just how much savings can be achieved.   Below is a sample of 10 objects delivered over HTTP and SPDY, the byte savings result in a total savings of 1762 bytes.   That doesn’t sound like much but we’re only talking about 10 objects.  The average home page now has close to 100 objects on it, and I’m sure the total number of hits to your website is well over that number.   If your website gets 1 million hits a day then extrapolating this out the savings become 168 MB, if the hits are closer to 10 million the savings nears 1.7 GB.   Over the course of a month or a year these savings will start to add up.  

SPDY performed header compression via deflate, this was discovered to be vulnerable to CRIME attacks, as a result HTTP/2 uses HPACK header compression, an HTTP header specific compression scheme which is not vulnerable to CRIME.  

The next element to examine is the ability to send multiple requests and response across a single connection, out of order and interleaved.  We all know that latency can have a big impact on page load times and the end user experience.  This is why HTTP 1.1 allowed for keep-alives, eliminating the need to perform a three way handshake for each and every request.   After keep alives came, domain sharding  and browsers eventually changed the default behavior to allow more than 2 concurrent TCP connections.  The downside of multiple TCP connections is having to conduct the three way handshake multiple times, wouldn’t things be easier if all requests could just be sent over a single TCP connection.  This is what HTTP/2 provides, and not only that the responses can be returned in a different order in which they were reqeusted. 

Now onto the SSL component.  HTTP/2 requires strong crypto –128 bit EC or 2048 bit RSA.  This requirement will be enforced by browsers and cannot be disabled.   With the ever growing number of attacks having SSL everywhere is a good thing but there are performance and reporting ramifications to encrypting all data.  Organizations that deploy solutions to monitor, classify and analyze Internet traffic may no longer be able to do so.  

All the changes coming in HTTP/2 have the potential to impact how an application is rendered and how infrastructure components will react.   What are the consequences of having all requests and responses transmitted over SSL, can the network support 50 concurrent requests for objects, does the page render properly for the end user if objects are received out of order?  On the positive you could end up with improved page load times and a reduction in the amount of data transferred, stop waiting and start enabling the future of the web today.