What to Expect From HTTP/2

With the HTTP/2 Working Group nearing completion and implementations starting to appear, the chair of the group, Mark Nottingham, has written a blog going over 9 things to expect in the new protocol:

1. Using the same APIs as we have in HTTP. As Mark mentions "Making HTTP/2 succeed means that it has to work with the existing Web. So, this effort is about getting the HTTP we know on the wire in a better way, not changing what the protocol means." Although there may be mechanisms allowing you to fine-tune new capabilities, in general there are no new methods, headers or playing around with status codes.
2. Cheaper requests. "HTTP/2 uses multiplexing to allow many messages to be interleaved together on a connection at the same time, so that one large response (or one that takes a long time for the server to think about) doesn’t block others. Furthermore, it adds header compression, so that the normal request and response headers don’t dominate your bandwidth — even if what you’re requesting is very small. That’s a huge win on mobile, where getting big request headers can easily blow out the load time of a page with a lot of resources by several round trips."
3. The protocol has been designed to be much more network and server friendly. "HTTP/2 is designed to use fewer connections, so servers and networks will enjoy less load. This is especially important when the network is getting congested, because HTTP/1’s use of multiple connections for parallelism adds to the problem." So HTTP/2 now allows a single connection per host and prefers sites to consolidate on one host whenever possible.
4. HTTP/2 introduced the concept of "server push", which allows a server to proactively send data to a client's cache before the client needs it, thus improving performance. Of course in some cases the client may not want this, so HTTP/2 allows it to say no.
5. The new protocol provides a much nicer way for a client (browser) to change it's mind if it decides it doesn't need a response to a request. In HTTP/1 the client can really only close the connection. "HTTP/2 adds the RST_STREAM frame to allow a client to change its mind; if the browser navigates away from a page, or the user cancels a download, it can avoid having to open a new connection without wasting all of that bandwidth."
6. HTTP/2 has much more encryption support and we've covered the pros and cons of this as Mark wrote earlier.
7. If you like the ability to snoop and manually parse your HTTP requests and responses, or use telnet to the server, for instance, then prepare to have that ability removed. HTTP/1 is a text-based protocol whereas HTTP/2 is binary. "While binary protocols have lower overhead to parse, as well as a slightly lighter network footprint, the real reason for this big change is that binary protocols are simpler, and therefore less error-prone." Mark discusses this this is the case, e.g., how to delimit text, but one of the critical deficiencies with HTTP/1 and text has been security vulnerabilities. "HTTP/1’s textual nature has also been the source of a number of security issues; because different implementations make different decisions about how to parse a message, malicious parties can wiggle their way in (e.g., with the response splitting attack)."
8. Don't expect HTTP/2 to miraculously improve the performance of your client or server. "It’s more accurate to view the new protocol as removing some key impediments to performance; once browsers and servers learn how and when to take advantage of that, performance should start incrementally improving." As Mark points out, most sites today have been written with the limitations of HTTP/1 in mind and will take a while to be reconfigured to take advantage of what HTTP/2 offers. "Furthermore, the downside of HTTP/2’s network friendliness is that it makes TCP congestion control more noticeable; now that browsers only use one connection per host, the initial window and packet losses are a lot more apparent."
9. If you think that HTTP/2 is the end of the evolution then think again. The team are already considering what comes next. "Right now, people are really keen to get HTTP/2 'out the door,' so a few more advanced (and experimental) features have been left out, such as pushing TLS certificates and DNS entries to the client — both to improve performance. HTTP/3 might include these, if experiments go well. Of course, HTTP/3 might also be the version where the community cleans up all of the problems we missed this time around, but so far there seems to be a growing amount of confidence — both from the experience the community has deploying SPDY as well as HTTP/2 implementations — that HTTP/2 is getting close to done."

That's it. A great and concise overview of what's coming soon in HTTP/2 from Mark. What do you think of these capabilities? Anything here that worries you? Anything here that gets you excited about using the protocol when it starts to become mainstream?