HTTP/2: The future of the Web demystified (InfoWorld)

Making the most of HTTP/2 will take a lot of work on the part of Web designers, IT admins, and server jockeys. Here's what to expect

Out with the old, in with the new, as the saying goes -- but when it comes to an overhaul of one of the Internet’s most fundamental protocols, what exactly is coming in with the new?

HTTP has done yeoman’s work shouldering the explosive growth of Web traffic since it was first devised. But the truth is HTTP was conceived at a time when the amount of traffic one could expect to get to a given Web server was minimal and sparse. Over time, a real need has arisen to rethink how the Web itself is put together to serve everyone better.

Several changes have been proposed over the years to tune up the Web, one of which was a new version of the HTTP protocol. As of February 2015, we got exactly that. Version 2 of HTTP -- HTTP/2 -- was formally ratified and made into a standard after two-plus years of wrangling, feedback, discussion, and heated contention.

But what does HTTP/2 mean in practical, everyday terms for developers, IT folks, and admins? Here we take a look at the most promising payoffs of the new protocol and, more important, what kind of heavy lifting awaits ahead.

HTTP/2: The most promising payoffs

HTTP/2 aims to provide three distinct advantages over HTTP/1:

1.     To transcend some of the technical limitations imposed by HTTP/1

2.     To avoid many of the security issues that have emerged as by-products of HTTP/1’s design

3.     To improve performance

Here’s a rundown of what each of these improvements means in practice.

 A bandwidth test for HTTP/1.1 vs. HTTP/2. The image is actually a grid of 180 tiled images. When opened over HTTP/1.1, the grid takes 2.19 seconds to load. Note the way each image loads in the timeline, with only a few images loaded at any given time.

New protocol, new possibilities. HTTP/2 enables functionality that simply wasn’t possible with HTTP/1.1. Server push, for instance, allows content to be pre-emptively sent to a client without the need for a request -- say, sending a stylesheet along with a page, without having to place a reference to the stylesheet in the document.

 The same test conducted over HTTP/2. Load time is 400 milliseconds vs. HTTP/1.1’s 2.19 seconds, and many more of the images can be sent in parallel at once. However, this only works for Web pages where every element on the page is served from an HTTP/2-compliant server and the client itself is HTTP/2-compliant.

The best way to deploy these functions is still being determined; server push, for instance, brings with it the risk of wasting network resources rather than saving them if not done properly.

Better protection against HTTP-based issues and exploits. Binary-based HTTP/2 will cut down on the problems that a text-based protocol, like HTTP/1, can introduce. One commonly cited benefit: The binary HTTP/2 protocol will protect against a variety of exploits that, although not too common, can be successfully launched against text-based HTTP/1.

More efficient HTTP connections, on both the client and server. With HTTP/2, only one TCP connection is opened per host; by contrast, HTTP/1 opens multiple TCP connections for parallelism in downloading resources for a page. This shift cuts down on traffic congestion, thereby reducing latency, a source of much of the slowness that plagues Web transfers across even the fastest network connections.

Unfortunately, this change alone won’t speed up Web traffic -- a caveat that sets the tone for much of HTTP/2’s improvements. Because so much of the Web is still built using presumptions of how HTTP/1.1 works, HTTP/2’s approach to TCP connections can only do so much to improve latency on the Web. (More on this in the next section.)

HTTP/2: What you’ll need to brace for

With every major change comes major breakage. HTTP/2 is no exception, and most everyone in IT will be affected by the shift. What’s more, existing issues with site designs may be exacerbated by deploying HTTP/2. In other words, the Web is bound to get worse before it gets better.

Here are the major issues to consider in the run-up to HTTP/2.

Dev folks will need to upgrade their network inspection and management tools. 

The decision to make HTTP/2 a binary protocol goes beyond avoiding text-based exploits. Binary protocols, according to the HTTP/2 FAQ, are “more efficient to parse, more compact ‘on the wire’, and most importantly, they are much less error-prone compared to textual protocols like HTTP/1.x.”

Many old-school gurus are upset about this decision because it won't let them pull some of the nifty debugging tricks they so enjoy. With HTTP/1.x, one could fire up a terminal window, manually initiate a connection to a remote site, and inspect the results in plaintext.

Not with HTTP/2 -- for that, you need a tool that can support the binary-mode connections used by the protocol. Plain-text debugging is out the window. That said, many of the common tools used to debug HTTP connections and networks generally are getting HTTP/2 support in short order. It’s simply a question of when.

Web designers will need to undo optimization hacks.

This is both good news and bad news. Good news: Designers no longer have to bother with acceleration tricks, like CSS sprites, freeing them to concentrate on crafting a good-looking front end.

The bad news is that optimizations already deployed on sites set to receive HTTP/2 traffic will have to be undone. Under HTTP/2, such optimizations hurt performance, not help it. The creators of the H2O Web server have noted “the overhead of transmitting all the images/CSS styles used by the website at once while only some of them is needed to render a specific page [a/k/a ‘spriting’], becomes a bad idea.” Likewise, HTML Working Group member Matt Wilcox asserts, “The best practices of HTTP/1 are harmful in an HTTP/2 world.”

Given how widespread those practices are, it won’t be trivial to roll them back.