Talking about HTTP connection related knowledge

[[374909]]

This article will first introduce the characteristics, advantages and disadvantages of HTTP, and then will introduce in detail the connection management of HTTP long connections and short connections. By reading this article, you can have a deep understanding of HTTP connections.

Through the previous HTTP series of articles, I believe everyone has already known the basic knowledge of the HTTP protocol, and understood its message structure, request header, response header and other details.

Characteristics of HTTP

So let's talk about the characteristics, advantages and disadvantages of the HTTP protocol. We should see its good side as well as its bad side. Only by understanding HTTP from all aspects and angles can we "strengthen its strengths and avoid its weaknesses" and make better use of HTTP.

Flexible and scalable

First of all, the HTTP protocol is a "flexible and extensible" transmission protocol.

The HTTP protocol was relatively simple when it was first created. In the spirit of openness, it only specified the basic format of the message, such as using spaces to separate words, using newlines to separate fields, "header+body", etc. There were no strict grammatical and semantic restrictions on the various components of the message and they could be customized by developers.

Therefore, the HTTP protocol has grown along with the development of the Internet. In this process, the HTTP protocol has gradually added features such as request methods, version numbers, status codes, and header fields. The body is no longer limited to text-based TXT or HTML, but can transmit any data such as pictures, audio, and video, all of which are due to its "flexible and scalable" characteristics.

Those RFC documents can actually be understood as the "recognition and standardization" of existing extensions, realizing the virtuous cycle of "from practice to practice".

It is precisely because of this feature that HTTP has been able to "stand firm" in the long history of thirty years, from the initial low-speed experimental network to the current high-speed Internet that spans the globe, and it has always maintained its vitality.

Reliable transmission

The second feature is that the HTTP protocol is a "reliable" transmission protocol.

This feature is obvious, because the HTTP protocol is based on TCP/IP, and TCP itself is a "reliable" transmission protocol, so HTTP naturally inherits this feature and can "reliably" transmit data between the requester and the responder.

Its specific approach is similar to TCP/UDP. It wraps the actual transmitted data (entity) with a layer of packaging, adds a header, and then calls the Socket API to send or receive through the TCP/IP protocol stack.

However, we must correctly understand the meaning of "reliable". HTTP cannot 100% guarantee that data can be sent to the other end. In bad environments such as busy networks and poor connection quality, sending and receiving may fail. "Reliable" only provides a "commitment" to users that the lower layer will "try to" ensure the complete delivery of data by various means.

Of course, if the optical fiber is accidentally cut, even a god cannot send the data successfully. Therefore, "reliable" transmission means that data transmission and reception will be successful when the network is basically normal. To borrow the terminology of operation and maintenance, it is probably "three nines" or "four nines".

Application layer protocols

The third characteristic is that the HTTP protocol is an application layer protocol.

This feature is also self-explanatory, but it is very important.

In the decades since the birth of TCP/IP, although many application layer protocols have emerged, they all focus on very small application areas and are limited to a few application scenarios. For example, FTP can only transfer files, SMTP can only send emails, and SSH can only log in remotely, etc. They are "completely incompetent" in terms of general data transmission.

Therefore, HTTP, with its message structure that can carry any header field and entity data, as well as its convenient and easy-to-use features such as connection control and cache proxy, has quickly become a "star" protocol in the application layer. As long as the performance is not too demanding, HTTP can transmit almost everything and meet various needs, and it can be called a "universal" protocol.

To paraphrase a popular joke on the Internet, HTTP can be said in a joking tone: "Don't get me wrong, I'm not targeting FTP, I'm saying that everyone at the application layer is garbage."

Request-Response

The fourth characteristic is that the HTTP protocol uses a request-response communication model.

This request-response mode is the most fundamental communication model of the HTTP protocol. Generally speaking, it is "send and receive" and "give and take". It is like a function call when writing code. As long as you fill in the fields in the request header, you will receive a reply after the "call".

The request-response model also clarifies the positions of the two communicating parties in the HTTP protocol. The requester always initiates the connection and request first, which is active, while the responder can only reply after receiving the request, which is passive. If there is no request, no action will be taken.

Of course, the roles of requester and responder are not absolute. In the browser-server scenario, the server is usually the responder, but if it is used as a proxy to connect to the back-end server, it may play the roles of requester and responder at the same time.

The HTTP request-response model also happens to fit the traditional C/S (Client/Server) system architecture, where the requester is the client and the responder is the server. Therefore, with the development of the Internet, the B/S (Browser/Server) architecture emerged, using lightweight browsers to replace bulky client applications, realizing zero-maintenance "thin" clients, while the server abandons private communication protocols and uses the HTTP protocol instead.

In addition, the request-response model is also fully consistent with the working mode of RPC (Remote Procedure Call), which can encapsulate HTTP request processing into remote function calls, leading to the emergence of WebService, RESTful and gPRC.

Stateless

The fifth characteristic is that the HTTP protocol is stateless. How should we understand this so-called "state"?

"State" is actually some data or flags saved in the client or server, which records some changes in the communication process.

You must know that the TCP protocol is stateful. It is in the CLOSED state at the beginning, the ESTABLISHED state after the connection is successful, the FIN-WAIT state after the connection is disconnected, and finally the CLOSED state.

These "states" require TCP to use some data structures internally to maintain them. You can simply imagine them as flags that mark the current state, such as 0 for CLOSED, 2 for ESTABLISHED, and so on.

Let's look at HTTP again. If we compare it with TCP, we can see that there is no "state" specified in the entire protocol. The client and server are always in a state of "ignorance". Before establishing a connection, the two are unaware of each other, and each message sent and received is independent of each other and has no connection. Sending and receiving messages will not have any impact on the client or server, and there is no requirement to save any information after the connection.

"Stateless" figuratively means "no memory ability". For example, a browser sends a request, saying "I am Xiao Ming, please give me file A." After receiving the message, the server will check the permissions to see that Xiao Ming can indeed access file A, so it sends the file back to the browser. Then the browser wants file B again, but the server does not record the status of the previous request, and does not know that the second request and the first request are sent by the same browser, so the browser must repeat its identity again: "I am Xiao Ming just now, please give me file B again."

We can compare it with the UDP protocol, but it is connectionless and stateless, sending packets in order and receiving packets out of order, and the data packets are not taken care of after they are sent, and they are not sorted in order after they are received. HTTP, on the other hand, is connectionless and stateless, sending packets in order and receiving packets in order, and managing messages in the order of sending and receiving.

But don't forget that HTTP is "flexible and extensible". Although the "state" is not specified in the standard, it is entirely possible to "patch" it within the framework of the protocol to add this feature.

Other Features

In addition to the above five features, the HTTP protocol can actually list many more features, such as cacheable and compressible entity data, segmented data acquisition, support for identity authentication, support for internationalized languages, etc. However, these cannot be considered the basic features of HTTP, because they are all derived from the first feature of "flexible and scalable".

summary

• HTTP is flexible and extensible, and any header field can be added to achieve any function;
• HTTP is a reliable transmission protocol, based on the TCP/IP protocol, which "try its best" to ensure data delivery;
• HTTP is an application layer protocol, which is more versatile than FTP, SSH, etc. and can transmit arbitrary data;
• TTP uses a request-response model, where the client actively initiates the request and the server passively responds to the request;
• HTTP is stateless in nature. Each request is independent and unrelated to each other. The protocol does not require the client or server to record information related to the request.

HTTP connection management

HTTP connection management is a very old topic. You must have heard of terms like "short connection" and "long connection". Let's clarify them today.

Short connection

The HTTP protocol was originally (0.9/1.0) a very simple protocol, and the communication process also adopted a simple "request-response" method.

Its underlying data transmission is based on TCP/IP. Before sending each request, it needs to establish a connection with the server, and the connection will be closed immediately after receiving the response message.

Because the entire connection process between the client and the server is very short and does not maintain a long-term connection with the server, it is called a "short-lived connection." The early HTTP protocol was also called a "connectionless" protocol.

The disadvantage of short connections is quite serious, because in the TCP protocol, establishing and closing connections are both very "expensive" operations. TCP establishes a connection through a "three-way handshake", sends three data packets, and requires one RTT; closing a connection requires a "four-way handshake", and four data packets require two RTTs.

A simple HTTP "request-response" usually only requires 4 packets, and if the internal processing time of the server is not counted, it is at most 2 RTTs. Calculated in this way, the wasted time is "3÷5=60%", that is, two-thirds of the time is wasted, and the transmission efficiency is surprisingly low.

From a purely theoretical perspective, the TCP protocol may be difficult for you to understand, so let me use a clock-in attendance machine as an analogy.

Suppose your company bought a time clock machine and placed it at the front desk. Because the machine is relatively expensive, a protective cover was specially made to cover it. The company requires that employees open the cover every time they clock in or out, and then close the cover after clocking in.

However, the lid is very sturdy and it takes a lot of effort to open and close it. It may only take 1 second to punch in, but it takes four or five seconds to open and close the lid. Most of the time is wasted on the meaningless operation of opening and closing the lid.

As you can imagine, it’s not too bad on normal days, but when it comes to getting off work, there will be long queues in front of the time clock machine, and everyone has to repeat the three steps of “open lid - punch in - close lid”. Tell me, isn’t that anxious?

In this metaphor, the time clock machine is equivalent to the server, the opening and closing of the lid is the connection and closing of TCP, and each person who punches the clock is an HTTP request. Obviously, the disadvantage of short connections seriously restricts the service capacity of the server, causing it to be unable to handle more requests.

Long Connection

In response to the shortcomings exposed by short connections, the HTTP protocol proposed a "long connection" communication method, also called "persistent connections", "keep alive" and "connection reuse".

In fact, the solution is very simple. It uses the idea of ​​"cost sharing". Since TCP connection and closing are very time-consuming, the time cost is shared from the original "request-response" to multiple "request-response".

Although this cannot improve the connection efficiency of TCP, based on the "denominator effect", the invalid time of each "request-response" will be reduced a lot, and the overall transmission efficiency will be improved.

Here I drew a comparison diagram of short connection and long connection.

In a short connection, HTTP "request-response" is sent three times, and 60% of the RTT time is wasted each time. In the case of a long connection, three requests are also sent, but because the connection is only established in the first time and closed in the last time, the waste rate is "3÷9≈33%", which reduces the time loss by almost half. Obviously, if more requests are sent on this long connection, the larger the denominator, the higher the utilization rate.

Continuing with the analogy of the time clock machine, the company also felt that this repeated operation of "opening the lid - punching in - closing the lid" was too "anti-human", so it issued a new rule that after opening the lid in the morning, there is no need to close it again, and employees can punch in freely and close the lid after get off work.

In this way, the efficiency of clocking in (i.e. service capability) has been greatly improved. It used to take five or six seconds to clock in once, but now it only takes one second. The long queues during rush hour and rush hour are gone, and everyone is happy.

Connection-related header fields

Since persistent connections can significantly improve performance, persistent connections are enabled by default in HTTP/1.1. No special header fields are required. Once the first request is sent to the server, subsequent requests will reuse the first opened TCP connection, i.e., persistent connection, to send and receive data.

Of course, we can also explicitly request the use of a long connection mechanism in the request header, using the Connection field and the value "keep-alive".

However, regardless of whether the client explicitly requests a persistent connection, if the server supports persistent connections, it will always put a "Connection: keep-alive" field in the response message to tell the client: "I support persistent connections, and I will use this TCP to send and receive data all the time."

However, long connections also have some minor drawbacks, and the problem lies in the word "long".

Because TCP connections are not closed for a long time, the server must save its state in memory, which occupies server resources. If there are a large number of idle long connections that are only connected but not sent, the server resources will be exhausted quickly, resulting in the server being unable to provide services to users who really need them.

Therefore, long connections also need to be closed at the appropriate time and cannot remain connected to the server forever. This can be done on both the client or the server.

On the client side, you can add the "Connection: close" field in the request header to tell the server: "Close the connection after this communication." When the server sees this field, it knows that the client wants to actively close the connection, so it also adds this field in the response message, and after sending it, it calls the Socket API to close the TCP connection.

The server usually does not actively close the connection, but some strategies can be used. Take Nginx as an example, it has two methods:

• Use the "keepalive_timeout" command to set the timeout period for long connections. If no data is sent or received on the connection for a period of time, the connection will be automatically disconnected to prevent idle connections from occupying system resources.
• Use the "keepalive_requests" directive to set the maximum number of requests that can be sent on a persistent connection. For example, if it is set to 1000, then when Nginx processes 1000 requests on this connection, it will actively disconnect.

In addition, both the client and the server can add a general header field "Keep-Alive: timeout=value" in the message to limit the timeout of the long connection. However, this field is not very binding, and the communicating parties may not comply with it, so it is not common.

Head of Line Blocking

After looking at short connections and long connections, let’s talk about the famous “head-of-line blocking” (also called “head-of-line blocking”).

"Head of line blocking" has nothing to do with short connections and long connections, but is caused by the basic "request-response" model of HTTP.

Because HTTP stipulates that messages must be "sent one after another", this forms a first-in-first-out "serial" queue. There is no priority for requests in the queue, only the order in which they enter the queue, and the request at the front is processed first.

If the request at the head of the queue is delayed because it is processed too slowly, then all the requests behind it in the queue will have to wait as well, resulting in other requests incurring unnecessary time costs.

Let’s use the time clock as an analogy.

At work time, everyone lined up to punch in, but the person at the front encountered a problem with the clock-in machine, and couldn't punch in successfully. He was so anxious that he was sweating. By the time someone fixed the clock-in machine, everyone in the queue behind him was late.

Performance Optimization

Because the "request-response" model cannot be changed, the "head-of-line blocking" problem cannot be solved in HTTP/1.1, but can only be alleviated. What can be done?

The company can buy a few more time clock machines and place them at the front desk so that everyone doesn't have to crowd into one line and can clock in separately. It doesn't matter if one line is occasionally congested, as they can switch to other uncongested lines.

This is called "concurrent connections" in HTTP, which means initiating multiple long connections to a domain name at the same time, using quantity to solve the problem of quality.

But this approach also has its flaws. If each client wants to be fast and establishes many connections, the number of users multiplied by the number of concurrent connections will be an astronomical number. The server's resources simply cannot handle it, or the server will think it is a malicious attack, which will cause "denial of service".

Therefore, the HTTP protocol recommends that clients use concurrency, but not "abuse" it. RFC2616 explicitly limits each client to a maximum of 2 concurrent connections. However, practice has proven that this number is too small, and many browsers "ignore" the standard and raise the upper limit to 6-8. The later revised RFC7230 also "followed the trend" and removed the "2" limit.

However, the performance squeezed out by "concurrent connections" cannot keep up with the endless demands of the rapidly developing Internet. Is there any other solution?

The company is growing too fast, with more and more employees, and clocking in and out has become a pressing problem. The front desk space is limited and there is no room for more clocking machines. What should we do? Then we can open more clocking places, and put three or four clocking machines at the entrance of each floor and office area to further divert people and prevent them from crowding at the front desk.

This is the "domain sharding" technology, which is still the idea of ​​using quantity to solve quality.

Don't HTTP protocols and browsers limit the number of concurrent connections? Well, I'll open a few more domain names, such as shard1.chrono.com, shard2.chrono.com, and these domain names all point to the same server www.chrono.com, so the number of actual long connections will go up again, which is really "sweet". However, it really feels like "there are policies from above and countermeasures from below".

summary

In this lecture, we learned about short connections and long connections in the HTTP protocol. Let's briefly summarize today's content:

• The early HTTP protocol used short connections and closed the connection immediately after receiving the response, which was very inefficient;
• HTTP/1.1 enables persistent connections by default, sending and receiving multiple requests and responses on one connection, which improves transmission efficiency;
• The server will send the "Connection: keep-alive" field to indicate that a persistent connection is enabled;
• If there is "Connection: close" in the message header, it means that the persistent connection is about to be closed;
• Too many persistent connections will occupy server resources, so the server will use some strategies to selectively close persistent connections;
• The "head of line blocking" problem will cause performance degradation, which can be alleviated by using "concurrent connections" and "domain name sharding" technologies.