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:
Here's a rundown of what each of these improvements means in practice.
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 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.
Ops people will need to upgrade their Web servers. Web servers will need to be upgraded to support HTTP/2. Support for HTTP/2 is still in its infancy, and each major HTTP server is doing so on its own schedule.
Nginx already supports the HTTP/2 precursor SPDY and is planning to add formal support for HTTP/2 by the end of 2015. Microsoft's IIS is set to support HTTP/2 in its next release, bundled with Windows 10 and, one presumes, the next iteration of Windows Server. Google donated its SPDY code to the Apache Foundation, which plans to make SPDY part of Apache HTTPD 2.4, thereby paving the way for HTTP/2 down the line.
Web frameworks will need to be upgraded. Web frameworks that sport their own embedded server must be upgraded as well. If you're deploying with a large, commonly used framework, there's a good chance it already has HTTP/2 support built in, and it simply needs to be enabled by choosing the right library or passing the proper options to it. The popular Node.js framework Express, for instance, already supports HTTP/2, although proposals do not yet appear to be on the table for how to update Python's WSGI standard for HTTP/2.
Just because you upgraded to HTTP/2 doesn't mean other people have. If you're serving a site that pulls in content from third-party providers, such as a Web traffic tracking system, there's no guarantee those connections won't be served over HTTP/1.1. This will, again, theoretically make your site load slower than if you had been using HTTP/1.1.
HTTP/2 won't add encryption for you. Even if we didn't live in a post-Snowden world, mandating encryption for HTTP connections everywhere would in theory make it far harder to get away with many common kinds of attacks carried out via HTTP. In fact, there was discussion early on in the proposal process to make HTTP/2 connection encryption mandatory, but it lost out for a variety of reasons.
That said, the browser makers -- Firefox and Chrome in particular -- have elected to support HTTP/2 only over connections where TLS is present. Thus, to get the most out of HTTP/2, you're best off deploying it with an encrypted connection, lest the people who'll most benefit from it end up never using it. If the cost of a certificate is a stumbling block, the EFF and Mozilla are at work on a plan to provide free encryption certificates for all sites that want it later this year -- right around the time HTTP/2 itself has become a full-blown entity.
This is only the beginning
It's true that we're a little ways off from these issues. Many conditions still have to be satisfied: support on the client, support on the server, and support on all the infrastructure in between -- a tall set of orders to fill. Only then will we witness how HTTP/2 performs in the real world, with all the unexpected network congestion, buggy implementations, and ad hoc solutions that comes with the Web.
Old-school HTTP/1.1 won't completely disappear for a long time. The infrastructure that emerges will have to deal with both standards side-by-side, in much the same way browsers had to be compatible with HTML 4, XHTML, and HTML 5.
HTTP/2 is no panacea. In the long term, there were likely be an attempt to address what HTTP/2 itself couldn't -- or wouldn't -- touch, such as encryption by default. Some harsh criticisms have arisen over the way HTTP/2 dropped support for security by default, but it's possible that moving from HTTP/2 to HTTP/3 will make it far easier to support secure connections as a standard -- and with HTTP/2 itself the fallback for situations where that isn't possible.
For Web engineers, one of their next missions will require keeping an eye on how HTTP/3 -- whenever it arrives -- can advance the state of the art for all Web users, as elegantly as possible. But in the short run, they'll have their hands full, both making the switch to HTTP/2 and working with everyone else doing the same.