The current HTTP/2 adoption and the quite recent history

As of December 2019, HTTP/2 is used by 42.5% of the top 10 million websites¹. Officially standardized, in May 2015, HTTP/2 has had much success in helping the web forward. It is however worth noticing that HTTP didn’t stop evolving upon the release of HTTP/2, and that there is a draft for the the next major version HTTP3. In this article, we will examine the background of the most recent major change, and why HTTP/2 came to be.

The quite recent history of the HTTP/2 protocol

Since the first implementation of the HTTP standard in the 90’s, not a lot changed for a while in the way communications were handled on the Internet. While many adjustments and tweaks were developed to solve potential issues and improve the overall user experience, the core base of the protocol remained unchanged for over 15 years. But following the release of Google’s SPDY alternative to HTTP 1.0 in 2012, HTTP/2 was developed and implemented in 2015 to standardize many of the advances.

The implementation of a decade’s worth of changes

The Hypertext Transfer Protocol (HTTP) is the foundation of data communication for the World Wide Web. It’s through this protocol that web browsers are able to interact with web servers. Originally launched in the early 90’s as the version 0.9, HTTP received a few revisions until the release of HTTP/1.1 in 1996. This version was the standard all the way until 2015, and it was clear that a new version was needed due to many factors:

• People spend more time on mobile devices, which required more optimizations to save data and battery as well as improved methods to reduce the utilization of hardware resources.
• The global Internet infrastructure had changed a lot: while many people had incredibly fast Internet speeds, others struggled to have a decent online experience in wireless networks.
• In a world more interconnected than ever, security concerns had became much more important.

While there were tweaks on the previous HTTP iteration to handle these issues, the aim of HTTP/2 was to standardize the methods with a focus on simplicity, high performance, and robustness. And despite the high number of changes that HTTP/2 brought to the table, the goal was to keep the transition smooth. This meant that a majority of the technologies were to be retro-compatible, so that there would be no need for end users or companies to make drastic changes on their infrastructures. HTTP/2 was more of an extension of HTTP/1.1 rather than a replacement.

A new set of features

HTTP1.1 was limited to processing only one outstanding request per TCP connection. Browsers were then forced to open multiple TCP connections, which could cause network congestion and redundancy issues. HTTP/2 on the other hand supports multiplexing. As a result, the server can send data to the client through multiple streams over a single TCP connection. The data is then reconstructed on the client side. This is a much more efficient approach than having multiple data frames sent one after another over a single stream, with a delay between each frame.

This approach is taken even further with the utilization of binary data instead of text. This reduces the size of the transmitted data and improves the overall reactivity without relying on “hacks” such as image sprites, concatenation and domain sharding, among others. Binary data is also less prone to errors and eliminates the security concerns associated with the textual nature of HTTP1.x, such as response splitting attacks.

Server Push is another interesting feature. It allows the server to send additional cacheable information to the client that isn’t requested but is anticipated in future requests. This mechanism saves a request-respond round trip and reduces network latency. As a built-in security mechanism, the server must be authorized to push the resources beforehand. Therefore, the server can multiplex pushed resources along with originally-requested information within the same TCP connection, which the client can then use across multiple pages. While similar Push capabilities were already available with sub-optimal techniques such as Inlining to Push server responses, Server Push presents a protocol-level solution to make things a lot easier.

While still under work, the stream prioritization concept has a lot to offer. It allows to assign a level of prioritization to specific requests so that the server knows what should be handled first. This could not only drastically improve the user experience by reducing the latency and delivering the most important content first, but also make the resource management a lot better on the server side.

Another big optimization aspect is the stateful header compression. As of today, web servers don’t keep track of the user’s interaction history. Web browsers must therefore send headers packed with a lot of information related to the previous requests. To alleviate this, HTTP/2 implements the HPACK protocol. HPACK compresses the individual value of each header before it is transferred to the server, which then looks up the encoded information in a list of previously transferred header values to reconstruct the full header information. On top of providing an extra layer security since hackers can no longer provide fake history information, this approach reduces the request sizes and therefore improves the reactivity.

The upgrade to HTTP/2

HTTP/2 is today available in all popular web servers. It is stable and robust enough to be used in production, and the upgrade process is quite smooth. It is also supported by all modern web browsers: Google Chrome and Firefox have supported the technology for years and Apple added HTTP/2 browser support to the Safari web browser back in 2014. Internet Explorer requires users to run Windows 8 to support the latest application protocol. The same can be said for their mobile counterparts.

From a security standpoint, HTTP/2 supports SSL similarly to its previous iteration. It does however pack some extra features such as fewer TLS handshakes, low resource consumption on both client and server sides, and improved capabilities in reusing existing web sessions while eliminating vulnerabilities associated with HTTP1.x. It’s worth noting that having an SSL certificate isn’t a compulsory step since regular HTTP exchanges are permitted.

It makes no doubt that HTTP/2 is here to stay, and as of December 2019, HTTP/2 is used by 42.5% of the top 10 million websites. There are many reasons for using HTTP/2, including the advances in terms of security, page load speed and overall performance. It also makes the job a lot easier for developers who don’t waste time implementing hacky solutions by putting at their disposal fully-implemented features at the protocol level. All these points make it a solid evolution over HTTP/1.1 and considering how straightforward the upgrade process is, it is clear that in 2019 it has become the world standard for Internet communications. And after an official request to rename HTTP-over-QUIC as HTTP/3 in the end of 2018, the work on the next major protocol update is in the workings.

¹ https://w3techs.com/technologies/details/ce-http2