Shamus McGillicuddy is a Senior Analyst for EMA and is a featured guest blogger.
The Internet Engineering Task Force (IETF) published HTTP Version 2 (HTTP/2) as RFC 7540 in May 2015, and already several browsers (including Firefox and Chrome) support it. However, adoption of the new web application protocol probably won’t be particularly rapid. In fact, uptake of HTTP/2 might progress at a pace similar to that of IPv6. For many, there will be no compelling reason to implement the protocol, given the hassle involved.
The key benefit of HTTP/2 is improved performance of websites and web applications. HTTP/2 is purely a wire-based enhancement to HTTP, so applications won’t need to be rewritten to use it. However, web servers and browsers will need to be updated. Many application delivery technologies, such as gateways and load balancers, will need to be updated as well.
Some of the features that make HTTP/2 faster may also lead to heavier loads on web servers. For instance, HTTP/2 replaces the ordered and blocking request model of HTTP/1.1 with a multiplex model. Instead of limiting web clients to one request per TCP connection, HTTP/2 allows a client to make multiple requests at once. While this makes HTTP/2 a more efficient wire protocol, it also makes the servers deliver multiple pieces of content at the same time, increasing their workload. This could force application providers to upgrade elements of their infrastructure, especially load balancers and application delivery controllers (ADCs), in order to handle the increased loads.
Encryption is a de facto mandate in HTTP/2 implementations at the moment because all known browser implementations from the likes of Firefox and Chrome only support HTTP/2 with TLS encryption enabled. If you are a web content provider who relies on a content delivery network (CDN) to reduce latency, you will need to share your encryption keys with your CDN providers. While some providers are comfortable doing so, many more are not.
Given these various requirements, many organizations will have to weigh the benefits of HTTP/2 adoption against the costs of implementation. Do the performance improvements make it worth the steps required to support it? This calculation will probably lead many web content providers and enterprises to hold off on HTTP/2 implementation. Improved performance doesn’t always tip this calculation in favor of an upgrade. We’ve seen many organizations hold off on IPv6 uptake, despite that fact that Facebook recently noted that network performance can be 10 to 15 percent faster over IPv6 than IPv4.
Who will be motivated to adopt HTTP/2 early? My first guess is e-commerce companies will as they understand that page load times and speed of web-based transactions are essential to success. If HTTP/2 can increase the number of sales they get per web impression, e-commerce companies will convert quickly.
Online trading services also have a reason to move forward quickly. These companies differentiate themselves with the ability to close a stock trade as fast as possible. HTTP/2 has a role to play there.
Enterprises that support business processes with web-based applications will be a little slower to adopt HTTP/2. Faster web applications might improve productivity, but that’s a soft benefit with a limited concrete return on investment. Instead, these companies will continue to rely on existing optimization methods to get the job done, whether it is a CDN for reduced latency or web performance optimization at the Layer 4–7 services layer for more efficient HTTP/1.1 transactions.
In the meantime, you should watch the spread of HTTP/2 closely to determine when a changeover will make sense for your business. CDNs and big web companies have already rolled out beta support for the protocol. As these early adopters share lessons learned from implementation, you’ll get a better sense of what HTTP/2 will do to your own infrastructure. And you’ll be better equipped to make a decision on the protocol when the time comes.