December 19, 2015

The World Wide Web. You use it everyday. It might even be as old as you are (born in March of 1989). And it all runs over Hypertext Transfer Protocol.

The first draft of the HTTP specification was pretty simple. Just ~650 words, ~25 lines. Since then we've improved on it with HTTP 1.0 and 1.1. It can stream video and retrieve your email.aspx). We've wrapped some security around it with SSL and now TLS. And now we're moving on to the largest change in the protocol in its history: HTTP/2.

Oooh shiny

In the last 26 years HTTP has enveloped the world. Other protocols such as gopher and FTP have fallen in prominence, and seemingly everything runs over HTTP. HTTP APIs are preferred over all other transports, the Web is arguably the world's largest application platform, and web browsers are the planet's most widely distributed runtime.

HTTP/2 was finalized in May of 2015 in RFC 7540 after ~3 years of work. It builds on an earlier protocol from Google called SPDY. SPDY is due to be deprecated in January 2016.

Changes

The main drive in development of HTTP/2 was performance. With so much of the Internet consisting of Web traffic, optimizations in speed and efficiency would have large payoffs. In addition, end users are shifting to a more mobile (or mobile-only) world of increased latency. Plus, web pages are becoming more and more complex, in both size and composition. Security was also an area of focus, with internet privacy at the forefront of many web users’ minds.

HTTP/2 uses a single persistent connection

Over this single connection requests and replies are multiplexed. Like SSH multiplexing, this means less time spent doing connection setup/teardown. (For instance, SSL handshakes are minimized) It also prevents "head of line" blocking which means one slow request will no longer delay subsequent requests.

HTTP/2 is a binary format. This means it can be extremely fast (think Protocol Buffers instead of parsing XML or JSON). The downside of this is we lose the ability to debug connections with "telnet host 80" and "GET /". But hey, with encryptioneverywhere we couldn't do that anyways, right? If you do need to look at HTTP/2 "on the wire" Wireshark already has a plugin. And for debugging curl 7.43.0 and higher has HTTP/2 support built-in.

TLS Required

Speaking of security, one of the contentious points during the protocol's development was the requirement of transport-level encryption (with TLS). In the end TLS was left as an optional flag; servers are not required to use HTTPS when serving content. However, as it happens, all of the browser makers have agreed to only support HTTP/2 when used over TLS, making it a de-facto standard.

Deployment

And many servers already support HTTP/2. Facebook, Google, and Twitter all already support HTTP/2, enjoying decreased bandwidth usage and better performance, among other benefits. (Oracle, Amazon, Apple, get with it.) If you help maintain a website, consider working with the web developers to upgrade the servers to support HTTP/2.

And surprise: you're likely reading this article over HTTP/2 right now! https://sysadvent.blogspot.com is HTTP/2 enabled. Check your website, courtesy of KeyCDN. You can also install plugins to add handy indicators to Chrome and Firefox. If plugins aren’t your style you can use Chrome Developer Tools (Network - Right click on columns and show Protocol) or Firefox Developer Tools (Headers - Version). Safari and Edge will show it as well.