Seven no-bull facts about the new HTTP/2 protocol

The long-awaited revision to the venerable (and aging) HTTP protocol is finally here. Here's what's most important, what's to expect, and what to brace for

http web globe finger internet browser

After more than 15 years, the HTTP protocol -- arguably the most important Internet standard apart from TCP/IP itself -- is receiving a long-overdue upgrade.

What the IETF (Internet Engineering Task Force) described as "more than two years of discussion, over 200 design issues, 17 drafts, and 30 implementations" has resulted in HTTP/2, a new wire protocol for more efficient and network-friendly delivery of Web pages.

Here are seven key details about HTTP/2: where it came from, what it's all about, what it means to the user and the IT admin alike, and where it's likely to go.

1. It was all Google's idea (sort of)

Google's already deployed SPDY protocol ended up being the starting point for HTTP/2 -- another sign we're living in a world where an open source implementation of an idea carries far more weight than any number of standards on paper.

Though a small number of people were already deploying SPDY in production, there's a big difference between a de facto standard as proposed by a company like Google and a genuine standard as ratified by a group like the IETF. The IETF moving forward from Google's code to a standard that anyone can implement independently was a huge and crucial step.

2. It's the network protocol that's new, not HTTP itself

The biggest difference between HTTP/2 and its predecessors is the bundling and transmission of HTTP across the network. According to the official HTTP/2 protocol page, "HTTP methods, status codes, and semantics are the same, and it should be possible to use the same APIs as HTTP/1.x (possibly with some small additions) to represent the protocol."

The wire protocol -- the way the actual bits are sent across the network -- is different now. Where HTTP 1.x was a text-based protocol and only worked via one connection at a time, HTTP/2 is binary and can multiplex connections. But all that happens at the network level; applications that read and respond to HTTP requests and responses won't have to change anything.

3. You can finally kiss a lot of old HTTP speed tricks good-bye (and good riddance)

One of the touted advantages of HTTP/2 is faster connection speeds -- you no longer have to open multiple connections for the sake of, say, downloading all the elements on a given page. For Web designers and application developers, this is good news. It means stand-on-one's-head-and-wave-a-dead-chicken speed tricks like CSS spriting or inlining should become passé.

4. We'll need new tools; fortunately, they're on the way

Now the bad news: Because HTTP/2 is binary, a lot of old-school ways of debugging HTTP connections are also out the window. That means no more popping open a telnet session and manually instigating a connection to a remote server. What's more, the actual work involved will also be trickier. "Debugging an encrypted, multiplexed session in a single TCP connection is a lot harder than debugging HTTP/1.1," said Owen Garrett, head of product at Nginx, in an email.

On the other hand, upgrades to the needed tools shouldn't be far off. Protocol analyzers like Wireshark are already getting upgraded to handle HTTP/2, and higher-level tools like the network connection inspector in Chrome should continue to work transparently.

5. The front end will catch up far faster than the back end

"Web users largely will be able to benefit from the improvements offered by HTTP/2 without having to do anything different," the IETF has said. That is, Chrome, Firefox, and the rest of the world's browsers (perhaps even IE) will support HTTP/2 in short order, thanks to their rapid update cycles.

It'll take longer for the servers of the world to catch up, mostly because admins need to roll out updated versions of the servers -- not due to lack of support for the server software. Apache is likely to add HTTP/2 to its HTTPD server via Google's mod_spdy project (SPDY was HTTP/2's predecessor). Nginx, long a supporter of HTTP/2, has already carried support for SPDY (albeit in an "experimental" implementation) and is set on rolling out HTTP/2 sooner rather than later.

6. Encryption won't be mandated, but maybe that's not so bad

One proposal floated early in the draft process was having HTTPS, not HTTP, as the default connection type for HTTP/2 -- in effect, encrypting connections by default.

Unfortunately, always-on encryption creates a host of unforeseen problems: What happens to caching in public proxies, for instance? What about older hardware that uses HTTP and can't be upgraded? What about performance implications? A surprising number of political issues are also attached to the problem, as outlined in an article for the Association for Computing Machinery by Poul-Henning Kamp. (Exercise for the reader: What happens if you try to enforce encryption for connections coming from a country with stiff laws against it?)

Mark Nottingham, chair of the IETF HTTP Working Group, felt it was better to make the use of encryption more appealing on HTTP/2, instead of strong-arming HTTP/2 users into using encryption. Politics aside, he wrote, "HTTP is a deployed protocol with lots of existing stakeholders, like proxy vendors, network operators, corporate firewalls, and so on. Requiring encryption with HTTP/2 means that these stakeholders get disenfranchised."

Garrett concurs on this note: "The decision not to mandate encryption as part of HTTP/2 was most likely about giving choice to the site owner," he wrote. "If you want broad adoption of a standard, it probably makes sense to let the user decide. The onus is then on the site owner to understand the benefits of encryption and the risks of not implementing."

7. Expect the evolution -- and the criticism -- to continue, for the good

The decades-long lag between versions of HTTP made it feel like the protocol didn't need to evolve to meet the times. But every protocol, every standard, every implementation is always a work in progress. HTTP is no different, and now that it's been dislodged from its legacy roots, it'll be easier to make future iterations.

Given all the furor erupting around the nuts and bolts of networks now -- Net neutrality, security and privacy, the desires of users versus the ambitions of companies -- the fact that the HTTP protocol is able to respond to changing times is nothing but good news.