Detailed keepalive related configuration of HTTP in Nginx _nginx

HTTP keepalive
in the early days of HTTP, each HTTP request required a TPC socket connection to be opened, and the TCP connection was disconnected once it was used. Using keep-alive can improve this state of being able to send multiple copies of data in a single TCP connection without disconnecting. By using the keep-alive mechanism, you can reduce the number of TCP connections that can be established, or reduce the TIME_WAIT state connection to improve performance and increase the throughput of HTTPD servers (fewer TCP connections mean less system kernel calls, and socket accept ( ) and close () calls. However, Keep-alive is not a free lunch, and long TCP connections can easily lead to invalid system resources. Improperly configured keep-alive are sometimes more costly than reusing connections. Therefore, it is very important to set Keep-alive timeout time correctly.
Keepalvie Timeout
The httpd daemon generally provides 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 that is generated by an HTTP will have to hold keepalive_timeout seconds after the last response is sent to start closing the connection. When the httpd daemon sends out a response, should immediately turn off the corresponding TCP connection, set Keepalive_timeout, httpd daemon will want to say: "Wait a minute, see if the browser has asked to come over", this is the Keepalive_ Timeout time. This HTTP connection is turned off if the daemon has not received a browse HTTP request for this waiting time.
I wrote a script to facilitate testing

<?php Sleep
(60);//To facilitate analytical testing, the
echo "Www.jb51.net" is adjusted according to the test;
? >

1. When the keepalive_timeout time is 0 o'clock, that is, when the keep-alive is not enabled, the lifecycle of a TCP connection

#tcpdump-N Host 218.1.57.236 and port 80

 20:36:50.792731 IP 218.1.57.236.43052 > 222.73.211.215.http:s 1520902589:1520902589 (0) win 65535 20:36:50.792798 IP 222.73.211.215.http > 218.1.57.236.43052:s 290378256:290378256 (0) Ack 1520902590 win 5840 20:36:50.801629 IP 218.1.57.236.43052 > 222.73.211.215.http:. Ack 1 win 3276820:36:50.801838 IP 218.1.57.236.43052 > 222.73.211.215.http:p 1:797 (796) Ack 1 win 32768 20:36:50.80184 3 IP 222.73.211.215.http > 218.1.57.236.43052:. Ack 797 win 5920:37:50.803230 IP 222.73.211.215.http > 218.1.57.236.43052:p 1:287 (286) Ack 797 win 59 20:37:50.803289 IP 222.73.211.215.http > 218.1.57.236.43052:f 287:287 (0) Ack 797 win 20:37:50.893396 IP 218.1.57.236.43052 > 222 .73.211.215.http:. Ack-win 32625 20:37:50.894249 IP 218.1.57.236.43052 > 222.73.211.215.http:f 797:797 (0) ACK win 32625 20:37:50. 894252 IP 222.73.211.215.http > 218.1.57.236.43052:. Ack 798 win 

The 1th to 3rd line establishes TCP three times handshake and establishes the connection. Spents 8898μs
Line 4th to 5th sends the first HTTP request through the established connection, and the server confirms receipt of the request. Spents 5μs
Line 5th to 6th, you can know that when the script executes 60s1387μs, it matches the PHP script.
6th, 8 line server to send HTTP response. 90166μs when sending a response.
Line 7th indicates that the server-side daemon actively shuts down the connection. Combine lines 6th and 8 to indicate that once the HTTP response has been sent, the server closes the TCP connection immediately.
7th, 9, 10 indicates that the TCP connection order is off, when 90963μs. Note that the socket resource is not released immediately, and it needs to wait 2MSL time (60s) before it is truly released.
Thus, in the absence of keepalive_timeout settings, a socket resource from the establishment to the real release of the elapsed time is: Establish a TCP connection + transfer HTTP request + PHP script Execution + transmit HTTP response + Close TCP connection + 2MSL. (Note: The time here can only do the reference, the specific time mainly by the network bandwidth, and the response size depends)
2. When the keepalive_timeout time is greater than 0 o'clock, that is, when the keep-alive is enabled, the lifecycle of a TCP connection. To facilitate analysis, we set the keepalive_timeout to 300s

#tcpdump-N Host 218.1.57.236 and port 80

21:38:05.471129 IP 218.1.57.236.54049 > 222.73.211.215.http:s 1669618600:1669618600 (0) win 65535 21:38:05.471140 IP 2 22.73.211.215.http > 218.1.57.236.54049:s 4166993862:4166993862 (0) Ack 1669618601 win 5840 21:38:05.481731 IP 218.1.5 7.236.54049 > 222.73.211.215.http:. Ack 1 win 32768 21:38:05.481976 IP 218.1.57.236.54049 > 222.73.211.215.http:p 1:797 (796) Ack 1 win 32768 21:38:05.4819 IP 222.73.211.215.http > 218.1.57.236.54049:.  Ack 797 win 21:38:07.483626 IP 222.73.211.215.http > 218.1.57.236.54049:p 1:326 (325) Ack 797 win 59 21:38:07.747614 IP 218.1.57.236.54049 > 222.73.211.215.http:. ACK 326 win 32605 21:43:07.448454 IP 222.73.211.215.http > 218.1.57.236.54049:f 326:326 (0) Ack 797 win 59 21:43:07.560 316 IP 218.1.57.236.54049 > 222.73.211.215.http:. ACK 327 win 32605 21:43:11.759102 IP 218.1.57.236.54049 > 222.73.211.215.http:f 797:797 (0) Ack 327 win 32605 21:43:11. 759111 IP 222.73.211.215.http > 218.1.57.236.54049:. Ack 798 win 59
 

Let's take a look at line 6th to 8th, unlike the last example, when the server-side httpd Daemon has completed its response, it does not immediately turn off the TCP connection.
Line 8th, combined with line 6th, we can see that after 5 minutes (300s), the server actively shuts down this TCP connection. This time is exactly the keepalive_timeout time we set.
Thus, set the keepalive_timout time, a socket set up to release the time it takes 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. For ease of analysis, we set the keepalive_timeout to 180s
With this test, we want to figure out whether the keepalive_timeout is timed from the end of the first response or the end of the last response. The test results proved to be the latter, where we made a request every 120s and sent 3 requests over a TCP connection.

# Tcpdump-n Host 218.1.57.236 and Port 80

22:43:57.102448 IP 218.1.57.236.49955 > 222.73.211.215.http:s 4009392741:4009392741 (0) win 65535 22:43:57.102527 IP 2 22.73.211.215.http > 218.1.57.236.49955:s 4036426778:4036426778 (0) Ack 4009392742 win 5840 22:43:57.111337 IP 218.1.5 7.236.49955 > 222.73.211.215.http:. Ack 1 win 3276822:43:57.111522 IP 218.1.57.236.49955 > 222.73.211.215.http:p 1:797 (796) Ack 1 win 32768 22:43:57.11153 0 IP 222.73.211.215.http > 218.1.57.236.49955:.  Ack 797 win 22:43:59.114663 IP 222.73.211.215.http > 218.1.57.236.49955:p 1:326 (325) Ack 797 win 59 22:43:59.350143 IP 218.1.57.236.49955 > 222.73.211.215.http:. ACK 326 win 3260522:45:59.226102 IP 218.1.57.236.49955 > 222.73.211.215.http:p 1593:2389 (796) ACK 650 win 32443 22:45: 59.226109 IP 222.73.211.215.http > 218.1.57.236.49955:. Ack 2389 win 22:46:01.227187 IP 222.73.211.215.http > 218.1.57.236.49955:p 650:974 (324) Ack 2389 win 83 22:46:01.45 0364 IP 218.1.57.236.49955 > 222.73.211.215.http:. ACK 974 win 3228122:47:57.377707 IP 218.1.57.236.49955 > 222.73.211.215.http:p 3185:3981 (796) Ack 1298 win 32119 22:47:57.377714 IP 222.73.211.215.http > 218.1.57.236.49955:. Ack 3981 win 108 22:47:59.379496 IP 222.73.211.215.http > 218.1.57.236.49955:p 1298:1622 (324) Ack 3981 win 108 22:47:5 9.628964 IP 218.1.57.236.49955 > 222.73.211.215.http:. Ack 1622 win 3276822:50:59.358537 IP 222.73.211.215.http > 218.1.57.236.49955:f 1622:1622 (0) Ack 3981 win 108 22:50:59 .367911 IP 218.1.57.236.49955 > 222.73.211.215.http:. ACK 1623 win 32768 22:50:59.686527 IP 218.1.57.236.49955 > 222.73.211.215.http:f 3981:3981 (0) ACK 1623 win 32768 22:50 : 59.686531 IP 222.73.211.215.http > 218.1.57.236.49955:.
 Ack 3982 win 108

First group, three IP packets represent TCP three handshake to establish a connection, which is established by the browser.
The second group, which sends the first HTTP request and gets the response, and does not immediately turn off the TCP connection when the server daemon outputs the response. Instead, start the keepalive_timout timer.
The third group, 2 minutes later, sends a second HTTP request and gets a response, and the same server daemon does not immediately turn off the TCP connection and restart Keepalive_timout timing.
Group fourth, 2 minutes later, sent a third HTTP request and received a response. The server daemon still did not actively shut down the TCP connection (4 minutes from the first HTTP response, greater than the Keepalive_timeout value), but restarted the keepalive_timout timing.
Group fifth, with the last response Keepalive_timeout (180s), the daemon is no longer receiving requests. The timer ends and the server daemon actively shuts down the connection. 4 times after the wave, the service end into the TIME_WAIT state.
This indicates that when the keepalive_timeout is set, a socket is set up to release, which takes time: TCP establishes + (last response time – First request time) + TCP shutdown + 2MSL. Red Bold indicates the time each request was sent, the execution time of each request script, the time each response was sent, and the time interval of 22 requests. Further testing, a TCP connection that is shutting down or time_wait state, cannot transmit HTTP requests and responses. That is, when a connection ends Keepalive_timeout timing, the server daemon sends the first FIN flag IP packet, and the connection is no longer available. The
http keep-alive and TCP keep-alive
http keep-alive are not the same thing as TCP keep-alive and are not intended to be the same. The HTTP keep-alive is designed to allow TCP to live longer to send multiple HTTP on the same connection, increasing the efficiency of the socket. TCP Keep-alive is a kind of TCP-preserving mechanism to detect TCP connection. TCP keep-alive freshness Timer, supports three system kernel configuration parameters:

 echo 1800 >/proc/sys/net/ipv4/tcp_keepalive_time echo >/proc/sys/net/ipv4/t CP_KEEPALIVE_INTVL echo 5 >/proc/sys/net/ipv4/tcp_keepalive_probes 

KeepAlive is a TCP fresh-keeping timer, when the network at both ends of the TCP connection, the idle idle (the two sides do not have any data stream to send traffic) after the tcp_keepalive_time, the server kernel will try to send a detection packet to the client to determine the TCP connection status ( It is possible that client crashes, forced shutdown of applications, host unreachable, and so on. If you do not receive the answer (ACK package), you will try to send the detection packet after TCP_KEEPALIVE_INTVL, until you receive an ACK on the other side, if you have not received the other's ACK, will try Tcp_keepalive_probes times, The time interval is 15s, 30s, 45s, 60s, 75s, respectively. If you try to tcp_keepalive_probes and still do not receive an ACK packet from the other side, the TCP connection is discarded. The default idle time for TCP connections is 2 hours, which is generally set to 30 minutes enough. That is, only if the keepalive_timeout value of Nginx is set higher than tcp_keepalive_time and the last HTTP response that is transmitted from this TCP connection, after a tcp_keepalive_time time, The operating system sends a reconnaissance packet to decide whether to discard the TCP connection. This is not usually the case unless you need to do so.
Keep-alive and Time_wait
with HTTP Keep-alvie, you can reduce the number of server time_wait (because the server-side httpd daemon actively shuts down the connection). The reason is simple, in contrast, enabling keep-alive, the establishment of fewer TCP connections, natural to be shut down the TCP connection is less.
At last
I want to use a schematic to illustrate the difference between using enabled keepalive. In addition, the HTTP keepalive is the result of collaboration between the client browser and the server-side httpd daemon, so we are arranging additional space to introduce the various scenarios of different browsers on the use of keepalive.