Since the release of HTTP/1.1 in 1997, HTTP/1.1 has quickly occupied the market, and to this day (2022) it is still the most widely used http protocol today. However, this does not mean that HTTP/1.1 is perfect, there are still many problems.
At present, HTTP 1.1 has gradually stabilized in terms of the format and function of the protocol itself after several iterations such as HTTP 0.9 and HTTP 1.0. The main problem of the current protocol is the problem caused by the underlying protocol that the original dependence on in the early stage of protocol development, that is, the problem caused by relying on TCP: slow efficiency.
In the early days of the http protocol, no one would have thought that a small browser could appear such a colorful content, the initial setting, just to publish and share files, will not consider the “interaction” experience problem at all, can not imagine that today’s browser client a page down, will produce so many requests. The original setting was simple: just to allow European scholars to share files and ensure the sharing of academic information; Therefore, reliability is the first priority, TCP is a reliable connection, and TCP was naturally chosen.
However, with the development of the Internet, the drawbacks of choosing TCP as the underlying protocol gradually became prominent: establishing a connection was complex and inefficient. TCP connection establishment requires three handshakes and four waves, and the process of creating and disconnecting is tedious and inefficient.
Before the http1.1 protocol, each request had to create a new link; it is known that the average site has 65 to 79 requests (2019 statistics), so it takes 65 ~ 79 requests to open such a website… Fortunately, after http1.1, the keep-alive field is added, which can reuse the original TCP link, without creating a TCP link with three handshakes per request, and without a response ending four times to close a TCP link, which improves the overall protocol efficiency to a certain extent. However, there are other problems, such as head-of-line blocking. Under the http1.1 protocol, the request order of all HTTP requests in the same website is executed in an streamlined order, that is, although the same TCP link channel may be shared, two requests under the same TCP link channel will have a blocking waiting condition: if the previous HTTP request is not processed, the second http request can only block the wait, so the stall time will affect the transmission efficiency of the overall protocol. Moreover, in different browsers, the number of concurrent connections under the same domain name is limited, such as Chrome browser, only allows a maximum of 6 concurrent connections under the same domain name, so that if an average website needs 65 ~ 79 http requests (2019 official statistics), assuming that they are all under the same domain name, at least 65 / 6 11 requests are required to wait to send all requests to finish. And suppose that a request in one of the link channels is delayed or waiting, which will directly block the request time in the queue behind the request.
In order to improve the overall performance of http, http2.0 optimizes the transmission of http protocol without changing the overall format and semantics of the current protocol, which greatly improves the overall transmission efficiency of http2.0. Feel the speed by clicking on the following link: https://http2.akamai.com/demo
The improvements in HTTP 2.0 are mainly aimed at the improvement of HTTP performance.
There are two main factors that affect the performance of http network communication: latency and bandwidth. With the continuous improvement of hardware capabilities and the popularity of 5G, bandwidth is gradually not a factor affecting network communication efficiency, and latency has become the main factor affecting http network communication. If you want to increase the latency, you need to find the reason from the network protocol itself. As early as 2009, Google began to study the factors that improve the performance of http; At that time, a protocol called SPDY was developed, and in 2012, it was supported by browsers such as Chrome, Firefox, and Opera, and successfully applied to large websites such as Google, Twitter, and Facebook. Since then, more and more companies want to use SPDY.
HTTP officials saw this trend and decided to model the SPDY protocol and transform the HTTP protocol, so there is now HTTP 2.0. The early HTTP2.0 basically inherited the SPDY protocol, and later extended on this basis. Similar to the SPDY protocol, HTTP 2.0 follows the following principles:
The goal is to increase network loading speed by more than 50%.
It is forbidden for the current HTTP user to make compatible modifications, so that the user’s application is unaware of the switch
Minimize modifications to the current network protocol structure
The principle of HTTP 2.0 and SPDY is very simple, that is, to imitate TCP’s unpacking to solve the current HTTP head-of-Line blocking problem to achieve the effect of multiple requests being transmitted concurrently and multiplexing.
Let’s talk about the improvements of http2.0 in detail:
Binary framing is the most significant change to HTTP 2.0, and the multiplexing of HTTP 2.0 is based on this.
Binary framing is on top of the current TLS protocol for HTTPS, abstracting a layer (that is, the premise of using HTTP 2.0 is that HTTPS must be used). A request can be split into multiple small packets at the time of transmission, multiple requests can be split into many packets at the same time to send together, to the server, the server then stitches according to the sequence number of the packet, to get the complete each request.
The minimum granularity of these split requests is called frame, which can be divided into two types of structures by type: Headers frame and data frame. The headers frame abstracts the request header, and the data frame abstracts the request body.
In addition to the frame structure, the entire binary framing layer also has two data structures, message and stream, and these data structures have an inclusion relationship: frame is the smallest, message contains multiple frames, stream contains multiple messages; The three data structures of frame, message, and stream together constitute the binary framing layer of http2.0. The connections and functions of the three data structures are as follows:
A frame is the smallest unit of transmission and has a special internal identifier that distinguishes which stream this frame belongs to
The message is a logical level thing, not reflected in the specific implementation, mostly used to indicate whether to request a message or a corresponding message, a messsage contains multiple frames
A stream is the most granular “packet” of HTTP 2.0 transmission, which contains uniqueness fields and priority information, and can contain requests or corresponding messages.
So, how does http2.0 implement multiplexing and solve the head of block problem of http1.1?
First of all, all requests for http2.0 are transmitted only in one tcp connection, and http2.0 will split all current requests into countless small frames (in fact, at this time, different streams have been distinguished).
Then, according to the identification information in each frame (the frame is marked with a stream ID), a stream is formed, and finally the various streams are transmitted in a tcp bidirectional pipeline.
Note: Although there is a message structure in the binary framing protocol, it is only a logical-level structure that distinguishes between a request and a response piece of information and does not participate in the actual protocol implementation. The underlying implementation has only streams and frames
After receiving various types of streams, the client and server terminals spell out the complete request or response stream array according to the logo of steam, and then parse out the complete request or response information according to the frame information in the stream array.
In this way, the multiplexing of http in transit is realized.
It is worth mentioning that in the transmission process of http2.0, we no longer use plain text, but transmit the requested data in binary (0 or 1) form, which also reduces the additional performance overhead caused by text escaping;
During the http1.1 transmission, the request body can be compressed according to gzip, but the request header is not processed, and as the number of requests on the website increases, after http2.0, the request header is also compressed.
For a site, the information in the request header in most requests is duplicated, and only a few header properties are different.
In order to increase the transmission rate, http2.0 in the transmission, will maintain a request for header information of the hash table, and stored in the client and server at the same time, each time the transmission, if the transmitted header information is found to exist in the hash table, then only the index value of the hash table, no longer transmit the specific content, so that greatly reduce the transmission of data. At the same time, if there is a new header field, the hash table will also dynamically add new values on the client and server side, and when there are the same fields in the future, it will no longer be transmitted, and only the index value of the hash table will be transmitted.
In fact, the so-called hash table above is subdivided into two tables: one is called a static table and the other is called a dynamic table. Static tables are some common values that hold the HTTP protocol itself fixed:
Dynamic tables hold some site-specific property fields that increase as the fields in the request change.
After that, the contents of the request header become mostly data that is the index value of the hash table except for a small number of header fields; But that’s not all, and http2.0 will also encode existing data content, compressing it again.
The above is the http2.0 header compression algorithm, called the HACK algorithm.
Different from the request-response mode of http1.1, http2.0 can push messages from the server to the client, but the push method here is different from the two-way communication of tcp or websocket, which has certain limitations.
Under the common http1.1 protocol, the client and server communicate strictly in a request-response. This leads to a situation where some requests appear redundant. For example, to request a website page, after returning the main html file, the content of the css, js and other files inlined in the html file must be requested by additional clients in order to get the data from the server; These inline data files are certain and must be obtained, so it seems that in the http1.1 scenario, these inline data files must be requested again by the client to get the response data of the server; in the http2.0 scenario, the server will prejudge and actively push the data necessary in the next request according to other files associated with the file. http2.0 data push is limited to this, different from tcp, websocket two-way communication, we should pay special attention.
Here some people may ask: “http provides caching capabilities, what if the data pushed is in the client-side cache?” In fact, it is very simple, if the server pushes the data over, the client can choose to give up or save the pushed data, but if the client actively gives up the data pushed, it is actually a waste of an http response transmission; There is a better way for http2.0 to tell the server the cache information that the client already has, and after the server judges, it can only push the non-existent data information.