[Computer Network]-TCP-Keep-alive Mechanism

introduction

Keep-alive mechanismIt is a way to detect the other party without affecting the content of the data stream. It is implemented by a keep-alive timer . When the timer is triggered, one end of the connection will send a keep-alive probe (referred to as keep-alive) message, and the other end will send an ACK as a response when receiving the message.

The keepalive mechanism is not part of the TCP specification. The host requirement RFC 1122 gives three reasons for this:

  1. When a brief network error occurs, the keep-alive mechanism will disconnect a good connection (the end receiving the keep-alive message may not respond due to a temporary failure, and the failure may recover soon, but the other end does not know , he only knew that the keep-alive message he sent did not receive a response, so he mistakenly believed that the other party was no longer working, so he disconnected)
  2. The keep-alive mechanism will occupy unnecessary bandwidth (because it does not affect the data flow and requires additional packet overhead)
  3. Spending more money on the Internet under metered traffic (also because of the extra packets used)

The keep-alive function is generally provided for server applications. The server application hopes to know whether the client host crashes or leaves, so as to decide whether to bind resources to the client. After all, as a service provider, if the other party is no longer working, it will naturally It is necessary to end the behavior of providing services to save your own operating resources.

Using the TCP keepalive function to detect leaving hosts helps the server have relatively short-term conversations with non-interactive clients, such as Web servers, POP, etc.; servers that implement more long-term interactive services may not want to use it. Keep-alive functions, such as ssh and remote login systems such as Windows Remote Desktop

describe

The keep-alive function is turned off by default. Either end of the TCP connection can request to turn on this function. It can be set on one end of the connection, both ends, or neither end.

If within a period of time (called keepalive time , keepalive time keepalive\ timek ee p a l i v e t im e  ) The connection is in aninactive state. The end that turns on the keep-alive function will send a keep-alive detection message to the other party. If the sender does not receive a response message, thenthe keepalive interval(keepalive interval keepalive\ intervalk ee p a l i v e in t er v a l  ), ​​will continue to send keepalive probe messages until the number of sent probe messages reachesthe number of keepalive probes(keepalive probe keepalive\ probek ee p a l i v e p ro b e  ) (because just one lack of response is not enough to determine whether the connection has stopped working), then the other host will be confirmed as unreachable and the connection will be interrupted.

The three variables mentioned above correspond to the sysctl variables in the Linux system net.ipv4.tcp_keepalive_time, net.ipv4.tcp_keepalive_intvl, net.ipv4.tcp_keepalive_probes, and the default is 7200 seconds, 75 seconds and 9 detections

The keep-alive detection message is an empty message segment (or contains only 1 byte), and its sequence number is equal to the maximum sequence number of the ACK message sent by the other host minus 1 . The data of this sequence number has been successfully received, so it will not affect the message segments that have arrived, but the response returned by the probe message can determine whether the connection is still working. Neither the probe nor its response
message contains any new Valid data and will not be retransmitted when they are lost

In the keep-alive function workflow, the party that turns on this function will find that the other party is in one of the following four states:

  1. The other party's host is still working and can be reached. If the other party's TCP responds normally to the keep-alive detection message, the requesting end will reset the keep-alive timer; if an application transmits data through the link before the timer times out (ending the inactive state), the timer will be reset again. Set as keepalive time value
  2. The other party's host has crashed. At this time, the other party's TCP will not respond, and will continue to send probe messages after the keep-alive time interval. Until a total of a specified number of keep-alive probes are sent and no response to any probe message is received, the requesting end will Think that the other party is closed and disconnect
  3. The other party crashed and has restarted. At this time, the connection on the requesting side is equivalent to a half-open connection. At this time, the requesting end will receive a response to its detection message, but this response is a reset segment, and the requesting end will disconnect.
  4. The other party's host is still working, but cannot reach the requesting end for some reason, such as the network cannot transmit. This situation is similar to state 2. TCP cannot distinguish between the two states.

In the first case, the requesting application layer will not be aware of the keep-alive detection (unless the requesting application layer activates the keep-alive function). All operations are completed at the TCP layer and are transparent to the application layer; second and third , in 4 cases, the requesting application layer will receive an error report from its TCP layer, such as "connection timeout", "connection reset by the other party", etc.

Guess you like

Origin blog.csdn.net/Pacifica_/article/details/123960850