In vernacular: How is HTTP/1.1 optimized? 【Illustration】


Ask you: " Do you know how to optimize HTTP/1.1? "

I think your first thought is to use KeepAlive to change HTTP/1.1 from short connections to long ones.

This is indeed an optimized method. It enters from the direction of the underlying transport layer. By reducing the number of TCP connection establishment and disconnection, the network transmission delay is reduced, thereby improving the The transmission efficiency of the HTTP/1.1 protocol.

But in fact, the HTTP/1.1 protocol can also be optimized from other directions, such as the following three optimization ideas:

  • 尽量避免发送 HTTP 请求
  • 在需要发送 HTTP 请求时,考虑如何减少请求次数
  • 减少服务器的 HTTP 响应的数据⼤小

Below, we will take a look at the optimization methods for these three ideas.
insert image description here

1. How to avoid sending HTTP requests?

Do you find this idea strange? If you don't send HTTP requests, how can the client interact with the server? Aren't you a hooligan?

Calm down, you're right, of course the client has to send a request to the server.

However, for some repetitive HTTP requests, for example, the data obtained from each request is the same, we can use this pair of "request-response" data 缓存在本地, and then directly read the local data next time, It is no longer necessary to obtain the server's response through the network. In this case,
the performance of HTTP/1.1 will definitely be improved.

Therefore, the way to avoid sending HTTP requests is to pass . The 缓存技术HTTP designers have taken this into account long ago, so there are many fields in the header of the HTTP protocol for caching.
How does the cache do it?

The client will save the data of the first request and the response on the local disk, where the requested URL is used as the key, and the response is used as the value, and the two form a mapping relationship.

In this way, when the same request is subsequently initiated, the corresponding value, that is, the response, can be found through the key on the local disk first, and if found, the response will be read directly from the local. Undoubtedly, the speed of reading the disk this time is definitely much faster than the network request, as shown in
insert image description here
the figure below: You may have thought that if the cached response is not the latest, but the client does not know, what should you do?

Rest assured, the HTTP designers have long considered this issue.

Therefore, 服务器在发送 HTTP 响应时,会估算⼀个过期的时间,并把这个信息放到响应头部中when the client checks the information in the response header, once it finds that the cached response is expired, it will resend the network request.

If the client finds that the response has expired from the response header obtained from the first request, and the client resends the request, assuming that the resources on the server have not changed, it is still the same. on this resource?

Obviously, without it, the performance of the HTTP protocol can be improved. How to do it?
Only when the client resends the request 在请求的 Etag 头部带上第⼀次请求的响应头部中的摘要, this digest is the only resource that identifies the response. When the server receives the request, it will compare the digest of the local resource with the digest in the request.

If it is different, it means that the client's cache has no value, and the server brings the latest resources in the response.
If it is the same, it means that the client's cache can still be used, then the server 仅返回不含有包体的 304 Not Modified 响应tells the client that it is still valid, which can reduce the delay of response resource transmission in the network, as shown in the figure below:
insert image description here
Cache is really a performance optimization. The master key, ranging from CPU Cache, Page Cache, Redis Cache, to HTTP protocol cache.

2. How to reduce the number of HTTP requests

Reducing the number of HTTP requests naturally improves HTTP performance. You can start from these three aspects:

  • 减少重定向请求次数
  • 合并请求
  • 延迟发送请求

1. Reduce the number of redirect requests

Let's take a look at what is 重定向请求?

After a resource on the server may be moved from url1 to url2 due to migration, maintenance and other reasons, and the client does not know it, it continues to request url1. At this time, the server cannot rudely return an error, but through the 302response code and Locationheader , Tell the client that the resource has been migrated to url2
, so the client needs to send a url2 request to obtain the server's resource.

Then, if there are more redirected requests, the client will have to initiate HTTP requests multiple times, and each HTTP request has to go through the network, which will undoubtedly reduce the network performance.

In addition, there is often more than one server on the server side. For example, the upper level of the source server is a proxy server, and then the proxy server communicates with the client. At this time, client redirection will lead to the need for the connection between the client and the proxy server. 2 message delivery, as shown in the figure below:
insert image description here
If the redirection is done by the proxy server, the number of HTTP requests can be reduced, as shown in the figure below:

insert image description here
And when the proxy server knows the redirection rules, it can further reduce the number of message transmissions, as shown in the figure below:
insert image description here
In addition to the 302redirection response code, there are other redirection response codes, as you can see from
insert image description here
the figure below: , 301and The 308response code tells the client that the redirection response can be cached to the local disk, and then the client automatically uses url2 instead of url1 to access the server's resources.

2. Merge Request

If multiple requests for accessing small files are combined into one large request, although the total resources transmitted are still the same, reducing the number of requests means that 减少重复发送的 HTTP 头部.

In addition, since HTTP/1.1 is a request-response model, if the first request sent does not receive a corresponding response, subsequent requests will not be sent. Therefore, in order to prevent the blocking of a single request, the general browser will initiate a simultaneous request. 5-6 requests, each request is a different TCP connection, so if the request is merged, it will be 减少 TCP 连接的数量,因⽽省去了 TCP 握⼿和慢启动过程耗费的时间.

Next, let's take a look at several ways to merge requests.

Some web pages contain many small pictures and small icons, and as many small pictures as there are, how many requests the client will initiate. Then for these small pictures, we can consider using CSS Image Spritestechnology to combine them into a large picture, so that the browser can obtain a large picture with one request,
and then cut the large picture into multiple small pictures according to CSS data sheet.
insert image description here
This way is通过将多个小图片合并成⼀个大图片来减少 HTTP 请求的次数,以减少 HTTP 请求的次数,从⽽减少⽹络的开销。

In addition to merging small pictures into large pictures, the server also uses webpackpackaging tools such as js, css and other resources to combine and package into large files, which can also achieve a similar effect.

In addition, you can also encode the binary data of the picture, base64sneak into the HTML file in the form of URL, and send it along with the HTML file.

<image
src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAPoAAAFKCAIAAAC7M9WrAAAACXBIWXMAA …
/>

In this way, after the client receives the HTML, it can directly decode the data, and then directly display the image, so there is no need to initiate image-related requests, which reduces the number of requests.
insert image description here
As you can see, 合并请求的⽅式就是合并资源,以⼀个⼤资源的请求替换多个⼩资源的请求.

But such a merge request creates a new problem, 当大资源中的某⼀个小资源发⽣变化后,客户端必须重新下载整个完整的⼤资源⽂件which obviously brings additional network consumption.

Delay sending request

Don't eat a big fat man in one go. Generally, HTML will contain a lot of HTTP URLs. We don't need to get resources that are not needed at present, so we can use " 按需获取" to reduce the first HTTP requests. frequency.

When requesting a web page, it is not necessary to obtain all resources, but only the page resources that the current user sees. When the user swipes down the page, the next resources are obtained from the server, so as to achieve The effect of delaying sending the request.

3. How to reduce the data size of HTTP response?

For HTTP requests and responses, usually the data size of the HTTP response will be relatively large, that is, the resources returned by the server will be relatively large.

Therefore, we can consider compressing the resources of the response, so that the data size of the response can be reduced, thereby improving the efficiency of network transmission.

Compression methods are generally divided into two types, namely:

  • ⽆损压缩
  • 有损压缩

lossless compression

Lossless compression means that after the resource is compressed, the information is not destroyed, and it can be completely restored to the original state before compression. It is suitable for use in text files, program executable files, and program source code.

First of all, we compress the syntax rules of the code, because usually the code file has many line breaks or spaces. These are to help programmers read better, but these characters are not needed when the machine executes them. Redundant symbols are removed.

The next step is lossless compression. It is necessary to build a statistical model for the original resources. Using this statistical model, the frequently occurring data is represented by a shorter binary bit sequence, and the less frequently occurring data is represented by a longer one. The binary bit sequence representation of , and the generation of the binary bit sequence is generally a "Huffman coding" algorithm.

gzip is a relatively common lossless compression. The compression algorithm supported by the client will tell the server in the HTTP request through the Accept-Encoding field in the header:
Accept-Encoding: gzip, deflate, br

After the server receives it, it will select a compression algorithm supported by the server or a suitable compression algorithm, and then use this compression algorithm to compress the response resource, and finally tell the client the compression used by the resource through the content-encodingfield algorithm.
content-encoding: gzip

Compared with the Brotli algorithm introduced by Google, the compression efficiency of gzip is almost meaningless, that is, the br in the above, so if possible, the server should choose the br compression algorithm with higher compression efficiency.

lossy compression

The opposite of lossless compression is lossy compression. After this method of compression, the decompressed data will be different but very close to the original data.

Lossy compression mainly discards secondary data and sacrifices some quality to reduce the amount of data and improve the compression ratio. This method is often used to compress multimedia data, such as audio, video, and pictures.

The server can be told the expected resource quality through the "q quality factor" in the Accept field in the HTTP request header.
Accept: audio/*; q=0.2, audio/basic

Regarding the compression of pictures, the one with higher compression is currently launched by Google. The comparison of WebP 格式the compression ratio of it with the common Png format pictures is as follows:
insert image description here
It can be found that under the same picture quality, the size of the pictures in the WebP format is larger than that in the Png format. The pictures are small, so for websites with a large number of pictures, you can consider using pictures in WebP format, which will greatly improve the performance of network transmission.

Regarding the compression of audio and video, audio and video are mainly dynamic, and each frame has a time sequence relationship. Usually, the changes between consecutive time frames are very small.

For example, in a video of reading a book, usually only the characters' hands and the book on the desk will change, while other parts are usually static, so only a static key frame is needed to make the It is used 增量数据to express subsequent frames, which reduces a lot of data and improves the performance of network transmission. Common encoding formats for video include H264, H265, etc., and common encoding formats for audio include AAC and AC3.

4. Summary

This time, I mainly introduce the idea of ​​optimizing the HTTP/1.1 protocol from three aspects.

The first idea is to avoid sending HTTP requests through caching technology. After the client receives the response of the first request, it can cache it on the local disk. When the next request is made, if the cache has not expired, it will directly read the locally cached response data. If the cache expires, the client sends a request with a summary of the response data. After the server compares and finds that the resource has not changed, it sends a 304 response without a body, telling the client that the cached response is still valid.

The second idea is to reduce the number of HTTP requests, there are the following methods:

  1. The redirection request originally processed by the client is handed over to the proxy server for processing, which can reduce the number of redirection requests;
  2. Combining multiple small resources into one large resource for transmission can reduce the number of HTTP requests and the repeated transmission of headers, and then reduce the number of TCP connections, thereby eliminating the network consumption of TCP handshake and slow start;
  3. Access resources on demand, only access the resources that the current user can see/use, when the customer slides down, and then access the next resources, so as to achieve delayed requests, which reduces the number of HTTP requests at the same time.

The third idea is to reduce the size of transmission resources by compressing response resources, thereby improving transmission efficiency, so a better compression algorithm should be selected.

No matter how you optimize the HTTP/1.1 protocol, it is limited, otherwise the HTTP/2 and HTTP/3 protocols will not appear, and we will introduce the HTTP/2 and HTTP/3 protocols later.

Guess you like

Origin blog.csdn.net/weixin_60297362/article/details/122983312