cancel
Showing results for 
Search instead for 
Did you mean: 
Login & Join the DevCentral Connects Group to watch the Recorded LiveStream (May 12) on Basic iControl Security - show notes included.
Dawn_Parzych_20
Altocumulus
Altocumulus

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.  

 HTTPSPDYByte Savings
https://.../SitePages/Home.aspx291792914930
https://.../_layouts/1033/core.js844578441146
https://.../_layouts/sp.js718347175183
https://.../_layouts/sp.ribbon.js5799957827172
https://.../_layouts/1033/init.js4205541864191
https://.../_layouts/images/fgimg.png2047820250228
https://.../_layouts/images/homepageSamplePhoto.jpg1693516704231
https://.../ScriptResource.axd2785427617237
https://.../_layouts/images/favicon.ico57945525269
https://.../_layouts/blank.js496221275

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. 

 

0151T000003d6BFQAY.png

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.  

Comments
Kari_Hurtta_375
Nimbostratus
Nimbostratus
> Now onto the SSL component. HTTP/2 requires strong crypto HTTP/2 for "https:" -urls requires: 3.3. Starting HTTP/2 for "https" URIs http://tools.ietf.org/html/draft-ietf-httpbis-http2-13section-3.3 9.2. Use of TLS Features http://tools.ietf.org/html/draft-ietf-httpbis-http2-13section-9.2 But there is also 3.2. Starting HTTP/2 for "http" URIs http://tools.ietf.org/html/draft-ietf-httpbis-http2-13section-3.2 This does not include crypto (but perhaps do not work with proxies). / Kari Hurtta
Kari_Hurtta_375
Nimbostratus
Nimbostratus
Seems that comments do not preserve newlines (and this does not mention that html tags are used).
JG
Cumulonimbus
Cumulonimbus
The version of curl on v11.6.0 still does not support http/2.
Haarith_Devaraj
Nimbostratus
Nimbostratus
Is there a way to implement this profile on Version 10 through iRules
Spann_191147
Nimbostratus
Nimbostratus
This is Manse What is it still boasts some of the blow off top but, yeah, self-publishing definitely takes a lot bigger than you. Star Wars, I am. And takes care of. Laughter out of the park baseball 14 keygen, crack, cheat I'm not playing hide-and-seek.
JG
Cumulonimbus
Cumulonimbus
The version of HTTP2 contained as at v11.6.0 HF5 is no longer supported by most browsers, and I could only get it work on one version of Chrome.
JG
Cumulonimbus
Cumulonimbus
It works now with Firefox 41.0, which has just been released. Cool!
Version history
Last update:
‎19-Jun-2014 08:16
Updated by:
Contributors