What are the differences between HTTP 2 and HTTP 1.1?

Asked

Viewed 8,680 times

24

A very pertinent question was asked earlier to find out what the differences between the HTTP 1.1and the HTTP 1.0.

I wish I knew exactly the same but between HTTP 2.0 and HTTP 1.1.

Additionally, they may refer to whether the protocol is already fully supported by browsers main?

4 answers

27


Automatic compression

At HTTP 1.1 we enable GZIP to compress the information we send in our responses. A good practice that needs to be explicitly enabled. In HTTP 2 GZIP is standard and required.

Only changing headers are re-sent

In HTTP 1.1 headers are sent to Plain text, on each request (the famous User-Agent for example). In HTTP 2 headers are binary and compressed, decreasing the volume of data. In addition, it is possible to reuse headers for the following requests. That way, we only have to send the headers that change. This reduces requests and makes them less bulky.

Parallelization of requests

For every feature a page has, a request then made to load them faster we need 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 the same time, parallelizing 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 requests and replies are automatically parallel on a single connection. It’s called multiplexing.

Prioritization of requests

An interesting optimization is to facilitate initial rendering, prioritizing the resources needed for the user to see the page first (CSS) and interact (JS) after.

In HTTP 2 we can indicate which requests are most important through numerical prioritization. So the browser can give high priority to a CSS file in the head that blocks rendering, and lower priority to an asynchronous JS at the bottom of the page.

Server Push

A common gambit in HTTP 1.1 is to inline resources for faster initial rendering. The big problem here is that we cancel the browser cache. CSS next to HTML cannot 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 it yet. The server "pushes" into the browser resources that it knows will be requested soon. So when the browser needs the resource, it will already be cached and will not make a request.

Security

A while ago there was a discussion whether HTTP 2 would allow use without SSL (I stopped following for some time), but in practice only secure HTTPS connections will be supported. Thus we have security and privacy more established with the protocol.

Finally, I recommend the episode of Hipsters.Tech. about HTTP2, will give you even more information on the subject

  • I liked the answer. You can explain this part a little better: "By the way, only the changing headers are re-sent, we no longer have that excess of information sending all the headers again."?

  • Sure, I’ll edit that part of the answer to make it more complete :)

13

While HTTP 1.x is considered a textual protocol, HTTP 2 is considered binary, difficult to read by a human, but making it easier for the computer. This is because now the packages are multiplexed in a TCP connection and are more compact, up to the header is compressed. Him makes better use of TCP capability and reduces travel between server and client.

As a consequence, the latency has been reduced and he’s better able to transmit larger packages and faster, besides facilitate the pipelining of requests and responses, avoiding the lock of the first package existing in HTTP 1.x.

Some new features have been added, such as:

  • the prioritization of packages and indication of dependency between them;
  • information for managing streams, because now they have an identifier;
  • made it much easier to do the push server, so used nowadays by HTTP itself;
  • RESET to cancel sending data.

Some parts of the protocol that were mandatory, but not always needed, became optional.

The possibility of creating extensions to the protocol is open as needed.

It is compatible as 1.1 and a negotiation decides how to communicate.

With all this, it is able to meet the demand for varied uses and not just traditional simple web pages that has ceased to be the exclusive use of the protocol.

Some techniques that were used to improve performance but hindered development are no longer needed.

Can read more details in a community book which I based myself on.

the protocol is already fully supported by the main browsers?

Protocol support varies. The major browsers support it almost fully. Servers also in their latest versions.

5

The differences are several, but let’s start from the most basic change.

HTTP2 is a binary protocol, other than HTTP1 which is in text format. Only with this concept we already have many differences. With a binary protocol it is easier to know the beginning and end of packages, which is much more complicated to do with textual protocols. That is, the implementation itself is simpler.

With respect to features, HTTP2 has come to solve HTTP1 problems and limitations that websites currently try to circumvent in different ways.

Some of the techniques used with HTTP1 to circumvent its limitations: Spriting, Inlining, concatenation of Javascript files and Sharding.

I won’t go into the details of each of the above techniques, but HTTP2 has been implemented so that they are no longer needed, thus fixing the latency problems of the first version of the HTTP protocol.

Among these new HTTP2 features, we can mention:

  • Multiplexed flow: a same connection can bring different types of data (Javascript files, images, etc.), all of them being mixed under this same connection. The destination will process the frames in the order they are received.
  • Priorities and dependencies: In the stream packets mentioned above, some of them may have priority over others. This priority can be changed dynamically. A classic example is when the user is viewing a page with multiple images and the user decides to use the scroll bar to load the images from the next "page"and in this case it is desirable that these images take priority over the images that appeared on the top of the page.
  • Header compression: for being a stateless (stateless) protocol, HTTP repeats many headers to each request and often they do not change with each request. When there is too much information repeated, some kind of compression is required. Currently HTTP compression in the TLS layer (using Gzip) or even the proposal made by the former Protocol SPDY help 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.
  • Reset: mechanism to facilitate the closure of connections and start a new one. It is not always possible to do this with the current HTTP, and when it is, there is a certain network cost for this, because you need to negotiate a new TCP connection.
  • Server push: the server can guess that the client needs a resource beyond what he initially requested, already storing this second resource cached in the client, predicting that he will request it and receive it (thus) immediately.

I believe these are the main changes from the point of view of the "end" user. Of course there are many other more technical differences, but I think this answers the main questions for those who know what is new and the differences.

What changes to developer?

According to the document created by one of the main contributors of the protocol, it will be necessary to use more elaborate tools to track the requests sent/received by the page, such as the Wireshark.

However, all major browsers on the market already support the protocol since 2015. Thus, the changes to the new binary protocol are transparent from the point of view of the developer, who can follow the requests that the page sends or receives.

  • I already tested HTTP2 with IIS and Chrome and the information appeared in the same way as it appears for the version of the previous protocol.

  • @Brunocosta, thanks for the feedback. Was it exactly the same? I did a search now here and saw no difficulties in the browser, my base was just the comment of the protocol author. I will adjust this information.

  • 1

    It was the same way, it’s so much the same that the only way I could know (without resorting to other tools) was to enable a column that indicates which protocol is being used for the requests. You can see this when browsing on google. At the time it was all the same but it seems that some heads are now preceded ":".

4

Browser other questions tagged

You are not signed in. Login or sign up in order to post.