Introduction to HTTP/2 Header Compression Technology (1)

Introduction to HTTP/2 Header Compression Technology (1)

We know that the HTTP/2 protocol is composed of two RFC: one is RFC 7540, which describes the HTTP/2 protocol itself; the other is RFC 7541, describes the Header Compression Technology Used in HTTP/2. This article will introduce the HTTP/2 Header Compression Technology in detail through actual cases.

Why compression?

In HTTP/1, HTTP requests and responses are composed of three parts: Status line, request/response header, and message body. Generally, the message body is compressed by gzip, or the compressed binary file (such as sample and audio) is transmitted, but the status line and header are not compressed, directly transmit plain text.

As Web functions become more complex, more and more requests are generated for each page. According to HTTP Archive statistics, each page generates hundreds of requests on average. As a result, more requests consume more and more traffic in the header. In particular, it is a waste to transmit UserAgent and Cookie content that will not change frequently every time.

The following is the packet capture result of a page that I opened. We can see that the network overhead of the transmission header exceeds kb, more than HTML:

 

The following is the details of a request. We can see that in order to get 58 bytes of data, the traffic consumed on the header transmission is several times:

 

In the HTTP/1 era, there are many optimization solutions to reduce the traffic consumed by the header, such as merging requests and enabling Cookie-Free domain names, however, these solutions will introduce more or less new issues, which will not be discussed here.

Compression Effect

Next, I will use the packet capture record for accessing this blog to illustrate the changes caused by HTTP/2 header compression.

First, directly. The selected Stream is the first request header sent by the browser to access this site:

 

The figure shows that the HEADERS stream is 206 bytes in length, and the decoded header is 451 bytes in length. It can be seen that the size of the compressed header is reduced by more than half.

But is that all? Create another image. The selected Stream is the request header sent by the browser after clicking the link on this site:

 

This time, the HEADERS stream is only 49 bytes in length, but the decoded header is 470 bytes in length. This time, the size of the compressed header is almost 1/10 of the original size.

Why is the gap between the two times so big? We expand the header information twice to view the number of bytes occupied by the two transmission of the same field:

 

 

After comparison, we can find that the second request header is very small because most key-value pairs only occupy one byte. Especially for headers such as UserAgent and Cookie, the first request occupies many bytes, and only one byte is required for subsequent requests.