1) Overview: performance and short link, long link
1) Long connections can minimize the number of tcp handshake and wave hands, thereby improving performance.
2) The short link performs a tcp handshake and wave for each http request, resulting in a large performance loss.
2) Short link
The HTTP (0.9/1.0) protocol is a very simple protocol, and the communication process uses a simple "request-response" method.
Its underlying data transmission is based on TCP/IP. It needs to establish a connection with the server before each request is sent, and the client will [close the tcp connection immediately] after receiving the response message. The entire connection process between the client and the server is very short, so it is called "shortlived connections". The shortcomings of short connections are quite serious, because in the TCP protocol, establishing a connection and closing a connection are both very "expensive" operations.
3) Long connection (HTTP/1.1 enables long connection by default)
The HTTP 1.1 protocol proposes a "persistent connection" communication method, also called "persistent connections", "keep alive", and "connection reuse". In terms of thinking, the idea of "cost sharing" is used. Since TCP connection and closing is very time-consuming, then the time cost is divided from the original "http request-http response" to multiple "http request-http response" "on. Although the connection efficiency of TCP cannot be improved, the invalid time of each "http request-http response" will be reduced a lot, and the overall efficiency will be improved. The effect of long connection is shown in the figure below:
4) Small disadvantages of long connections (so long connections also need to be closed [at the right time])
Because the TCP connection is not closed for a long time, the server must save the connection status in the memory, which actually occupies the server's resources. If there are a large number of idle long connections that are not sent, it will quickly exhaust the server's resources.
Therefore, long connections need to be closed [at the right time]. Close the long connection, which can be done on the client or the server.
On the client side, you can add the "Connection: close" field to the request header to tell the server: "Close the tcp connection after this communication is complete." When the server sees this field, it knows that the client wants to actively close the connection, so it adds this "Connection: close" field to the response message, and after the response is sent, it calls the Socket API to close the TCP connection.
The server usually does not actively close the tcp connection, but has some strategies for closing long connections. Take Nginx as an example. There are two ways:
- Use the "keepalive_timeout" command to set the timeout period for a long connection. If there is no data flow on the tcp connection for a period of time, the tcp connection will be actively disconnected, so as to avoid idle tcp connections occupying server resources.
- Use the "keepalive_requests" command to set the maximum number of http requests that can be sent on a long connection. For example, if it is set to N, then when Nginx processes N requests on this connection, it will also actively disconnect the long connection.
5) Connection related header fields
The connection in HTTP/1.1 will enable persistent connection by default. The client does not need to specify the header field. As long as the first request is sent to the server, subsequent http requests will reuse the first opened TCP connection until the TCP connection is closed. Of course, the persistent connection mechanism can also be explicitly required in the request header, and the header field used is Connection: "keep-alive". However, regardless of whether the client explicitly requires persistent connections, if the server supports persistent connections, it will always put a Connection: "keep-alive" header field in the response message to tell the client: "My server supports persistent connections. The next http request reuses this TCP connection."