The Internet Engineering Steering Group (IESG) has approved the specifications for HTTP/2 and HPACK (a compression format for HTTP/2 header fields), says working group chair Mark Nottingham.
HTTP/2 is based on SPDY, a Google-developed protocol designed to speed up web page loading by compressing the content and reducing the number of connections.
SPDY was announced in 2009 and first implemented in Chrome 6 in 2010. SPDY inventors Roberto Peon and Mike Belshe passed SPDY to the IETF (Internet Engineering Task Force) for standardisation, the outcome being the just-approved specification for HTTP/2.
HTTP/2 does not change web content or HTML standards, but only the means by which that content is delivered to the browser. The current standard, HTTP/1.1, is inefficient, mainly because typical web pages are composed of many individual requests, leading to connection congestion and unnecessarily duplicated data.
HTTP/2 is a binary protocol and also multiplexed, which means that clients can use a single connection per origin server when loading a page.
Peon says that HTTP/2 improves on SPDY:
The biggest difference is probably the prioritization scheme, which is much more flexible and good for proxies in HTTP2 as compared to SPDY. A very close second is the change to how header compression is done-- in HTTP2 it is much faster, much much more memory efficient, and compresses a bit less effectively than SPDY's use of gzip … and, of course, HTTP2 is also much, much, MUCH better specified than was SPDY.
SPDY has already been implemented by major sites including Google, Twitter, Yahoo! and WordPress.com. It is also implemented in the Nginx web server and can be added to Apache. Firefox has support. Microsoft’s Windows 10 supports HTTP/2 both in the browser and in an updated IIS web server. Since HTTP/2 is, in effect, now the current version of SPDY, HTTP/2 support is likely to follow where SPDY has been implemented. Google’s Chrome supports HTTP/2, and its internal name is SPDY4.
HTTP/2 is more complex than its predecessor, and not without controversy. Poul-Henning Kamp, who created the open source Varnish HTTP accelerator, stated last month that HTTP/2 has “layering violations, inconsistencies, needless complexity, bad compromises, and misses a lot of ripe opportunities.”
Kamp argues that the creators of HTTP/2 have commercial interests which prevent them from doing the right thing over privacy by deprecating cookies in favour of a "client controlled session identifier" which would give users control of tracking:
The reason HTTP/2.0 does not improve privacy is that the big corporate backers have built their business model on top of the lack of privacy. They are very upset about NSA spying on just about everybody in the entire world, but they do not want to do anything that prevents them from doing the same thing. The proponents of HTTP/2.0 are also trying to use it as a lever for the "SSL anywhere" agenda, despite the fact that many HTTP applications have no need for, no desire for, or may even be legally banned from using encryption.
The encryption aspect has been controversial. Some argued for mandatory encryption, but this is not in the final specification. However, some implementations do require it.
Even if HTTP/2 is enthusiastically adopted, the open nature of the internet means that the older, simpler HTTP/1.1 standard will remain necessary for the foreseeable future.
More information on HTTP/2 is in the FAQ here.®