User: Password:
Subscribe / Log in / New account

What's new with HTTP2

Benefits for LWN subscribers

The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!

By Nathan Willis
March 12, 2014

Changing any widely used network protocol is a risky affair—more so with a protocol as ubiquitous as HTTP. But the venerable web transport protocol is expected to see its first update of the century later this year when HTTP2 is slated for release. The new revision can be hard to characterize, since it changes the way HTTP is sent over the wire, but it does not alter the existing HTTP semantics. In essence, the revisions are designed to speed up how HTTP traffic is relayed between clients, servers, proxies, and switches, but to keep intact the format and meaning of HTTP requests and responses. The upshot will be faster throughput, even if few people outside of network operators will see the actual changes to the protocol.

HTTP has not been updated since 1999, when the Internet Engineering Task Force (IETF) published version 1.1 in RFC 2616. Version 1.1, notably, added support for persistent, pipelined TCP connections between clients and servers. Thus, it was no longer necessary to open and close a separate TCP connection for each HTTP request, and clients could send multiple requests without waiting for each request's response before sending the next.

Those changes did a lot to reduce latency in HTTP, and the concepts implemented arose from the real-world problems experienced with HTTP 1.0. The HTTP2 situation is similar; the vendors that make web software and networking hardware—as well as large-scale web service providers—identified a new set of pain points as the World Wide Web continued to evolve. Several players (including Google and Microsoft) started their own research projects to develop improvements, and by 2007 there was enough interest for the IETF to charter a new working group to address a new revision.

The working group is called the HTTP Bis group—where Bis is a perhaps uncommon designation meaning "twice" that is intended to communicate that the group's charter is not to invent new methods or headers, but just to improve on existing HTTP functionality. The notion that HTTP2 is semantically compatible with HTTP 1.1 is clearly important to the project. The group has recently taken to calling revised protocol HTTP2 or HTTP/2, rather than "HTTP 2.0," just to make such a distinction more prominent, although there is not yet universal agreement on the point.


The most recent HTTP2 draft is version 10, which was published on February 13. The first draft was based directly on Google's SPDY (which we looked at in 2009), although as one would expect, it has evolved in a number of ways since then. The basic approach, however, remains the same.

HTTP2 is backward compatible with all of HTTP 1.1's request methods, responses, and headers. But it attempts to decrease the overall latency of serving a page to a client by multiplexing requests, compressing HTTP headers, and allowing the server to prioritize some requests over others.

Multiplexing requests is in many ways an extension to the pipelining feature of HTTP 1.1. Pipelining allows the client to send request #2 before request #1 has been fulfilled by the server, but it still has a weakness: request #2 is still processed by the server after request #1. So if request #1 takes a long time, it still introduces latency. This is called "head-of-line blocking." HTTP 1.1 is also hampered by the requirement that clients not open more than two simultaneous connections to the same server. HTTP2 does away with that limit, and averts head-of-line blocking by multiplexing several HTTP request connections over the same underlying TCP connection (testing of current implementations seems to indicate somewhere between four to eight streams as the best number on average). Since these multiplexed HTTP streams are independent of each other, it is far less likely for slow requests to block the delivery of the entire page.

In addition to making more efficient use of bandwidth, HTTP2's multiplexing will alleviate the need to do several other popular workarounds, such as resource sharding (i.e., splitting one image into several pieces each served from a different server) and the inlining of CSS and JavaScript. Both of these techniques have their costs; sharding introduces multiple DNS lookups for the various servers (and then opening lots of separate HTTP connections to them), and inline CSS and JavaScript cannot be cached by the browser. So the full benefits of HTTP2 multiplexing should exceed the raw gains seen just from reducing head-of-line blocking.

HTTP2 also compresses the HTTP headers, which typically contain a lot of redundancy—particularly between related requests for the same page. The earliest implementations used gzip for compression, and built a shared Huffman code dictionary for all of the requests on a single connection. But that scheme was found to be vulnerable to the CRIME (Compression Ratio Info-leak Made Easy) attack, in which an attacker can discover the bytes of a session cookie by injecting test bytes into HTTP requests—if the compressed result is the same length as the unmodified request, then the attacker knows the test byte is indeed part of the cookie. The HTTP Bis group has subsequently moved to a new compression scheme called HPACK.

There is little opposition to header compression as an idea, but the same cannot be said of another HTTP2 optimization: binary encoding. As befits a compressed format, HTTP2's frame format is binary, both for the header and the payload. This decision has its critics, such as John Graham-Cumming, who said that he wondered "whether it was really necessary to add a complex, binary protocol to the HTTP suite." But, in response, Mozilla's Patrick McManus commented that the orderly message boundaries of the binary format make it considerably more straightforward—and, therefore, faster—to parse than HTTP 1.1's ASCII. Of course, it could also be argued that the binary format is not human-readable, but the counter-argument is that it is merely the binary encoding of existing ASCII request/response semantics, rather than something new.

HTTP2 adds several other mechanisms that can speed up the process of fulfilling requests, but which (unlike compression and multiplexing) require some deployment-time tweaks to produce optimized results. For instance, servers can prioritize one request stream over another. The assumption is that some content (such as page text) is more critical to deliver to the client than others (such as CSS or decorative images), but, naturally, the decision of which resources to prioritize and which to leave untouched cannot be solved in the abstract. Similarly, HTTP2 allows servers to effectively "push" some resources, initiating the transfer before the client makes the actual request. The most effective implementation might begin sending linked-in CSS or image resources after the main page is requested, but the protocol itself does not dictate how servers decide what to push.


Work continues on HTTP2, and the final draft is not expected until mid-2014. Most recently, discussion has included whether (and how) the new protocol should deal with encryption. At one time or another, dropping support for unencrypted http:// URIs was considered, as was dropping HTTPS as a separate protocol—in favor of requiring that HTTP2 run over TLS. For now, no such large steps have been taken. But the group has introduced HTTP Alternate Services (ALTSVC), a new HTTP header through which a server can move a URI request to a different host, port, or even protocol, without tearing down the connection and starting a new one.

This technique could be used to "upgrade" an http:// URI request from HTTP 1.1 to HTTP2, and thus move the connection to TLS. ALTSVC is a comparatively recent draft, which is still subject to change. Among other things, upgrading a connection to TLS relies on the presence of some specific TLS extensions, such as Server Name Indication (SNI), so while the idea of "opportunistic encryption" sounds appealing to many, there may be a fair amount of tire-kicking left before it is finalized.

The working group maintains a list of issues on GitHub and a publicly archived mailing list at the W3C site, which makes it easy to follow the development of the protocol. Just as importantly, the group tracks working implementations of HTTP2. Firefox and Chromium already support HTTP2, and Google, Twitter, and a few other large-scale application services support it on the server side. Since many of the benefits of the new protocol rely on implementations testing and getting the optimization details right, this is welcome news, and keeping in line with the IETF mantra of "rough consensus and working code." End users, of course, will notice only reduced page load times if they notice anything at all—but perhaps that is a good goal for a protocol update to set.

(Log in to post comments)

What's new with HTTP2

Posted Mar 13, 2014 2:45 UTC (Thu) by freemars (subscriber, #4235) [Link]

I'm encouraged by the attention being paid to encryption.

With Snowden's revelations about the importance of metadata to various Three Letter Agencies the final protocol had better encrypt everything: establish your TLS tunnel first, then request a specific web page, hold the connection open for a bit, and perhaps opportunistically pass other bits of information through the same connection.

With Certificate Authorities now outed as an untrusted part of the web of trust, HTTP2 browsers should specifically mark CA certificates as NOT securely encrypted. The CAs still have a role and authenticating the ownership of the web server.

What's new with HTTP2

Posted Mar 13, 2014 13:41 UTC (Thu) by hkario (subscriber, #94864) [Link]

with tools like Firesheep available to the average punter, let alone determined script kiddie, plaintext HTTP can be used to serve only static content

as such HTTP2 should require TLS

What's new with HTTP2

Posted Mar 13, 2014 15:24 UTC (Thu) by riccieri (guest, #94794) [Link]

I, too, would love to see the whole web encrypted! However, I'm worried that mandatory SSL would hinder adoption due to the certificate requirement and/or make the prices explode.

I'm no economist though, so it might be the case that the exact opposite happens :)

What's new with HTTP2

Posted Mar 13, 2014 17:50 UTC (Thu) by jwarnica (guest, #27492) [Link]

My initial reaction to the discussion about encryption was "WTF? How many people on the payroll of those bloodsucking certificate authorities are on this WG?"

If they make encryption required, they will have to update the standards to highly recommend UAs implement interaction with the user in a SSH like way; first time, ask them; later if the cert is the same, all is OK. CA's as well , sure, but if I need to spend an extra hour of my life... and real cash money to make it useful publicly, to set up a new website, then *boom*, life is over.

What's new with HTTP2

Posted Mar 14, 2014 14:50 UTC (Fri) by Jonno (subscriber, #49613) [Link]

> My initial reaction to the discussion about encryption was "WTF? How many people on the payroll of those bloodsucking certificate authorities are on this WG?

Encryption does not necessarily imply requiring a certificate. I could certainly welcome a new work order where both http:// and https:// is encrypted, but only https:// needs a certificate from a trusted authority.

What's new with HTTP2

Posted Mar 14, 2014 15:24 UTC (Fri) by jwarnica (guest, #27492) [Link]

That would be a reasonable path forward.

What's new with HTTP2

Posted Mar 17, 2014 16:32 UTC (Mon) by ms-tg (subscriber, #89231) [Link]

> Encryption does not necessarily imply requiring a certificate. I
> could certainly welcome a new work order where both http:// and
> https:// is encrypted, but only https:// needs a certificate
> from a trusted authority.

Great idea! +1

What's new with HTTP2

Posted Mar 18, 2014 21:03 UTC (Tue) by rodgerd (guest, #58896) [Link]

Absolutely. Seperating identity from encryption would be a huge boost to encryption in practise.

I'd trust my Bank to give me their own credentials reliably far ahead of pretty much any of the CAs out there...

What's new with HTTP2

Posted Mar 20, 2014 7:42 UTC (Thu) by eduperez (guest, #11232) [Link]

Pardon my ignorance, but what is exactly the point of encryption without certification? How does an "anonymous" encryption prevent a man-in-the-middle attack? If you cannot guarantee that the data you receive has been encrypted by the server that you are accessing, you cannot be sure that somebody somewhere has decrypted, read or modified, and then encrypted it again for you.

What's new with HTTP2

Posted Mar 20, 2014 8:01 UTC (Thu) by palmer_eldritch (guest, #95160) [Link]

It puts the bar a little higher. For example, it's very easy to listen to what people are doing on a public wifi. Remember that firefox extension that allowed users to easily do session hijacking a few years ago? It wouldn't be that easy if everything was encrypted. It wouldn't be impossible either, but it would be harder.

What's new with HTTP2

Posted Mar 20, 2014 18:05 UTC (Thu) by dlang (subscriber, #313) [Link]

It changes the attackers requirement from a passive "capture some traffic and analyze it later" to the more difficult and expensive "intercept and process _all_ traffic in realtime" matter.

Without encryption, if you only capture 90% of the packets, you have a 90% chance of getting what you want. With even broken encryption that could be reversed if the entire session is sniffed, such as where you have a copy of the server cert, if you don't get 100% of the traffic, you can't see anything after the first lost packet, and if you don't have access to the key of one end, you have to actively MITM the session to get anything.

What's new with HTTP2

Posted Mar 21, 2014 8:29 UTC (Fri) by abket (guest, #95676) [Link]

It doesn't, but it defends against passive attackers and allows to eventually detect massive active attackers.

What's new with HTTP2

Posted Mar 21, 2014 11:46 UTC (Fri) by Jonno (subscriber, #49613) [Link]

> How does an "anonymous" encryption prevent a man-in-the-middle attack?
It doesn't, but it *does* prevent man-at-the-side attacks, and makes man-in-the-middle attacks more expensive and (slightly) easier to detect after the fact.

My proposal would still leave http:// less secure than https:// (which BTW isn't perfect either, there is no such thing as "perfect security", only more-or-less difficult to break security), but improving the baseline would do a tremendous amount of good, even if it doesn't reach the level of current "best practices".

What's new with HTTP2

Posted Mar 21, 2014 13:18 UTC (Fri) by eduperez (guest, #11232) [Link]

Yes, man-in-the-middle attacks are harder than just traffic-snooping; but the difference is probably not as large as it may seem. For example:

* At a public wifi, do you trust the hot-spot owner?
* A rogue hot-spot, with the same name as the good one.
* ...

Besides, using anonymous https can give some users a false sense of security.

What's new with HTTP2

Posted Mar 13, 2014 22:17 UTC (Thu) by rodgerd (guest, #58896) [Link]

> I'm encouraged by the attention being paid to encryption.

I'm not. And if you can't understand why requiring the approval of a CA to run a web server is problematic, you've absorbed the wrong lessons from Snowden. Under the proposed regime for HTTP2 we end up with a more centralised, more command-and-control web for everything.

Given we know CAs are collectively incompetent, easily subverted by criminals and governments, and that browser authors are so unwilling to ever revoke CAs from their accepted lists, it just provides an illusion of security you pay a lot of money for.

If you wanted to design a way to make it harder for people to freely use the web (which is ~= the Internet for most folks) you couldn't do better than to increase the stranglehold a comparative handful of companies exert already.

What's new with HTTP2

Posted Mar 13, 2014 23:04 UTC (Thu) by ncm (subscriber, #165) [Link]

Indeed, it is hard to believe that many, even most certificate authorities are not actually owned by spooks already. How much does it cost to buy one of the the discount operations? How much does it cost to start one? How much does it cost to put in a mole at Verisign?

Is there any rational reason to think Verisign was not a spook operation to begin with? The only one I can think of is that Ed Snowden hasn't said so yet, and is advocating more use of SSL, but that's pretty thin. Is there any plausible path to a secure certificate infrastructure? Without, everything else seems like a waste of time.

What's new with HTTP2

Posted Mar 14, 2014 3:13 UTC (Fri) by raven667 (subscriber, #5198) [Link]

While I'm all for Snowden I'm not sure what your point is here except to say that Certificate-based key authentication is somehow tainted by the CAs but that depends on what part you are trying to protect. The CAs never have access to customer private keys so the encryption works regardless of how shoddy the CAs are, the only issue is how well you know that the remote endpoint you are talking to is who they say and not some third party (spooks). That can be combat by tools like certificate pinning (minus crappy client library bugs in the validation) or even SSH style public key known hosts files that might be able to warn you when something changes. Neither of these techniques rely on the CA infrastructure so I'm not sure we need to waste a lot of time worrying about how secure the CAs are, the endpoints need to make their own decisions on identity and authentication and the CA certificate is but one datapoint among many.

What's new with HTTP2

Posted Mar 13, 2014 9:44 UTC (Thu) by ncm (subscriber, #165) [Link]

I wouldn't bet on reduced page-load times for most sites, no matter how successful the design and deployment. Instead, we can look forward to similar load times on pages larded with with more-singing, more-dancing, more-intrusive advertising. Traffic prioritization, likewise, will provide us ample time to study the ads as we wait for what newspaper typesetters used to call the "filler" to show up.

But LWN will get faster, and the reduction in LWN's bandwidth fees will support even more investigative and reportorial excellence that we get today, which is already rather more than we lot (dear reader excepted) deserve.

What's new with HTTP2

Posted Mar 16, 2014 18:38 UTC (Sun) by speedster1 (guest, #8143) [Link]

I think this should go into the list of predictions for the next year ;)

What's new with HTTP2

Posted Mar 20, 2014 9:12 UTC (Thu) by ssokolow (guest, #94568) [Link]

The "push" support is the only part that really worries me since the rest can be solved with an ad-blocker.

Having the server decide to serve up something which I'm just going to discard anyway wastes bandwidth and, while I may be on a flat-rate DSL plan, most of my fellow Canadians are not.

What's new with HTTP2

Posted Mar 21, 2014 23:10 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Presumably you could have your browser just ignore server push requests (and extensions would pop up to filter them). I thought there was a header you could set to say "I won't listen to your push requests".

What's new with HTTP2

Posted Mar 24, 2014 7:06 UTC (Mon) by dtlin (✭ supporter ✭, #36537) [Link]

In SPDY (and I assume HTTP2, though I haven't read it) the client can send a GOAWAY frame, which informs the server it will not accept any more streams.

What's new with HTTP2

Posted Mar 14, 2014 7:22 UTC (Fri) by sml (subscriber, #75391) [Link]

The chairman of the HTTP Bis group had an interesting presentation about HTTP2 at LCA earlier this year - video

Copyright © 2014, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds