The Internet has Upgraded to HTTP/2, but One Key Feature will Slow You Down

Imagine a world where smartphones were only upgraded every 15 years.  It is hard to imagine waiting that long for new hardware and new functionality to meet consumer expectations and demands.  It is even harder to imagine how the update will integrate all the changes in the way people utilize their smartphones.

Until recently, the primary protocol for Internet traffic, HTTP, was last updated in 1999.  In May of this year, 2015, RFC7540 was published updating the HTTP standard to HTTP/2.  HTTP/2 incorporates a lot of features to improve performance and delivery of content based on how web content has evolved from static text-based pages to media-rich interactive sites that contain over 1.5MB of content among over 100 objects.

Unfortunately, a key feature of HTTP/2, encryption, will SLOW down your web surfing activities for the foreseeable future.  This is because HTTP/2 supports and encourages the use of encryption.  While HTTP/2 does not require encryption, most client implementations only support HTTP/2 over TLS, making encryption a de facto requirement.

Why Does Encryption Affect Web Performance?

It is not because of the initial thought that encryption requires more compute to generate keys and encode/decode content.  The problem is that most of the optimization technologies that are used on the Internet, do not support the optimization of encrypted traffic.

Looking at some of these technologies, this can be broken into two broad categories.  All of these technologies are based on the premise that they have access to unencrypted content and the ability to manipulate and/or store this content.

First, there are solutions that optimize traffic based on the type of content being sent.  This includes compression technologies for static text and images.  This also includes solutions that optimize streaming content such as video and audio compression technologies.  Since all of these technologies are based on understanding and manipulating the content, they are unable to do anything for content that has been encrypted.

Second, there are solutions that cache content for better delivery such as CDNs.  These cannot handle encrypted content as well, unless the application provider is willing to give the CDN an SSL certificate for their site so that the CDN can act as an SSL proxy to cache decrypted content.  If this arrangement has not been established, then the CDN provides no benefit.  And, from a security perspective, the CDN is essentially a MITM for the encrypted communications, which might not be a good thing.

This means that to properly take advantage of the performance benefits of the new HTTP/2 standard, all of these manipulations need to occur at the HTTP/2 server, or more likely, at the HTTP/2 gateway.  ADCs can serve as an HTTP/2 gateway providing transition services to translate HTTP/2 to HTTP 1.1 or HTTP 1.2.  While the ADC is acting as this gateway, it is possible to deliver enhanced services to enable the web performance optimization (WPO) services that HTTP/2 is designed to deliver.

Until most of the servers on the Internet are HTTP/2 compliant (which will most likely take a while), keep in mind that HTTP/2 is a great step forward, but there some other aspects of the Internet that need to be sorted out to make everything play together nicely.