HTTP/2 specifications have been approved for publication, according to the Internet Engineering Task Force (IETF).
15 years after the launch of HTTP/1.1, IETF have gone through over 200 design issues, 17 drafts, and 30 implementations to get the specification approved to be published as standards-track RFCs.
In the intervening years since HTTP/1, web pages have become increasingly more resource intensive. Stats obtained from HTTP Archive demonstrate how the web has grown.
For example, the two charts above demonstrate web pages using fonts, with the difference between February 2011 (left chart) and February 2015 (right chart) growing from just 2% to 47%.
Similarly, the below charts show Average Bytes per Page per Content Type. In February 2011, the total was 654kb. In 2015 it has increased to 1867kb. Images accounted for 394kb, compared to 1085kn in 2015.
Mark Nottingham, chair of the HTTPBIS working group, announced the decision on the IETF blog in the post HTTP/2 Approved. He said:
The HTTP Working Group began work on HTTP/2 in 2012 by selecting Google’s SPDY protocol as the starting point, holding a series of six interim meetings to incorporate community feedback. This resulted in substantial changes to the format of the protocol, its compression scheme, and its mapping to the semantics of HTTP.
The resulting protocol is designed to allow a seamless switch between HTTP/1 and HTTP/2, with minimal changes to applications and APIs, while at the same time offering improved performance and better use of network resources. Web users largely will be able to benefit from the improvements offered by HTTP/2 without having to do anything different.
Nottingham says that HTTP/2 will help to provide users with a faster browsing experience, reduce the amount of bandwidth required, and make using secure connections easier.
Compared to HTTP/1.1 the key differences include
- HTTP/2 is binary, rather than textual
- Instead of being ordered and blocking, HTTP/2 is fully multiplexed -- using just one connection for parallelism
- using header compression, HTTP/2 reduces overhead
- HTTP/2 allows servers to “push” responses proactively into client caches
In February 2015, Google announced plans to remove support for SPDY in favour of HTTP/2 by 2016. Google also plans to remove support for the TLS extension named NPN in favor of ALPN in Chrome at the same time, and the company strongly encourages server developers to move to HTTP/2 and ALPN.
Countering speculation that Google forced the SPDY protocol on IETF, Nottingham says
Anyone who actually interacted with Mike and Roberto [Mike Belshe and Roberto Peon, co-creators of Google's SPDY] in the group knows that they came with the best of intent, patiently explaining the reasoning behind their design, taking in criticism, and working with everyone to evolve the protocol.
Roberto also served alongside Herve Ruellan as editor of HPACK, after they merged their competing proposals for header compression.
