HTTP/2 is Awesome. Why aren’t more people talking about it?

If you are reading this, you probably use HTTP nearly every day. It is the basis of the of the world-wide-web, and backbone of most applications we use over the internet. This website, your facebook app and even smart TV’s rely on HTTP to transfer data to and fro.

For such an important protocol, HTTP is pretty long in the tooth in terms of internet technology. Its last major update was HTTP 1.1 which rolled out in 1999. That makes it ancient by web standards. Remember in 1999: the US internet penetration was at 36%, AOL CD’s were still arriving in the mail each month and IE 4 and Netscape Navigator were squaring off for dominance in the great “browser wars”. Things have changed a lot since then.

Thankfully, a major update to the protocol began rolling out to web servers and browsers in early 2015. HTTP/2.

What is HTTP/2?

At first glance, HTTP/2 doesn’t look a whole lot different than HTTP/1.1. In terms of working with the protocol itself, engineers won’t need to change a thing to take advantage of its performance benefits. (phewf!) The request methods are all the same (GET, PUT, DELETE etc) HTTP2 focuses purely on the performance of these requests moving between client and server, and this is where stuff gets pretty cool.

There are far more detailed posts about how HTTP2 differs from HTTP1.1, but from my reading on the subject these are what I find to be the top enhancements:

1.) Multiplexed streams – HTTP 1.1 can only send and request and send data in a single “stream”. This means for every image, css file or font a browser requests, a new TCP connection is established and new request made. These requests would remain open, to waiting for a response. If a browser asked for more than one thing (which it does about 99.99% of the time), multiple TCP connections would be opened, each with its own HTTP stream, each one blocking overall progress as it waits for its resources. To add insult to injury, browsers set a limits on how many connections they will make to a single domain, so developers used workarounds like domain sharding (multiple CDN subdomains) to request more resources at a time. Believe it or not, in the HTTP/1.1 world a best practice is to load 16 images, sharded over 4 cdn domains, with 16 separate TCP connections. This is all very wasteful.HTTP/2 improves this behavior dramatically by multiplexing the streams. This means data can be requested, sent and transmitted all over a single TCP connection simultaneously. The reduction in overhead alone of all the TCP setup and teardown is a big advantage, on its own, but the ability to request and receive HTTP instructions without going into a “WAIT” state is massive, and arguably the biggest benefit of the new protocol.

2.) Server push: The current nature of HTTP is that each and every request goes through a roundtrip pattern like so:

1 – open a new connection.
2 – request the item from the webserver.
3 – receive the data
4 – close connection.

The problem with this pattern is that one resource often spawns requests for others. By the time the browser has loaded the base HTML, step 4 has been completed and it needs to open new connections up for images, css, jss etc, which often in turn spawn MORE requests for more assets. Again, a fairly wasteful process with a lot of back and forth between client + server.Server push allows webservers to pre-emptively send content down the wire, before the browsers even request it. This makes a lot of sense. Instead of the 1 – 4 step process per item, multiple assets and files will be sent back at step 3, reducing the need to constantly run through the full cycle.

Server push is one of the coolest HTTP/2 features, but its rollout seems to have been a bit slower than the HTTP/2 spec itself. (I assume this is due to some major architectural changes certain webservers will need to undertake.) Rollout is pretty mixed today. Nginx only supports server push as part of its paid “Nginx Plus” product. Cloudfront lacks support for Server push, whilst Cloudfare announced support earlier this year. So, YMMV depending on your CDN / Webserver of choice.

3.) Header Compression – HTTP/2 uses HPACK to compress all HTTP headers. This is one of those “well that makes sense” sort of improvements. HTTP sends a lot of redundant headers back and forth, often with only minor changes. In HTTP/1.1 these headers were not compressed. In HTTP/2 HPACK compresses all HTTP Headers and enables both client and server to keep a list of past headers for fast retrieval. This drops a decent sized chunk of data from each HTTP webservers have to deal with, leaving more bandwidth available for the important stuff, and resulting in fast load times and less bandwidth consumption.

4.) Binary – HTTP/2 converts requests and responses into binary before sending it over the wire. Binary protocols are more space efficient, more resilient to loss and have the added benefit of being far more secure. Packet-sniffing a binary protocol is no easy task. So again, data moves slightly faster and bandwidth is reduced.

5.) Baked in, fast TLS: Although the official HTTP/2 spec did not make HTTPS + TLS mandatory for HTTP/2, every major browser implementation did. (Smart move from Google, Mozilla etc. The browser giants want to move us to an all-HTTPS world-wide ASAP.) So with that, HTTP/2 is effectively HTTPS only and uses TLS 1.2.

Now, standard wisdom is that SSL / TLS make sites a little slower due the CPU cycles needed for the encryption and decryption of data, as well as adding even more handshakes into an already wasteful process. But with HTTP/2 this isn’t the case.

HTTP/2 leverages a TLS extension called “ALPN” which reduces roundtrips caused by protocol negotiations using techniques similar to the ones listed above. When a browser sets up a TLS transmission, it lists supported protocols in its first “hello” transmission. When the server responds back to the initial “hello” it does so with the selected protocol, which the browser switches to immediately. Less roundtrips, faster TLS setup.

Additionally, the benefits of multiplexing and server push naturally reduce the handshake chatter and CPU overhead becoming noticeable. Most smartphones nowadays (even on the low end) have processing power to spare compared to their relatively slow data speeds.

So what does this mean for the web, mobile apps and other systems which use HTTP?

HTTP/2 is a major “under-the-hood” improvement which should greatly increase the speed of many content-heavy sites, while also reducing the bandwidth consumed by loading such sites. The TLS dependency may slow adoption in the short-term, but serve as a powerful incentive for webmasters and businesses to switch their entire operations to HTTPS.

As per usual, it’s no magic bullet. Sites which have an excessive number of objects to load on each page or have very large payloads will always be slow (although HTTP/2 would help incrementally)

Web Engineers really don’t need to do much to support HTTP/2 aside from getting their sites ready for HTTPS and ensuring they have supported webservers and CDN’s. Certain time-honored performance techniques like CSS + JS concatenation will probably not be as impactful given the multiplex and server-push technologies HTTP/2 introduces.

Sadly, the rollout will take some time. I was disappointed to see this wordpress site is still being served via HTTP 1.1. Godaddy WordPress hosting seems to be using a fairly old version of Apache Traffic Server (5.3, which does not have HTTP/2 support. HTTP/2 is fully supported with Server Push as of 7.0). C’mon Godaddy, upgrade yer shit!

I’m especially eager to see how HTTP/2 improves performance in developing countries, where mobile data is far more common than broadband, and latencies are often in the 100 – 500 ms ranges. Assuming sites are already optimized, HTTP/2 could make a HUGE impact on these sort of connections where latency and poor radio connectivity increase the delays caused by HTTP overhead.

So to conclude, if you run a website or web application and HTTP/2 isn’t in your roadmap, take a closer look. Most websites will be rewarded received a moderate to substantial boost in performance from the migration, which for most modern web stacks could be completed over a weekend.

The proof is in the pudding: Check out some cool demo’s of HTTP/1.1 vs HTTP/2 performance from here and here.

Do you have questions about HTTP/2, or experience migrating your web app to it? Ask or comment below.