A very pertinent question was asked earlier to find out what differences between HTTP 1.1 and HTTP 1.0 .
I wanted to know exactly the same but between HTTP 2.0 and HTTP 1.1 .
In addition, can you tell if the protocol is already fully supported by the main browsers?
In HTTP 1.1 we enabled GZIP to compress the information we sent in our responses. A good practice that needs to be explicitly enabled. In HTTP 2 GZIP is standard and required.
In HTTP 1.1 headers are sent in plain text, on each request (the famous User-Agent for example). In HTTP 2 the headers are binary and compressed, decreasing the volume of data. In addition, it is possible to reuse the headers for the following requisitions. That way, we just have to send the changing headers. This reduces the requests and makes them less bulky.
For every resource a page has, a request then made to load them faster needs to parallelize those requests. The problem is that HTTP 1.1 is a sequential protocol, we can only do 1 request at a time. The solution is to open more than one connection at a time, paralleling the requests in 4 to 8 requests (that's the limit we have). A common way to handle this is to use multiple hostnames on the page (pag.com and img.pag.com), thus gaining more parallel connections.
In HTTP 2 the requests and responses are automatically parallel in a single connection. This is called multiplexing .
An interesting optimization is to facilitate the initial rendering, prioritizing the resources needed for the user to see the page first (CSS) and to interact (JS) later.
In HTTP 2 we can indicate in the requests which of them are most important through numerical prioritization. So the browser can give high priority to a CSS file in the head that blocks the rendering, and lower priority for an asynchronous JS at the bottom of the page.
A common trick in HTTP 1.1 is to inline resources, aiming for faster initial rendering. The big problem here is that we've cleared the browser cache. CSS next to HTML can not be cached independently.
Here comes Server Push in HTML 2. The idea is to have the server send some resources to the browser without it having requested yet. The server "pushes" to the browser features that it knows will be requested soon. So when the browser needs the feature, it will already be cached and will not make a request.
A while ago there was a discussion whether HTTP 2 would allow non-SSL usage (I've stopped tracking for some time), but in practice only secure HTTPS connections will be supported. So we have security and privacy more established with the protocol.
Finally, I recommend the Hipsters.tech episode on HTTP2, will give you even more information on the subject
While HTTP 1.x is considered a textual protocol, HTTP 2 is considered binary making it difficult for a human to read but making it easier for the computer. This is because now the packets are multiplexed on a TCP connection and it is more compact until the header is compressed . It leverages TCP's ability and reduces travel between the server and the client .
As a result, latency has been reduced , it is better able to broadcast larger and faster packets , as well as facilitate wikipedia.org/wiki/HTTP_pipelining "> pipelining of requests and responses, avoiding server push , so used nowadays , by HTTP itself.
Some parts of the protocol that were mandatory, but that did not always need to be optional.
It is possible to create extensions to the protocol as needed.
It is compatible as 1.1 and a negotiation decides how to communicate.
With all of this it is able to meet the demand for varied uses and not just traditional simple web pages that are no longer the exclusive use of the protocol.
Some techniques that were used to improve performance that hindered development are no longer necessary.
You can read more details in a community book which I relied on to answer.
Is the protocol already fully supported by main browsers?
Protocol support varies. Top browsers support you almost completely .
The differences are several , but let's start with the most basic change.
HTTP2 is a binary protocol , different from HTTP1 that is in text format. Only with this concept do we have many differences. With a binary protocol it is easier to know the beginning and end of the packets, which is much more complicated to do with textual protocols. That is, the implementation itself is simpler.
Regarding the features, HTTP2 came to solve HTTP1 issues and limitations that sites currently try to get around in different ways.
Some of the techniques used with HTTP1 to circumvent its limitations: Spriting , Inlining , concatenation of Javascript files and Sharding .
I will not go into the details of each of the above techniques, but HTTP2 has been implemented so that they are no longer needed, thus correcting the latency problems of the first version of the HTTP protocol.
Among these new features of HTTP2, we can cite:
Gzip ) or even the proposal made by the extinguished SPDY protocol aid in this problem, but are vulnerable to the attack known as CRIME . HTTP2 supports a type of compression dedicated to headers, known as HPACK , which does not have the same vulnerability. I believe these are the major changes from the "end" user's point of view. Of course there are many other more technical differences, but I think this answers the main questions for those who know what's new and the differences.
According to the document created by one of the main contributors to the protocol, it will be necessary the use of more elaborate tools to track requests sent / received by the page, such as Wireshark .
However, all major browsers on the market already support the protocol since 2015 . So the changes to the new binary protocol are transparent from the developer's point of view, which can keep track of the requests the page sends or receives.