Why we need to use HTTP/2

HTTP/2 is the first major upgrade to the HTTP protocol in over 15 years.
Websites have changed dramatically in the interim, with the number of external image, CSS, and JavaScript assets growing by the year. HTTP/1.1 wasn’t designed for this kind of complexity. HTTP/2 is optimized for the modern website, improving performance without complicated hacks like domain sharding and file concatenation. Adopting HTTP/2 speeds up your website without any changes to your existing codebase.

Test results

HTTP/2 demonstrated to be consistently faster then HTTP/1.1 on this test

• 4 times faster on WiFi / 20Mbps cable, average server ping 50ms
• 6 times faster on LTE network, average server ping 90ms
• 15 times faster on 3G network, average server ping 120ms
• 2 times faster on 2G network, average server ping 400ms

The reason HTTP/2 is just 2x faster on 2G network is due to EDGE bandwidth constraints as at 170Kbps link rapidly saturates.

The primary goals for HTTP/2 are to reduce latency by enabling full request and response multiplexing, minimize protocol overhead via efficient compression of HTTP header fields, and add support for request prioritization and server push.
To implement these requirements, there is a large supporting cast of other protocol enhancements, such as new flow control, error handling, and upgrade mechanisms, but these are the most important features that every web developer should understand and leverage in their applications.

HTTP/2 does not modify the application semantics of HTTP in any way. All the core concepts, such as HTTP methods, status codes, URIs, and header fields, remain in place. Instead, HTTP/2 modifies how the data is formatted (framed) and transported between the client and server, both of whom manage the entire process, and hides all the complexity from our applications within the new framing layer. As a result, all existing applications can be delivered without modification.

Why not HTTP/1.2?

To achieve the performance goals set by the HTTP Working Group, HTTP/2
introduces a new binary framing layer that is not backward compatible with previous HTTP/1.x servers and clients — hence the major protocol version increment to HTTP/2.

That said, unless you are implementing a web server (or a custom client) by
working with raw TCP sockets, then you won’t see any difference: all the new, low-level framing is performed by the client and server on your behalf. The only observable differences will be improved performance and availability of new capabilities like request prioritization, flow control, and server push!

HTTP/2 defines request priorities and supports cancellations, so that if an application needs to render i.e. a dynamic gallery preview it can request high priority images for the initial view, request images down the list and i.e. cancel their download if user would navigate away or scroll deep down the list.

Timeline

• March 2012: Call for proposals for HTTP/2
• November 2012: First draft of HTTP/2 (based on SPDY)
• August 2014: HTTP/2 draft-17 and HPACK draft-12 are published
• August 2014: Working Group last call for HTTP/2
• February 2015: IESG approved HTTP/2 and HPACK drafts
• May 2015: RFC 7540 (HTTP/2) and RFC 7541 (HPACK) are published

HTTP/2 Push — Opportunities

HTTP/2 gives huge performance improvements over HTTP/1 in many ways, and server push is one of its features for performance.

A typical (and simplified) HTTP request/response flow is like this (The screenshot below is for connecting to Hacker News):

1. The browser requests an HTML document.
2. The server processes the request and generates/sends the HTML document.
3. The browser receives the response and parses the HTML document.
4. It identifies more resources that are needed to render the HTML document, such as stylesheets, images, JavaScript files, etc. It sends more requests for those resources.
5. The server responds to each request with the corresponding resource.
6. The browser renders the page using the HTML document and associated resources.

This means that there usually are multiple round-trips of requests/responses to render one HTML document because there are additional resources that are associated with it, and the browser needs them to render the document correctly. It would be great if all those associated resources could be sent to the browser together with the original HTML document without the browser requesting them. And that is what HTTP/2 server push is for.

In HTTP/2, the server can proactively push additional resources together with the response to the original request that it thinks the browser will request later. Later, if the browser really needs them, it just uses the already-pushed resources instead of sending additional requests for them.