HTTP protocol: HTTP/1.1 and HTTP/2

Introduction

The full name of HTTP is Hypertext Transfer Protocol, which is a standard protocol that appeared after the development of the World Wide Web in 1989 and is used to transmit data on the WWW. HTTP/1.1 is a supplement and optimization based on the original HTTP protocol in 1997.

In 2015, in order to meet the needs of fast-transmitting web applications and modern browsers, a new HTTP/2 protocol has been developed, which is mainly optimized in mobile browsers, delay processing, image processing and video processing.

Basically all modern browsers support the HTTP/2 protocol, but there are still many applications that use the old HTTP/1.1 protocol. This article will introduce the difference between HTTP/1.1 and HTTP/2.

HTTP/1.1

HTTP 1.0 was released by Timothy Berners-Lee in 1989 as the standard protocol of the World Wide Web. Generally, HTTP methods such as GET or POST are used to transmit messages between the client and the server in the form of TEXT text.

We can use post man to make HTTP requests very conveniently, as shown below:

GET /index.html HTTP/1.1
Host: www.flydean.com

The client requests the server-side /index.html page through a GET request. The protocol used is HTTP/1.1. After the server receives the request, it will return the corresponding text to the client.

The HTTP protocol is an encapsulation of the underlying TCP/IP protocol, because we do not need to hand over the underlying details of specific message splitting and encapsulation, but only need to focus on the specific business logic, which is very convenient.

HTTP/2

HTTP/2 was developed from the SPDY protocol. Its initiator was Google. It was originally designed to introduce new technologies such as compression and multiplexing in web interactions, and was eventually used as part of the HTTP/2 protocol in 2015.

Earlier we mentioned that HTTP/1.1 is transmitted in the form of text. The disadvantage of this is that the data occupies a larger space. Compared with HTTP/1.1, HTTP/2 uses binary transmission and uses binary to pair messages. Encapsulation, while retaining the semantics of HTTP, such as methods, first, etc.

This kind of binary encapsulation is unaware of the application layer. For the application, the HTTP request is created according to the usual method, and the work of encapsulating it into a binary is done by HTTP/2.

Transmission mode comparison

In HTTP1.0, whenever the client requests a page from the server, it often returns not a complete page, but additional resource link information that the page needs, because the complete page requires all resources to be downloaded It can only be displayed after completion, so in HTTP1.0, the client needs to interrupt the current connection, and then re-establish a new connection to request resources. This will consume extra resources and time.

In HTTP1.1, the concept of persistent connections and pipes is introduced, so that there is no need to reopen and create new connections every time a request is made. By default, the underlying TCP connection of HTTP is open, unless you manually tell it to close. In this case, the client can use the same connection to interact with the server, which greatly improves the efficiency of HTTP.

Although the same connection can be used for data transmission in HTTP1.1, for this connection, the requests are responded to one by one, and they are in order. If the first request is blocked, the subsequent requests will not receive a response. This situation is called head-of-line (HOL) blocking.

In order to solve this problem, multiple connections can be established on the client and server sides, so that multiple connections can be used to transmit data in parallel, thereby improving transmission efficiency.

But the disadvantage of this is that new connections will consume too many resources, and the number of connections between the client and the server is also limited.

So HTTP/2 appeared.

In HTTP/2, data is transmitted in a binary format, which itself divides the original request into smaller information packets, which greatly increases the flexibility of data transmission.

HTTP1.1 needs to establish multiple TCP connections to solve the problem of parallel transmission, but in HTTP/2, only one connection needs to be established. Multiple data streams can be transmitted in this connection, and each data stream contains multiple message packets, and each message is divided into multiple data frames.

These data frames can be exchanged during transmission and then reassembled at the other end of the receiving end. Interleaved requests and responses can run in parallel, so as not to block the messages behind them. This process is called multiplexing. The multiplexing mechanism eliminates the need for one message to wait for the completion of another message, thus solving the problem of head-of-line blocking in HTTP/1.1. This also means that the server and client can send concurrent requests and responses, thereby achieving better control and more effective connection management.

Although multiplexing constructs multiple message streams, it only occupies one TCP connection, thereby reducing the memory and processing space of the entire network, resulting in better network and bandwidth utilization, thereby reducing overall operating costs.

A single TCP connection also improves the performance of the HTTPS protocol, because the client and server can reuse the same secure session for multiple requests/responses. In HTTPS, during the TLS or SSL handshake, both parties use a single key for the entire session. If the connection is interrupted and a new session is restarted, the newly generated key is required for further communication. Therefore, maintaining a single connection can greatly reduce the resources required for HTTPS.

Please note that although the HTTP/2 specification does not mandate the use of TLS, many major browsers only support HTTP/2 with HTTPS.

Stream priority

Although HTTP/2 solves the problem of the usual transmission of multiple data frames, for the same resource, it must wait until all the data frames have been accepted before it can be displayed. What if we want to display a certain resource first? ?

HTTP/2 provides a solution to stream priority.

When the client sends a message to the server, the message will be transmitted in the connection in the form of a stream. These streams can be assigned a weight between 1 and 256 to determine the priority of the response to their request. The larger the number, the higher the priority. In addition, the client also illustrates the dependence of each stream on another stream by specifying the ID of the stream it depends on. If the parent identifier is omitted, the stream is considered to be dependent on the root stream.

The server will use the IDs in the stream to build a dependency tree to determine its corresponding order.

Application developers can set the priority of the request according to their needs, such as providing low-resolution thumbnails on the web page while providing low-priority high-resolution images. By assigning different priorities to resources, developers can better control the rendering of web pages.

Buffer overflow handling

Regardless of the protocol, the client and server have a buffer to temporarily store data that cannot be processed temporarily when receiving data, but the size of the buffer is limited, so buffer overflow may occur For example, if the client uploads a large picture to the server, it may cause the buffer overflow on the server and cause some extra data packets to be lost.

In order to avoid buffer overflow, various HTTP protocols provide certain solutions.

In HTTP1.1, flow control relies on the underlying TCP protocol. When a connection is established between the client and the server, the system default settings are used to establish a buffer. When data is being communicated, it will tell the other party the size of its receiving window, which is the remaining free space in the buffer. If the receiving window size is zero, it means that the receiver's buffer is full, and the sender will no longer send data until the client clears its internal buffer, and then requests to resume data transmission.

Because HTTP1.1 uses multiple TCP connections, it is possible to perform separate flow control for each TCP connection. But HTTP2 uses a multiplexing mode, so its flow control method is different from HTTP1.1.

HTTP2 is the transmission of buffer size messages through the client and server applications, and the data flow is controlled at the application layer level, so each application can control the size of the flow by itself, thereby achieving higher connection efficiency.

HTTP/2 provides a more detailed level of control, which opens up the possibility of greater optimization.

Forecast resource requests

In a typical web application, when the client sends a GET request to the server, the client usually finds that it needs more than one resource, and it may also include resources such as CSS or other JS. But the client can only really confirm which resources are needed when it gets the response from the server for the first time. Then you need to request additional resources to complete the entire request. But these additional requests will eventually increase the connection load time.

So is it possible that the server sends the resource to the client before the client requests it? Let's see how HTTP1.1 and HTTP2 are done.

In HTTP1.1, the main method of resource inlining is used, such as including CSS or JS resources required by the client in the HTML document originally sent by the server, that is, doing inline operations, thereby reducing the amount that the client must send The total number of requests.

But such solutions also have problems. Because in general resource inlining is generally for smaller resources, if the resource file is too large, it will greatly increase the size of the HTML file, thereby offsetting the speed advantage of reducing the connection.

In addition, if the resources are placed in HTML, then the client has no possibility to cache these resources, which affects the overall efficiency.

Server push is used in HTTP/2. Because HTTP/2 can send multiple streams in the same connection, the server can send the resource to the client together with the requested HTML page, and provide the resource before the client requests it. This process is called server push.

In this way, the separation and simultaneous push of HTML documents and resources can be realized without having to open a new connection.

But in HTTP/2, server push is controlled by the application, so it will be more complicated to control. We will explain HTTP/2 server push in detail in a follow-up article.

compression

Usually in order to reduce the transmission of data on the network, we need to compress the data. Next, let's take a look at how it is done in HTTP1.1 and HTTP2.

In HTTP1.1, gzip is usually used to compress messages in HTTP, mainly for CSS files and javascript files, but HTTP message headers are still sent in plain text. In addition, due to the use of cookies, HTTP message headers are The size will become larger and larger, which will have a certain impact on the performance of the program.

In HTTP/2, the algorithm used is the HPACK algorithm, and the HTTP header and data can be compressed separately, thereby greatly reducing its size.

Summarize

HTTP/2 performs more fine-grained optimization control on the basis of HTTP1.1, and provides advanced features including multiplexing, stream priority, flow control, server push, and compression. Very powerful. Hope everyone likes it.

This article has been included in http://www.flydean.com/02-http1-1-vs-http2/

The most popular interpretation, the most profound dry goods, the most concise tutorial, and many tips you don't know are waiting for you to discover!

Welcome to pay attention to my official account: "Program those things", know technology, know you better!