TCP Keepalive(1)
Introduction
Under some circumstances, it is useful for a client or server to become aware of the termination or loss of connection with its peer.
In other circumstances, it is desirable to keep a minimal amount of data flowing over a connection, even if the applications do not have any to exchange.
TCP keepalive provides a capability use- ful for both cases.
Keepalive is a method for TCP to probe its peer without affect- ing the content of the data stream.
It is driven by a keepalive timer.
When the timer fires, a keepalive probe (keepalive for short) is sent, and the peer receiving the probe responds with an ACK.
Keepalives are not part of the TCP specification.
The Host Requirements RFC [RFC1122] says that this is because they could
(1) cause perfectly good con- nections to break during transient Internet failures,
(2) consume unnecessary bandwidth, and
(3) cost money for an Internet path that charges for packets. Nev- ertheless, most implementations provide the keepalive capability.
For example, if the keepalive probes are sent during the time that an intermediate router has crashed and is rebooting, TCP incorrectly thinks its peer host has crashed.
Description
Anytime it is operating, a TCP using keepalives may find its peer in one of four states:
-
The peer host is still up and running and reachable. The peer’s TCP responds normally and the requestor knows that the other end is still up. The requestor’s TCP resets the keepalive timer for later (equal to the value of the keepalive time). If there is application traffic across the connection before the next timer expires, the timer is reset back to the value of keepalive time.
-
The peer’s host has crashed and is either down or in the process of reboot- ing. In either case, its TCP is not responding. The requestor does not receive a response to its probe, and it times out after a time specified by the keepalive interval. The requestor sends a total of keepalive probes of these probes, kee- palive interval time apart, and if it does not receive a response, the requestor considers the peer’s host as down and terminates the connection.
-
The client’s host has crashed and rebooted.In this case,the server receives a response to its keepalive probe, but the response is a reset segment, causing the requestor to terminate the connection.
-
The peer’s host is up and running but is unreachable from the requestor for some reason (e.g., the network cannot deliver traffic and may or may not inform the peers of this fact using ICMP). This is effectively the same as state 2, because TCP cannot distinguish between the two. All TCP can tell is that no replies are received to its probes.
The requestor does not have to worry about the peer’s host being shut down gracefully and then rebooting (as opposed to crashing).
When the system is shut down by an operator, all application processes are terminated (i.e., the peer’s pro- cess), which causes the peer’s TCP to send a FIN on the connection.
Receiving the FIN would cause the requestor’s TCP to report an end-of-file to the requestor’s process, allowing the requestor to detect this scenario and exit.
The values of the variables keepalive time, keepalive interval, and keepalive probes can usually be changed.
Some systems allow these changes on a per-connection basis, while others allow them to be set only system-wide (or both in some cases).
In Linux, these values are available as sysctl variables with the names net.ipv4 .tcp_keepalive_time, net.ipv4.tcp_keepalive_intvl, and net.ipv4 .tcp_keepalive_probes, respectively. The defaults are 7200 (seconds, or 2 hours), 75 (seconds), and 9 (probes).
Note that [RFC1122] places certain restrictions on the use of keepalives.
In particular, the keepalive time must be configurable and must not default to less than 2 hours.
In addition, keepalives must not be enabled unless an application requests one (although this behavior is violated if the net.inet.tcp.always_ keepalive variable is set).
Linux does not provide a native facility for adding keepalives to applications that do not request it, but a special library can be pre- loaded (i.e., loaded prior to ordinary shared libraries) to get this effect [LKA].
Keepalive Examples
Other End Crashes
Other End Crashes and Reboots
Connection reset by peer
Other End Is Unreachable
