Shulou(Shulou.com)05/31 Report--

This article mainly introduces "how to configure the keepalive of HTTP in Nginx". In the daily operation, I believe that many people have doubts about how to configure the keepalive of HTTP in Nginx. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts of "how to configure the keepalive of HTTP in Nginx". Next, please follow the editor to study!

Http keepalive

In the early days of http, every http request required an tpc socket connection to be opened, and the tcp connection was disconnected after using it once. Using keep-alive can improve this state, that is, multiple data can be sent continuously in a single tcp connection without being disconnected. By using the keep-alive mechanism, you can reduce the number of tcp connections established, which also means that you can reduce the number of time_wait stateful connections, thereby improving performance and throughput of the httpd server (fewer tcp connections mean fewer kernel calls, accept () and close () calls to socket). However, keep-alive is not a free lunch, and long tcp connections can easily lead to invalid use of system resources. Improperly configured keep-alive can sometimes be more costly than reusing connections. Therefore, it is important to set the keep-alive timeout time correctly.

Keepalvie timeout

Httpd daemons generally provide keep-alive timeout time setting parameters. Such as nginx's keepalive_timeout and apache's keepalivetimeout. This keepalive_timout time value means that a tcp connection generated by http needs to be keepalive_timeout-resided by hold for a second before it begins to close the connection after sending the last response. When the httpd daemon sends a response, it should immediately take the initiative to close the corresponding tcp connection. After setting the keepalive_timeout, the httpd daemon will want to say, "wait a minute and see if the browser has requested it." this is keepalive_timeout time. If the daemon does not receive a browsing http request during this waiting time, it closes the http connection.

I wrote a script to make it easy to test

1. When the keepalive_timeout time is 0, that is, when keep-alive is not enabled, the life cycle of an tcp connection

# tcpdump-n host 218.1.57.236 and port 8020 and port 36 ip 50.792731 ip 218.1.57.236.43052 > 222.73.211.215.http: s 1520902589 (0) win 6553520 222.73.211.215.http 36V 50.792798 ip 222.73.211.215.http > 218.1.57.236.43052: s 290378256 ip 290378256 (0) ack 1520902590 win 584020 36 ip 50.801629 ip 218.1.57.236.43052 > 222.73.211.215.http:. Ack 1 win 3276820 ack 36 ack 50.801838 ip 218.1.57.236.43052 > 222.73.211.215.http: P 1V 797 (796) ack 1 win 3276820 ack 36V 50.801843 ip 222.73.211.215.http > 218.1.57.236.43052:. Ack 797 win 5920 win 37 ack 50.803230 ip 222.73.211.215.http > 218.1.57.236.43052: P 1Visu287 (286) ack 797 5920 win 5920 ack 50.803289 ip 222.73.211.215.http > 218.1.57.236.43052: F 287lv 287 (0) ack 797 win 5920 Ju 3715 50.893396 ip 218.1.57.236.43052 > 222.73.211.215.http:. Ack 288 win 3262520 ip 37 222.73.211.215.http 50.894249 ip 218.1.57.236.43052 > 222.73.211.215.http: F 797Vera 797 (0) ack 288 win 3262520 Vol 37 Vera 50.894252 ip 222.73.211.215.http > 218.1.57.236.43052:. Ack 798 win 59

Lines 1-3 establish the tcp three-way handshake and establish the connection. Time: 8898 μ s

Lines 4-5 send the first http request over the established connection, and the server acknowledges receipt of the request. It takes 5 μ s

From lines 5 to 6, you can see that the script takes 60s1387 μ s to execute, which is consistent with the php script.

Lines 6 and 8 send the http response from the server. It takes 90166 μ s to send the response.

Line 7 indicates that the server daemon actively closes the connection. Combined with lines 6 and 8, the server closes the http connection as soon as the tcp response is sent.

7, 9, 10 indicate that the tcp connection sequence is closed, using 90963 μ s. It should be noted that the socket resource is not immediately released here, and you need to wait for the 2msl time (60s) before it is actually released.

Thus, in the case of no keepalive_timeout, the time it takes for a socket resource from establishment to real release is: establishing a tcp connection + sending a http request + php script execution + transmitting a http response + closing a tcp connection + 2msl. (note: the time here can only be used as a reference, and the specific time is mainly determined by the network bandwidth and the response size.)

two。 When the keepalive_timeout time is greater than 0, that is, when keep-alive is enabled, the life cycle of an tcp connection. For ease of analysis, we set the keepalive_timeout to 300s

# tcpdump-n host 218.1.57.236 and port 8021 and port 8021 ip 05.471129 ip 218.1.57.236.54049 > 222.73.211.215.http: s 1669618600 ip 1669618600 (0) win 655352138 ip 222.73.211.215.http > 218.1.57.236.54049: s 4166993862 (0) ack 1669618601 win 584021 38 05.481731 ip 218.1.57.236.54049 > 222.73.211.215.http. Ack 1 win 3276821 ack 38 ack 05.481976 ip 218.1.57.236.54049 > 222.73.211.215.http: P 1V 797 (796) ack 1 win 3276821 ack 3848 1985 ip 222.73.211.215.http > 218.1.57.236.54049:. Ack 797 win 5921 win 38 ip 222.73.211.215.http 07.483626 ip 222.73.211.215.http > 218.1.57.236.54049: P 1V 326 (325) win 5921 win 5921 38 ip 222.73.211.215.http 07.747614 ip 218.1.57.236.54049 > 222.73.211.215.http:. Ack 326 win 3260521 win 43 ip 222.73.211.215.http 07.448454 ip 222.73.211.215.http > 218.1.57.236.54049: F 326 ack 797 win 5921 Vista 4321 ip 218.1.57.236.54049 > 222.73.211.215.http:. Ack 327 win 3260521 ip 43 222.73.211.215.http 11.759102 ip 218.1.57.236.54049 > 222.73.211.215.http: F 797 ack 327 win 3260521 Ack 798 win 59

Let's take a look at lines 6-8. Unlike the last example, the server-side httpd daemon did not actively close the tcp connection immediately after it sent a response.

Line 8, combined with line 6, we can see that after 5 minutes (300s), the server actively closes the tcp connection. This time is exactly the time we set for keepalive_timeout.

Thus it can be seen that when the keepalive_timout time is set, the time required for a socket to be established and released is more keepalive_timeout time.

3. When the keepalive_timeout time is greater than 0 and multiple http responses are sent on the same tcp connection. Here, for ease of analysis, we set keepalive_timeout to 180s.

Through this test, we want to know whether keepalive_timeout starts timing from the end of the first response or from the end of the last response. The test results confirm the latter. Here, we send requests every 120s and send three requests over a tcp connection.

# tcpdump-n host 218.1.57.236 and port 8022 and port 43tcpdump 57.102448 ip 218.1.57.236.49955 > 222.73.211.215.http: s 4009392741 (0) win 6553522 43tcpdump 57.102527 ip 222.73.211.215.http > 218.1.57.236.49955: s 4036426778 4036426778 (0) ack 4009392742 win 58402243 57.111337 ip 218.1.57.236.49955 > 222.73.211.215.http. Ack 1 win 3276822 ip 43 ack 57.111522 ip 218.1.57.236.49955 > 222.73.211.215.http: P 1lav 797 (796) ack 1 win 3276822 ack 43v 57.111530 ip 222.73.211.215.http > 218.1.57.236.49955 Ack 797 win 5922 ip 222.73.211.215.http > 218.1.57.236.49955: P 1VO326 (325) ack 797 win 5922 PLO 43 ip 222.73.211.215.http 59.350143 ip 218.1.57.236.49955 > 222.73.211.215.http:. Ack 326 win 3260522 ip 49.226102 ip 218.1.57.236.49955 > 222.73.211.215.http: P 1593 ack 2389 (796) ack 650 win 3244322 ip 222.73.211.215.http > 218.1.57.236.49955:. Ack 2389 win 8322 ip 222.73.211.215.http > 218.1.57.236.49955: P 650 ack 2389 win 8322 ip 41.427187 ip 218.1.57.236.49955 > 222.73.211.215.http:. Ack 974 win 3228122 ip 57.377707 ip 218.1.57.236.49955 > 222.73.211.215.http: P 3185ip 3981 (796) ack 1298 win 3211922 win 377714 ip 222.73.211.215.http > 218.1.57.236.49955 Ack 3981 win 10822 ip 222.73.211.215.http 47 ip 222.73.211.215.http > 218.1.57.236.49955: P 1298 ack 3981 win 10822 ip 222.73.211.215.http 47 ack 59.628964 ip 218.1.57.236.49955 > 222.73.211.215.http:. Ack 1622 win 3276822 ack 50 ack 59.358537 ip 222.73.211.215.http > 218.1.57.236.49955: f 1622mm 1622 (0) win 10822 ack 50V 59.367911 ip 218.1.57.236.49955 > 222.73.211.215.http:. Ack 1623 win 3276822 ip 59.686527 ip 218.1.57.236.49955 > 222.73.211.215.http: f 3981 ack 1623 win 3276822 222.73.211.215.http 59.686531 ip 222.73.211.215.http > 218.1.57.236.49955:. Ack 3982 win 108

In the first group, three ip packets represent the tcp three-way handshake to establish a connection, which is established by the browser.

In the second group, after the first http request is sent and the response is received, the server daemon does not actively close the tcp connection immediately after outputting the response. Instead, start the keepalive_timout timing.

The third group, 2 minutes later, sends the second http request and gets a response. Similarly, the server daemon does not immediately actively close the tcp connection and restart keepalive_timout timing.

The fourth group, two minutes later, sent the third http request and got a response. The server daemon still does not actively close the tcp connection (4 minutes since the first http response, which is greater than the keepalive_ timeout value), but restarts the keepalive_timout timing.

In the fifth group, along with the last response keepalive_timeout (180s), the daemon received no more requests. The timing ends and the server daemon actively closes the connection. After 4 waves, the server enters the time_wait state.

This shows that when keepalive_timeout is set, the time required for a socket to be set up to release is: tcp establishment + (last response time-first request time) + tcp shutdown + 2msl. Bold in red indicates the time of each request, the execution time of each request script, the time of each response, and the interval between requests. Further testing shows that tcp connections that are being closed or in the time_wait state cannot transmit http requests and responses. That is, when a connection ends keepalive_timeout timing and the server daemon sends the first fin flag ip packet, the connection can no longer be used.

Http keep-alive and tcp keep-alive

Http keep-alive and tcp keep-alive are not the same thing and have different intentions. The purpose of http keep-alive is to make tcp live longer so that it can transmit multiple http on the same connection and improve the efficiency of socket. Tcp keep-alive is a fresh-keeping mechanism of tcp to detect the connection status of tcp. Tcp keep-alive fresh-keeping timer supports three system kernel configuration parameters:

Echo 1800 > / proc/sys/net/ipv4/tcp_keepalive_timeecho 15 > / proc/sys/net/ipv4/tcp_keepalive_intvlecho 5 > / proc/sys/net/ipv4/tcp_keepalive_probes

Keepalive is a tcp freshness timer. When a tcp connection is established at both ends of the network, and the idle idle (there is no data flow between the two sides to send each other) tcp_keepalive_time, the server kernel will try to send detection packets to the client to determine the tcp connection status (it is possible that the client crashes, the application is forcibly closed, the host is unreachable, and so on). If you do not receive the other party's answer (ack packet), you will try to send the detection packet again after tcp_keepalive_intvl until you receive the ack to the other party. If you have not received the other party's ack, you will try tcp_keepalive_probes for a total of 15 s, 30 s, 45 s, 60s, 75 s respectively. If you try tcp_keepalive_probes and still do not receive the other party's ack packet, the tcp connection will be discarded. The default idle time for tcp connections is 2 hours, which is generally set to 30 minutes. That is, only when the keepalive_ timeout value of nginx is set higher than tcp_keepalive_time, and the last http response transmitted by this tcp connection elapses tcp_keepalive_time time, the operating system will send a detection packet to decide whether to discard the tcp connection. This doesn't usually happen unless you need to.

Keep-alive and time_wait

With http keep-alvie, you can reduce the number of server-side time_wait (because the server-side httpd daemon actively closes the connection). The reason is simple: compared to enabling keep-alive, fewer tcp connections are established and fewer tcp connections are naturally closed.

At this point, the study on "how to configure the keepalive of HTTP in Nginx" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.