Home & Office

​How HTTP/2 will speed up your web browsing

Thanks to changes in the web's fundamental protocol, it is going to get faster and safer.
Written by Steven Vaughan-Nichols, Senior Contributing Editor

When the last version of the Hypertext Transfer Protocol 1.1 (HTTP/1.1) was approved in 1999, fast computers were running 500MHz Pentium III chips, Bill Clinton was president of the United States, and software engineers were working hard at fixing the Y2K bug. As for the internet, the US Federal Communications Commission defined broadband as 200 kilobits per second (Kbps), and most users connected to it with 56Kbps modems. Things have changed, and HTTP, the web's fundamental protocol, is finally changing with the times, too.

HTTP/2 in one box.
After more than two years of consideration, the Internet Engineering Task Force (IETF) has finally approved HTTP/2. HTTP/2 is made up of two specifications: The new protocol itself, and HPACK, which provides header compression for HTTP/2. This revised protocol "will help provide faster user experience for browsing, reduce the amount of bandwidth required, and make the use of secure connections easier".

HTTP/2 is based in part on an earlier protocol called SPDY (pronounced speedy) from Google, and takes most of its speed improvements from it. There was never a competition between the two; SPDY is HTTP/2's father, not its rival.

The first way HTTP/2 speeds up traffic is by transferring all data as a binary format instead of HTTP 1.1's four text message styles. Besides making it simpler for web servers and browsers, this new format is more compact, because the more compact a web page is, the less time it takes to be transmitted.

HTTP/2 uses multiplexing. This makes for a more responsive website by avoiding HTTP 1.1's "head-of-line blocking" problem.

With earlier versions of HTTP, only one data request can be handled at a time, even though every time you visit a website, you start from four to eight TCP/IP connections. With HTTP/2, each website only gets one TCP/IP connection, but you can have multiple data requests being dealt with simultaneously. The exact number of parallel streams is determined by your web browser. The net result is a faster, cleaner data connection.

HTTP/2 also includes Server Push, to make data transmissions faster. Today, when you connect with a site, a page's HTML is sent first and then your browser asks for the JavaScript, Flash, images, etc. That's a lot of connections turning on and off just for one lousy page. Now, with Server Push, the server will send a page's full contents, except for what it believes you already have in your local cache.

In HTTP/2, some elements of a web page are also given priority over others. Which ones depends on the browser and the server. The browser "hints" which element should come first -- video, for example, on YouTube -- while the server makes the final call.

Each of those HTTP connections also comes with a header. HTTP is a stateless protocol, meaning that every connection is made up of a request-response pair, without any reference to earlier or later connections. Therefore, each connection must include data about the connection in an HTTP header.

Over time, these headers have become ever larger and more complex. When headers were standardized in 2005, there were already 116 different header fields. All of this had to be sent with every element of every page, and much of it was duplicated information. So, to cut down on the overhead and make pages faster, HPACK compresses the header data.

Doesn't sound like much? Think again. Patrick McManus, a Mozilla platform software engineer, has found that every connection averages 1,400 bytes, and a single page often has at least 80 "assets", each of which requires a connection. Put it all together, and web pages average over 1 megabyte in size.

Originally, HTTP/2 was going to use GZIP for compression. However, an exploit, Compression Ratio Info-leak Made Easy (CRIME), has made streaming compression protocols such as GZIP unsafe. So, HTTP/2 is using a different, less efficient, but safer security method.

Keep in mind that none of these speed boosts will work unless both your web browser and the server pushing a website to you are both using HTTP/2. At this time, most of the latest versions of the top web browsers -- Chrome 40, Firefox 36, Internet Explorer 11 on Windows 10, and Opera 21 -- are implementing HTTP/2 support. The top web servers, Apache, Internet Information Server, and nginx, are also adopting HTTP/2.

Returning to security, as chairman of the HTTP/2 IETF working group Mark Nottingham pointed out, "HTTP/2 doesn't require you to use TLS [the standard form of SSL, the web's encryption layer], but its higher performance makes using encryption easier, since it reduces the impact on how fast your site seems."

Google and Mozilla have already decided that in Chrome and Firefox, they are going to insist that HTTP/2 be used only over TLS encrypted connections. Microsoft has left the door open, but in its beta versions of IE 11, which supports HTTP/2, it is also insisting that HTTP/2 connections be secured.

The reason why encryption isn't being mandated in the specification itself is, as Nottingham explained, "because 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."

While the IETF is washing its hands of deciding whether encryption will be required, the web browser companies are clearly favoring it. The Let's Encrypt initiative, sponsored by Internet Security Research Group (ISRG), is pushing for adoption of encryption everywhere on the web. HTTP/2 will make that a much more practical objective.

So, all this means that the web is going to get a lot faster and a lot more secure immediately. I wish!

As Nottingham put it, "HTTP/2 isn't magic web performance pixie dust; you can't drop it in and expect your page load times to decrease by 50 percent."

Indeed, a lot of websites that optimize their pages for HTTP 1.1, such as Amazon for example, may find that simply changing to HTTP/2 will see their pages slow down. On the security side, many web "middleboxes", such as proxies and firewalls, can't handle HTTP/2. These will need to be upgraded or replaced in many businesses before the new protocol's full benefits can be realized.

Eventually, HTTP/2 will both significantly speed up our web pages and make them more secure. Unfortunately, I don't think we will see HTTP/2's benefits really start showing up until 2016. The standard may finally be ready to go, but implementing it and optimizing for it will take at least another year.

Related stories:

Editorial standards