HTTP/2 is a web protocol that is currently undergoing active construction, but has been approved by the IETF on February 18, 2015 after "more than two years of discussion, over 200 design issues, 17 drafts, and 30 implementations."
Who cares? Everything seems to be working fine with the current HTTP/1.1, right? This is a valid concern, but must be analyzed in the light of the many workarounds that engineers have established to overcome oversights in HTTP/1.1. These workarounds include concatenated files, image sprites, and domain sharding. All of these workarounds would be rendered redundant by the adoption of HTTP/2.
What does HTTP/2 not do?
I think it is very important to understand that implementing HTTP/2 will not result in application developers doing anything differently. Your tried and true HTTP methods, status codes, URIs, headers, and cache directives will not be changing.
At a very high level, HTTP/2 seeks to improve the speed of using the HTTP protocol whether that be with web browsing on desktop or mobile, non-browsers such as HTTP APIs, or through proxies such as firewalls.
SPDY was an experimental protocol developed by the minds over at Google and was announced to the public in 2009. SPDY was created in order to reduce the load time of pages by addressing certain issues in HTTP/1.1. Google tested this new protocol with the top 25 websites at the time and found that pages loaded up to 55% faster (note: this was in lab conditions over simulated home connections).
Well, believe it or not, 3 years later the HTTP Working Group began development on HTTP 2.0.
Binary framing layer
Awwwww yiissss, let's get into the nitty-gritty of HTTP/2 now with the Binary Framing Layer. Implementing this layer will not change any of the newline delimited plaintext HTTP 1.x information that you all know and love, it simply splits those things into smaller pieces called messages and frames.
- Stream - Information flowing in a bidirectional manner between server and client on an established connection
- Frame - The smallest unit of communication that flows along the stream, makes up a complete message
- Message - A combination of frames that maps to a message
This might sound familiar to some of you! In fact it is very close to the binary framing done by HTTPS in order to secure communications.
This an extremely powerful feature that overcomes one of the limitations of HTTP 1.x in which a server could not send multiple responses to a single request (e.g., server responds to request for an HTML page then must wait for more requests for CSS and JS files).
This push will occur along one single TCP connection, unlike HTTP 1.x, which requires multiple TCP connections to account for multiple parallel requests. HTTP/2 will seek to overcome a crowding of TCP connections by sending messages in separate frames that can go in an independent order and be received and reconstructed (termed request and response multiplexing).
This is obviously a very high-level overview and does not even begin to cover all the benefits and changes that are coming with HTTP/2. If you want more information be sure to check out the HTTP2 github page as well as the HTTP2 IETF draft!