HTTP/2 (originally named HTTP/2.0) is the second major version of the HTTP network protocol used by the World Wide Web.
Why HTTP/2?
1. Resource Intensive Page Loading
Loading a Web page is more resource-intensive than ever, and loading all of those assets efficiently is difficult because HTTP practically only allows one outstanding request per TCP connection.
2. Multiple TCP Connections
In the past, browsers have used multiple TCP connections to issue parallel requests. However, there are limits to this; if too many connections are used, it’s both counter-productive (TCP congestion control is effectively negated, leading to congestion events that hurt performance and the network), and it’s fundamentally unfair (because browsers are taking more than their share of network resources).
3. Duplicate Data
A large number of requests back and forth from the browser to a server, means a lot of duplicated data on the wire.
4. Hacks
It’s considered Best Practice to do things like spriting, data: inlining, domain sharding and concatenation. These hacks are indications of underlying problems in the protocol itself, and cause a number of problems on their own when used.
Differences Between HTTP1.1
The proposed changes do not require any changes to how existing web applications work, but new applications can take advantage of new features for increased speed.
HTTP/2 leaves most of HTTP 1.1's high level syntax, such as methods, status codes, header fields, and URIs, the same. The element that is modified is how the data is framed and transported between the client and the server.
1. Backward Compatible
HTTP/2 will still work with the existing Web. So HTTP/2 will not introduce new methods, change headers or status codes.
2. Reduced Requests
HTTP/1 use techniques like inlining, concatenation and spriting to reduce the number of requests on a page.
HTTP/2 overcomes the above issue by using 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 process) doesn’t block others.
Why is HTTP/2 multiplexed?
HTTP/1.x has a problem called head-of-line blocking, where effectively only one request can be outstanding on a connection at a time. Multiplexing addresses these problems by allowing multiple request and response messages to be in flight at the same time; it’s even possible to intermingle parts of one message with another on the wire. This, in turn, allows a client to use just one connection per origin to load a page.
HTTP/2 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. This is 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. Less Load on Network & Servers
With fewer connections of HTTP/2 will ease the load on both the network and the servers. With the increasing use of mobiles, as an example say a phone opens up 4-6 TCP connections to each server to download page resources, it could end up overloading mobile network buffers causing issues like dropping packets.
Why is HTTP/2 multiplexed?
HTTP/2 allows the use of a single connection per host and encourages sites to consolidate their content on one host where possible.
4. Server Push
HTTP/2 employs server push which allows a server to proactively send resources: HTML, CSS and images to the client’s cache for future use.
This helps eliminating round trips to the server for fetching linked style sheets and image etc.
Cache
Server push can be useful for proactively updating or invalidating clientside cache.
If a client decides that it already has a copy, it can say "no" by with RST_STREAM.
5. RST_STREAM
In HTTP/1, if client sends a request and then finds out it doesn’t need the response, it needs to close the connection to save bandwidth; there’s no safe way to recover it.
HTTP/2 introduces RST_STREAM frame to allow a client to change its mind in scenarios like browser navigating away from the page, or user cancelling a download.
6. Encryption
Even though using TLS(Transport Layer Security) is not mandatory for HTTP/2, Many believe the only safe way to deploy the new protocol is to use encryption.
Chrome and Firefox are only going to support HTTP/2 using TLS, as it is difficult to deploy the new protocol across internet, given many of the middleboxes like proxies and firewalls assume that HTTP/1 will not change.
TLS(Transport Layer Security)
Transport Layer Security (TLS) is a protocol that ensures privacy between communicating applications and their users on the Internet. When a server and client communicate, TLS ensures that no third party may eavesdrop or tamper with any message. TLS is the successor to the Secure Sockets Layer (SSL).
7. No More Text
With HTTP/1, you can open up a telnet session and type in a request and then look at the response. But this will not be feasible with HTTP/2, because it's a binary protocol.
Textual protocols have many issues:
- Higher overhead to parse - In contrast, binary protocols are simpler, and have less overhead to parse.
- Delimiters - Newlines, whitespace handling, extra characters etc.
- Security - Different implmentations pay the way to malicious parties to make their way in.
- Processing text - Anything remotely look like HTTP/1 will be processed as HTTP/1.
Tools
Wireshark has a plugin for dissecting HTTP/2.
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.