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.
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.
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.