HTTP/2 Has Arrived (Sort of) – Why do you care?

HTTP/2 – What’s new and why do you care?

Mozilla rolled out Firefox 36 this week and with it included support for the current drafts of HTTP/2 – I don’t mean to geek out too hard here, but it’s kind of a big deal. No, really. Stay with me here!

For almost 16 years now servers have been sending out web content via the HTTP 1.1 protocol as we know it today. The original HTTP 1.1 was officially released back in 1997, but was tweaked and revised and the protocol has remained mostly unchanged since 1999. It has served us fairly well in that time, but in an era where technology is often considered “obsolete” (read: not cutting edge anymore) after just 6-12 months, 15 years is an eternity.

So why do you care about HTTP/2? Because you hate slow websites, because security on the web is in various states of functionality, and because you hate slow websites. Did I mention that you hate slow websites? Okay, just making sure.

HTTP/2 and Loadtime
Graphic credit to kissmetrics.com

As shown in the infographic, researchers have found that a website generally has 3 seconds to display or 25% of visitors will give up by second number 4, and that’s for desktop sites. When you start talking about mobile sites, research shows that if the site doesn’t load within 1 second you’ve lost 16% of your viewers. When I first read that I was initially shocked by the statistic, but when I sat down and really thought about my habits, I was surprised to find that I generally fall into that 3 second window myself: if a site I’ve never been to fails to load in 3-5 seconds I will leave to find another site with the same information. This truth has led to the uprising of Content Distribution Networks (CDNs) and all sorts of clever methods of pushing more data over a hobbled application-layer protocol such as HTTP 1.1.

“The internet is a series of tubes!”

One of the ways performance has been improved in the old protocol is “pipelining” which allows a browser to establish multiple TCP connections per site request which is effective up to a point, but is still prone to troubles such as poor compatibility at the network stack (in some cases) and the fact that this relies on a lot of educated guesswork a.k.a. heuristics to determine which connection should handle what request. I’m a hardware guy first, so here’s an analogy: branch prediction. Branch prediction in CPUs is when the processor makes a best guess as to what the next result of an “if, then, else” command will be and it can give drastic speed increases to a CPU if the prediction logic is very good. No prediction is perfect though and when branch prediction fails there is a non-trivial performance sacrifice due to the failed prediction. The same is true of pipelining in HTTP 1.1, only to a far greater degree since so much of the “prediction” in HTTP 1.1 is simply blind guess-work. It runs a bit along the lines of the scene in “The Princess Bride” where the Man in Black is up against Vizzini in a battle of wits to the death. Vizzini keeps running in logic circles and finally makes a guess which proves wrong and thereby fatal. (Clip for the unfamiliar). Okay, so pipelining isn’t exactly fatal for a website load, but you get the idea: there’s a penalty when it fails.

HTTP/2 introduces the idea of multiplexing, the description for which I’m lifting from the HTTP/2 Github page:

Multiplexing addresses these problems by allowing multiple request and response messages to be in flight at the same time; it’s even possible to intermingle parts of one message with another on the wire.

So if we bring that back to hardware terms then the analog for it would be Hyper-threading. In hyper-threading one CPU core can be used to process different threads of information, generally based upon the readiness of a given thread to access the necessary memory. This allows out-of-order processing to occur and can therefore increase performance in a properly coded program rather significantly. Add to this the fact that HTTP/2 has a drastic reduction in overhead per request and there are real benefits to be seen. Which brings me to the next item of interest.

Work smarter, not harder: or how HTTP/2 learned to stop worrying and love efficiency:

There are a number of ways the HTTP/2 is of benefit to both the server infrastructure in the web client / web server model and the client.

  1. One TCP connection per page potentially frees up a lot of headroom for other TCP connections, such as VOIP or other latency-sensitive TCP applications.
  2. “Server Push” is a method by which the server can predict (generally quite effectively, since it’s the one… well, serving) what the next resources the client will need are. IE: A client must receive and process HTML before it will even request the CSS, images and JavaScript that compose the rest of the site. The server knows all of the resources the client will need to display the page based on a host of other data the client identifies itself with so therefore it can push the required resources to the browser cache before the client needs it, let alone before it requests it. This effectively reduces the overhead when the browser is ready for a resource, which saves a significant amount of time.
  3. Header compression. The TCP protocol uses the “Slow Start” mechanism, effectively limiting the rate of packet transmission based upon the rate of acknowledgement of previous packets. Essentially it starts slow and then ramps up transfer speed once it determines the speed at which it can transmit without causing errors. Headers being the first thing to load on a webpage, they are generally the slowest to load when weighted against their size. The more resources a page has to load, the larger the headers. The larger the headers the longer it takes for the headers to be transmitted by the “Slow start” process. If the headers can be compressed into a much smaller dataset, they can possibly fit in one packet or just a few, instead of dozens. The reduced overhead is pretty significant for regular broadband, but especially so for higher-latency connections, such as mobile or satellite connections. One of the issues with gzipping the headers is the CRIME exploit which I won’t detail here, but basically enables gzipped traffic transmitted over HTTPS and SPDY protocols to be injected via scripts to divulge the plaintext contents of the encrypted data. So the team had to come up with a completely new compression mechanism called HPACK. Time will tell how secure it pans out to be, but it was a major focus of the development of the protocol, so chances are that it is Pretty Goodtm.
  4. HTTP/2 is a Binary protocol, whereas HTTP 1.1 is a textual protocol. And why does that matter? It matters because Binary protocols 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, because they often have a number of affordances to “help” with things like whitespace handling, capitalization, line endings, blank links and so on.1

What do we want? Security! When do we want it? 10 years ago!

The other big benefit above and beyond the speed and robustness that HTTP/2 promises is enhanced security. This is not to say the protocol itself is inherently more secure, but rather that it has the ability to enforce certain security profiles such as the version of encryption, blacklists of known weak cipher-suites, and what extensions can be used. There is also talk about enabling TLS for HTTP, what is called “opportunistic encryption”, though the jury is out on whether that will make it into the final specification or not. HTTP/2 does not require encryption, but when it is encrypted, it should be inherently more secure than current default encryption on HTTP 1.1, where weak ciphers are still allowed.

Conclusion – HTTP/2 is a “very good thing”.

It’s been a long time coming and it’s still not officially here, but much like wireless 802.11ac and 802.11n before it, it can be used before it’s officially completed and it’s already fully baked into Firefox 36 with Chrome/Chromium not far behind. You can actually enable HTTP/2 in Chrome and Chromium (it’s listed as an experimental feature) by browsing to chrome://flags and enabling “SPDY /4”. After a browser restart you’ll be using the current draft of HTTP/2. There are currently only a handful of sites using HTTP/2 to serve content at this time, but Google and Twitter are among them. In my tests Twitter loaded completely in an average of 1.6 Seconds on Chromium Version 43.0.2316.0 with HTTP 1.1. When once Chromium’s cache was cleared and HTTP/2 was enabled, it was down to an average of 1.16 Seconds or about 33% faster. That’s certainly respectable, but Firefox took the cake with an average load time of just .96 Seconds for twitter.com.

In the end we all stand to benefit from this new protocol and thankfully the migration will be transparent, since it will likely take years for an internet-wide changeover. HTTP 1.1 will continue to function as it always has, but sites will start making the move to HTTP/2 at varying levels of adoption once it’s fully ratified; as discussed earlier it’s in the site owners’ best interests and the end user benefits from it as well. I, for one, welcome our new HTTP/2 overlords!

Leave a comment

Your email address will not be published. Required fields are marked *