"Summary" TCP Keepalive and HTTP Keepalive detailed

TCP Keepalive

The origin of TCP keepalive
The two sides establish an interactive connection, but there is not always data interaction, some connections will be released after the data interaction, and some will not, then in a long period of time without data interaction,
Both sides of the interaction are likely to have a power-down, freezing, abnormal restart and other accidents, when these accidents occur, these TCP connections are not in time for normal release, then the other side of the connection does not know the situation on the end,
It will maintain this connection, long-time accumulation will lead to a lot of semi-open connections, resulting in the consumption and waste of the end system resources, in order to solve this problem, the transport layer can be used by the TCP keepalive message to achieve.

The role of TCP keepalive presence

1. Detect if the end of the connection is alive
During application interaction, there are several possible scenarios:
(1) The client or server unexpectedly loses power, freezes, crashes, restarts.
(2) The intermediary network has been interrupted, and the client and server are unaware.

By using the KeepAlive detection function, you can detect the unexpected behavior of this pair of ends, thus ensuring that a semi-open TCP connection can be released in the event of an accident.

2. Prevent intermediate devices from removing connection tables associated with timeouts
Intermediate devices, such as firewalls, will establish a connection information table for passing its data messages, and set a timer for the time-out period, if a connection has no message interaction if it exceeds the scheduled time.
The intermediary device will remove the connection information from the table, after deletion, when there is an application message, the intermediary device will discard the message, resulting in an application exception, the process of interaction is as follows:

　　　　　　　　　　　　

This situation is very common in applications with firewalls, which can have a significant impact on some applications that have long time without data interaction but have long time to maintain connectivity, such as databases, to solve this problem,
The application itself or TCP can maintain the information of the connection in the intermediary device via a keepalive message (or it can be resolved by turning on the long connection attribute on the intermediate device or by the time of the connection table being released.
However, this effect may be larger, and there is a chance to do a detailed description of this, not to mention it here.

Common Application Failure Scenarios:

A financial application, in the client needs to fill in a large number of form data, after the client and the server to establish a TCP connection, the client terminal users will spend a few minutes or even dozens of minutes to fill out the form-related information,
After the end user has finally filled out the required information for the form, click on the "Submit" button, and the result is that the intermediate device has already removed the TCP connection from the connection table.
It will directly discard this message or send the RST message to the client, the application failure, which will cause the client end user all the work will need to re-visit, to the user to bring great inconvenience and loss.

TCP KeepAlive Message interaction process

　　　　　　　　　　　　

Potential problems with TCP keepalive
1. Intermediate equipment due to a large number of keepalive connections, resulting in its connection table full
Gateway device due to keepalive problem, resulting in its connection table full, unable to create a new connection (XX Office gateway failure case) or severe performance degradation
2. Normal connection is released
When a link is sent to a keepalive probe, the intermediary network is unable to properly forward the keepalive probe to the opposite end due to various anomalies (such as link interruption, intermediate device restart, etc.).
may lead to the detection of the party to release the normal connection, but the probability of this possibility is small, in addition, it is generally possible to increase the number of keepalive detection packets to reduce the probability and impact of the occurrence of this situation.

HTTP Keepalive

HTTPD daemon, generally provides keep-alive timeout time setting parameters. Like Nginx's keepalive_timeout, and Apache's keepalivetimeout.
This keepalive_timout time value means that an HTTP-generated TCP connection will need to hold keepalive_timeout seconds after the last response has been delivered before the connection is closed.
When the httpd daemon sends a response, it should actively close the corresponding TCP connection immediately, after setting up keepalive_timeout, the httpd daemon would like to say: "Wait, see if the browser has asked to come over",
This is keepalive_timeout time. If the daemon has not received an HTTP request from the browser during this waiting time, the HTTP connection is closed.
1. In the absence of a keepalive_timeout setting, the time required for a socket resource to go from establishment to real release is: Establish TCP connection + transmit HTTP request + PHP script execute + transmit HTTP response + Close TCP connection
2. Set the keepalive_timout time situation, a socket set up to release the time required is more than keepalive_timeout time.

HTTP keep-alive with TCP keep-alive
HTTP keep-alive with TCP keep-alive, not the same thing, the intention is not the same. The HTTP keep-alive is intended to allow TCP to live longer to transmit multiple HTTP on the same connection,
Improve the efficiency of your sockets. TCP Keep-alive is a fresh-keeping mechanism for TCP to detect TCP connection condition. 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/TCP_KEEPALIVE_INTVL
Echo 5 >/proc/sys/net/ipv4/tcp_keepalive_probes
KeepAlive is a TCP freshness timer, when the network on both ends of the establishment of a TCP connection, idle (no data flow between the two sides sent) after the Tcp_keepalive_time
The server kernel attempts to send a reconnaissance packet to the client to determine the status of the TCP connection (it is possible that the client crashes, the application is forcibly closed, the host is unreachable, and so on). If you do not receive an answer (ACK packet),
Will try to send the detection packet again after TCP_KEEPALIVE_INTVL, until received the ACK to the other side, if you have not received the other side's ACK, will try to tcp_keepalive_probes a time,
Each time interval is 15s, 30s, 45s, 60s, 75s, respectively. If you try to tcp_keepalive_probes and you still do not receive an ACK packet from the other, the TCP connection is discarded.
The default idle time for TCP connections is 2 hours and is generally set to 30 minutes enough. In other words, only if the keepalive_timeout value of Nginx is set above Tcp_keepalive_time,
and the last HTTP response transmitted from this TCP connection, after Tcp_keepalive_time time, the operating system sends a reconnaissance packet to decide whether to discard the TCP connection.
This is generally not 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 connection is actively closed by the server-side httpd daemon). The rationale is simple, in contrast, to enable keep-alive,
Fewer TCP connections are made, and the TCP connections that naturally need to be shut down are correspondingly less.

"Summary" TCP Keepalive and HTTP Keepalive detailed