web in browser

web in browser

HTTP/1: HTTP Performance Optimization

Hypertext Transfer Protocol HTTP/0.9

HTTP/0.9 was proposed in 1991. It is mainly used for academic communication. The requirement is very simple - it is used to transmit HTML hypertext content between networks, so it is called Hypertext Transfer Protocol . On the whole, its implementation is also very simple, using a request-response-based mode, where a request is sent from the client, and the server returns data.

Let's take a look at a complete request process of HTTP/0.9 (see the figure below).

• Because HTTP is based on the TCP protocol, the client must first establish a TCP connection according to the IP address, port, and server, and the process of establishing a connection is the three-way handshake process of the TCP protocol.
• After the connection is established, a GET request line information will be sent, such as GET /index.htmlused to obtain index.html.
• After the server receives the request information, it reads the corresponding HTML file and returns the data to the client in ASCII character stream.
• After the HTML document transfer is complete, disconnect.

[External link picture transfer failed, the source site may have an anti-leeching mechanism, it is recommended to save the picture and upload it directly (img-BUmDTzmd-1683724254905)(null)]

The requirement at that time was very simple, it was used to transmit small HTML files, so the implementation of HTTP/0.9 had the following three characteristics.

• The first one is that there is only one request line, and there is no HTTP request header and request body , because only one request line is needed to fully express the client's needs.
• The second is that the server does not return header information, because the server does not need to tell the client too much information, it only needs to return data.
• The third is that the returned file content is transmitted in ASCII character stream, because all files are in HTML format, so it is most appropriate to use ASCII byte code for transmission.

HTTP/1.0

HTTP/1.0 introduced request headers and response headers, both of which are stored in the form of Key-Value. When HTTP sends a request, it will bring the request header information, and when the server returns data, it will first return the response header information.

To support multiple types of files, the following issues need to be addressed.

• First of all, the browser needs to know what type of data the server returns, and then the browser can perform targeted processing according to different data types.
• Secondly, as the applications supported by the World Wide Web become more and more extensive, the data volume of a single file becomes larger and larger. In order to reduce transmission performance, the server will compress the data before transmission, so the browser needs to know the method of server compression.
• Again, since the World Wide Web supports the global scope, internationalization support needs to be provided, and the server needs to provide different language versions for different regions, which requires the browser to tell the server what language version of the page it wants.
• Finally, due to the addition of various types of files, and the encoding form of each file may be different, in order to read the file accurately, the browser needs to know the encoding type of the file.

Based on the above problems, the HTTP/1.0 solution is to negotiate through the request header and the response header. When the request is initiated, the HTTP request header will tell the server what type of file it expects the server to return, what form of compression to use, and what language to provide. The file and the specific encoding of the file. The final sent request header content is as follows:

accept: text/html
accept-encoding: gzip, deflate, br
accept-Charset: ISO-8859-1,utf-8
accept-language: zh-CN,zh

The first line indicates that the server is expected to return a file of type html, the second line indicates that the server can use one of the compression methods of gzip, deflate or br, and the third line indicates that the encoding of the returned file is expected to be UTF-8 or ISO-8859- 1. The fourth line indicates that the preferred language of the desired page is Chinese.

After the server receives the request header information sent by the browser, it will prepare the response data according to the request header information. But sometimes there will be some unexpected situations, such as the compression type requested by the browser is gzip, but the server does not support gzip, only supports br compression, then it will tell the browser the final compression type through the content-encoding field in the response header , which means that the final browser needs to process the data according to the information in the response header.

content-encoding: br
content-type: text/html; charset=UTF-8

The first line indicates that the server adopts the compression method of br, and the second line indicates that the server returns an html file, and the encoding type of the file is UTF-8.

With the response header information, the browser will use the br method to decompress the file, then process the original file according to the UTF-8 encoding format, and finally parse the file according to the HTML method. This is a basic processing flow for HTTP/1.0 to support multiple files.

In addition to providing good support for multiple files, HTTP/1.0 also introduced many other features based on the actual needs at the time, and these features were implemented through request headers and response headers. Several new typical features:

• Some requests may not be processed by the server, or may be processed incorrectly. At this time, it is necessary to tell the browser server how to finally process the request, which introduces the status code . The status code is notified to the browser through the response line.
• In order to reduce the pressure on the server, a Cache mechanism is provided in HTTP/1.0 to cache downloaded data.
• The server needs to count the basic information of the client, such as the number of users of Windows and macOS, so the HTTP/1.0 request header also adds the user agent field.

HTTP/1.1

Improve persistent connections

Every time HTTP/1.0 conducts HTTP communication, it needs to go through three stages of establishing a TCP connection, transmitting HTTP data, and disconnecting the TCP connection (as shown in the figure below).

HTTP/1.1 added a persistent connection method, which is characterized in that multiple HTTP requests can be transmitted on one TCP connection, as long as the browser or server does not explicitly disconnect, the TCP connection will always be maintained .

[External link picture transfer failed, the source site may have an anti-leeching mechanism, it is recommended to save the picture and upload it directly (img-TCMUUxMD-1683724254944)(null)]

HTTP's persistent connection can effectively reduce the number of TCP connection establishment and disconnection, which has the advantage of reducing the additional burden on the server and increasing the overall HTTP request time.

Persistent connections are enabled by default in HTTP/1.1, so you don't need to set information in the HTTP request header specifically for persistent connections. If you don't want to use persistent connections, you can add them to the HTTP request header Connection: close. At present, for the same domain name in the browser, 6 TCP persistent connections are allowed to be established at the same time by default.

Immature HTTP pipelining

Although a persistent connection can reduce the number of TCP establishment and disconnection, it needs to wait for the previous request to return before making the next request. If a request in the TCP channel does not return in time for some reason, all subsequent requests will be blocked, which is the famous head-of-line blocking problem.

HTTP/1.1 tries to solve the problem of head-of-line blocking through pipeline technology . Pipelining in HTTP/1.1 refers to the technology of submitting multiple HTTP requests to the server in batches. Although the requests can be sent in batches, the server still needs to reply to the browser's requests according to the order of the requests.

Both FireFox and Chrome have done pipelining experiments, but due to various reasons, they finally gave up the pipelining technology.

Provide virtual hosting support

In HTTP/1.0, each domain name is bound to a unique IP address, so a server can only support one domain name. However, with the development of virtual host technology, it is necessary to bind multiple virtual hosts on one physical host, and each virtual host has its own separate domain name, and these separate domain names share the same IP address.

Therefore, the HTTP/1.1 request header adds a Host field to indicate the current domain name address, so that the server can perform different processing according to different Host values.

Perfect support for dynamically generated content

When designing HTTP/1.0, it is necessary to set the complete data size in the response header, for example Content-Length: 901, so that the browser can receive data according to the set data size. However, with the development of server-side technology, the content of many pages is dynamically generated, so the final data size is not known before the data is transmitted, which leads to the browser not knowing when it will receive all the file data.

HTTP/1.1 solves this problem by introducing the Chunk transfer mechanism. The server will divide the data into several data blocks of any size, and each data block will be sent with the length of the previous data block, and finally use a zero- length block As a sign of the completion of sending data. This provides support for dynamic content.

Client Cookie, Security Mechanism

HTTP/1.1 also introduces client-side cookie mechanism and security mechanism.

HTTP/2: How to improve network speed?

The main problems with HTTP/1.1

HTTP/1.1 has made a lot of optimizations for network efficiency. The core methods are as follows:

1. Added persistent connection;
2. The browser maintains up to 6 TCP persistent connections for each domain name at the same time;
3. Use CDN to implement domain name sharding mechanism.

HTTP/1.1 's utilization of bandwidth is not ideal , which is also a core problem of HTTP/1.1

Bandwidth refers to the maximum number of bytes that can be sent or received per second . The maximum number of bytes that can be sent per second is called the upstream bandwidth , and the maximum number of bytes that can be received per second is called the downstream bandwidth .

The reason why HTTP/1.1 is not ideal for bandwidth utilization is because HTTP/1.1 is difficult to use up bandwidth. For example, the commonly said 100M bandwidth, the actual download speed can reach 12.5M/S, but when HTTP/1.1 is used, it may only be able to use up to 2.5M/S when loading page resources, and it is difficult to use up all 12.5M.

The reason for this problem is mainly caused by the following three reasons.

The first reason, TCP's slow start.

Once a TCP connection is established, it enters the state of sending data. At the beginning, the TCP protocol will use a very slow speed to send data, and then slowly increase the speed of sending data until the speed of sending data reaches an ideal state. We put This process is called slow start.

You can think of the process of each TCP sending data as the start-up process of a car. When it first enters the road, there will be a speed-up process from 0 to a stable speed. The slow start of TCP is similar to this process.

Slow start is a strategy of TCP to reduce network congestion, and we have no way to change it.

The reason why slow start will cause performance problems is because some key resource files commonly used in the page are not large, such as HTML files, CSS files, and JavaScript files. Usually, these files will initiate requests after the TCP connection is established. Yes, but the process is slow-start, so it takes a lot longer than normal, delaying the precious first render of the page.

The second reason is that multiple TCP connections are opened at the same time, and these connections will compete for a fixed bandwidth.

You can imagine that the system establishes multiple TCP connections at the same time. When the bandwidth is sufficient, the sending or receiving speed of each connection will slowly increase; and once the bandwidth is insufficient, these TCP connections will slow down the sending or receiving speed. . For example, if a page has 200 files and 3 CDNs are used, then 6 * 3, that is, 18 TCP connections need to be established to download resources when loading the web page; during the download process, when the bandwidth is found to be insufficient, each TCP connections need to dynamically slow down the speed at which data is received.

This will cause a problem, because some TCP connections download some key resources, such as CSS files, JavaScript files, etc., while some TCP connections download ordinary resource files such as pictures and videos, but between multiple TCP connections It is impossible to negotiate which key resources should be downloaded first, which may affect the download speed of those key resources.

The third reason is the problem of HTTP/1.1 head-of-line blocking.

When persistent connections are used in HTTP/1.1, although one TCP pipeline can be shared, only one request can be processed at a time in one pipeline, and other requests can only be blocked until the current request ends. This means that we cannot send requests and receive content in one pipeline at will.

This is a very serious problem, because there are many factors that block requests, and they are all uncertain factors. If some requests are blocked for 5 seconds, then subsequent queued requests will be delayed for 5 seconds. In this During the waiting process, bandwidth and CPU are wasted.

In the process of browser processing and generating pages, it is very desirable to receive data in advance, so that the data can be preprocessed. For example, if a picture is received in advance, then the encoding and decoding operation can be performed in advance, and when the need to use the When it comes to pictures, the processed data can be directly given, so that users can feel the overall speed improvement.

But head-of-line blocking prevents these data from being requested in parallel, so head-of-line blocking is not conducive to browser optimization.

Multiplexing with HTTP/2

Slow start and competition for bandwidth between TCP connections are due to the mechanism of TCP itself, while head-of-line blocking is caused by the mechanism of HTTP/1.1.

The idea of ​​HTTP/2 is that a domain name only uses one TCP long-term connection to transmit data, so that the download process of the entire page resource only needs one slow start, and also avoids the problems caused by multiple TCP connections competing for bandwidth.

In addition, there is the problem of head-of-queue blocking. Waiting for the request to complete before requesting the next resource is undoubtedly the slowest method, so HTTP/2 needs to implement parallel resource requests, that is, requests can be sent to The server does not need to wait for the completion of other requests, and then the server can return the processed request resources to the browser at any time.

Therefore, the solution of HTTP/2 can be summarized as: a domain name only uses one TCP long connection and eliminates the head-of-line blocking problem .

This figure is the core, most important and most disruptive multiplexing mechanism of HTTP/2 . Each request has a corresponding ID, such as stream1 indicates the request of index.html, and stream2 indicates the request of foo.css. In this way, on the browser side, the request can be sent to the server at any time.

After receiving these requests, the server will decide which content to return first according to its own preferences. For example, the server may have already cached the response header information of index.html and bar.js, so when the request is received, it can immediately Return the response header information of index.html and bar.js to the browser, and then return the response body data of index.html and bar.js to the browser. The reason why it can be sent at will is because each piece of data has a corresponding ID. After receiving it, the browser will filter out the content with the same ID and splice it into a complete HTTP response data.

HTTP/2 uses multiplexing technology, which can divide the request into frame-by-frame data for transmission, which brings an additional benefit, that is, when a high-priority request is received, such as JavaScript or For CSS key resource requests, the server can suspend previous requests to prioritize key resource requests.

Implementation of multiplexing

HTTP/2 adds a binary framing layer , combined with the graph to analyze the HTTP/2 request and receiving process.

• First, the browser prepares the request data, including request line, request header and other information. If it is a POST method, there is also a request body.
• After the data is processed by the binary framing layer, it will be converted into frames with request ID numbers, and these frames will be sent to the server through the protocol stack.
• After the server receives all frames, it will combine all frames with the same ID into a complete request message.
• Then the server processes the request, and sends the processed response line, response header and response body to the binary framing layer respectively.
• Similarly, the binary framing layer converts these response data into frames with request ID numbers and sends them to the browser through the protocol stack.
• After the browser receives the response frame, it will submit the data of the frame to the corresponding request according to the ID number.

It can be seen from the above process that the HTTP multiplexing technology is realized by introducing the binary framing layer .

Other features of HTTP/2

You can set the priority of the request

HTTP/2 provides request priority, which can be marked with the priority of the request when sending the request, so that after the server receives the request, it will give priority to the request with higher priority.

server push

HTTP/2 can also push data ahead of time directly to the browser. Imagine such a scenario, when a user requests an HTML page, the server knows that the HTML page will refer to several important JavaScript files and CSS files, then after receiving the HTML request, the CSS file and JavaScript file to be used will be sent together To the browser, so that after the browser parses the HTML file, it can directly get the required CSS file and JavaScript file, which plays a vital role in the speed of opening the page for the first time.

head compression

HTTP/2 compresses request and response headers

HTTP/3: Get rid of the burden of TCP and TLS to build an efficient network

TCP head-of-line blocking

HTTP/2 solves the head-of-line blocking problem at the application level, but like HTTP/1.1, HTTP/2 is still based on the TCP protocol, and TCP was originally designed for a single connection. Think of a TCP connection as a virtual pipeline between two computers. One end of the computer puts the data to be transmitted into the pipeline in order, and the final data will appear in the same order at the other end of the pipeline.

[External link picture transfer failed, the source site may have an anti-leeching mechanism, it is recommended to save the picture and upload it directly (img-IvlvrLeo-1683724254994)(null)]

The data sent from one end to the other end will be split into data packets arranged in order, and these data packets will be transmitted to the receiving end through the network, and the receiving end will combine these data packets into original data in order, and this is done data transmission.

However, if a data packet is lost due to network failure or other reasons during data transmission, the entire TCP connection will be suspended, waiting for the lost data packet to be retransmitted. You can think of a TCP connection as a pipeline that transmits data in order. If any data in the pipeline is lost, the subsequent data needs to wait for the retransmission of the data.

In the process of TCP transmission, the blocking caused by the loss of a single data packet is called head-of-line blocking on TCP

Under normal circumstances, how HTTP/2 transmits multiple requests

In HTTP/2, multiple requests run in a TCP pipeline. If packet loss occurs in any one of the data streams, all requests in the TCP connection will be blocked. This is different from HTTP/1.1. When using HTTP/1.1, the browser opens 6 TCP connections for each domain name. If one of the TCP connections is blocked by the head of the queue, the other 5 connections can still continue to transmit data. .

Therefore, as the packet loss rate increases, the transmission efficiency of HTTP/2 will become worse and worse.

TCP connection establishment delay

In addition to TCP head-of-line blocking, the TCP handshake process is also an important factor affecting transmission efficiency

Network delay is also called RTT (Round Trip Time). We call the entire round-trip time from sending a data packet from the browser to the server, and then returning the data packet from the server to the browser as RTT (as shown in the figure below). RTT is an important indicator reflecting network performance.

[External link picture transfer failed, the source site may have an anti-leeching mechanism, it is recommended to save the picture and upload it directly (img-qlWkGClP-1683724254967)(null)]

Both HTTP/1 and HTTP/2 are transmitted using the TCP protocol, and if HTTPS is used, the TLS protocol is also required for secure transmission, and the use of TLS also requires a handshake process, so two handshake delay processes are required.

1. When establishing a TCP connection, a three-way handshake with the server is required to confirm the connection is successful, that is to say, data transmission can only be performed after 1.5 RTTs are consumed.
2. For TLS connection, there are two versions of TLS - TLS1.2 and TLS1.3, each version takes different time to establish a connection, roughly 1 to 2 RTT

All in all, we need to spend 3-4 RTTs before transferring data. If the physical distance between the browser and the server is relatively close, then the time of 1 RTT may be within 10 milliseconds, which means that a total of 30-40 milliseconds will be consumed. This time may be acceptable to the user, but if the servers are far apart, one RTT may take more than 100 milliseconds. In this case, the entire handshake process takes 300-400 milliseconds, and the user can clearly feel " slow.

TCP protocol ossification

It is very difficult to solve these problems by improving the TCP protocol .

The first is the rigidity of the middleware . To figure out what an intermediate device is, we must first understand what an intermediate device is. We know that the Internet is a mesh structure interconnected by multiple networks. In order to ensure the normal operation of the Internet, we need to build various devices everywhere on the Internet. These devices are called intermediate devices.

There are many types of these intermediate devices, and each device has its own purpose. These devices include routers, firewalls, NATs, switches, etc. They usually rely on seldom-updated software that uses a large number of TCP features that are rarely updated after being set.

Therefore, if we upgrade the TCP protocol on the client side, but when the data packets of the new protocol pass through these intermediate devices, they may not understand the contents of the packets, so the data will be discarded. This is middleware ossification, which is a big obstacle to TCP updates.

In addition to the ossification of intermediate devices, the operating system is another reason for the ossification of the TCP protocol . Because the TCP protocol is implemented through the operating system kernel, the application program can only use it and cannot modify it. Usually the update of the operating system lags behind the update of the software, so it is very difficult to freely update the TCP protocol in the kernel.

QUIC protocol

HTTP/2 has some serious defects related to the TCP protocol, but due to the rigidity of the TCP protocol, it is almost impossible for us to solve these problems by modifying the TCP protocol itself. The idea to solve the problem is to bypass the TCP protocol and invent a TCP and A new transport protocol other than UDP. But this also faces the same challenge as modifying TCP, because of the rigidity of intermediate devices, these devices only recognize TCP and UDP, if a new protocol is adopted, the new protocol is not well supported by these devices.

Therefore, HTTP/3 chose a compromise method - the UDP protocol. Based on UDP, it implements functions such as multi-channel data streams and transmission reliability similar to TCP. We call this set of functions the QUIC protocol .

The QUIC protocol in HTTP/3 integrates the following functions.

• It realizes the functions of flow control and transmission reliability similar to TCP . Although UDP does not provide reliable transmission, QUIC adds a layer on top of UDP to ensure reliable data transmission. It provides packet retransmission, congestion control, and other features found in TCP.
• Integrated TLS encryption function . Currently, QUIC uses TLS1.3, which has more advantages than the earlier version of TLS1.3, the most important of which is that it reduces the number of RTTs spent in handshakes.
• Implements the multiplexing functionality in HTTP/2 . Unlike TCP, QUIC enables multiple independent logical data streams on the same physical connection (as shown in the figure below). Realizing the separate transmission of data streams solves the problem of head-of-queue blocking in TCP.
• A fast handshake function is implemented . Since QUIC is based on UDP, QUIC can use 0-RTT or 1-RTT to establish a connection, which means that QUIC can send and receive data at the fastest speed, which can greatly improve the speed of opening the page for the first time.

HTTP/3 Challenges

First, judging from the current situation, neither the server nor the browser provides relatively complete support for HTTP/3. Although Chrome started to support Google's version of QUIC several years ago, there is a big difference between this version of QUIC and the official QUIC.

Second, deploying HTTP/3 is also very problematic. Because the optimization of UDP by the system kernel is far from that of TCP, this is also an important reason for hindering QUIC.

It can greatly improve the speed of opening the page for the first time.

[External link image transfer...(img-AQyAt4f6-1683724251792)]

HTTP/3 Challenges

First, judging from the current situation, neither the server nor the browser provides relatively complete support for HTTP/3. Although Chrome started to support Google's version of QUIC several years ago, there is a big difference between this version of QUIC and the official QUIC.

Second, deploying HTTP/3 is also very problematic. Because the optimization of UDP by the system kernel is far from that of TCP, this is also an important reason for hindering QUIC.

Third, the problem of rigid intermediate equipment. The optimization degree of these devices to UDP is far lower than that of TCP. According to statistics, when using the QUIC protocol, there is a packet loss rate of about 3% to 7%.