Notes on detailed interpretation of TCP/IP (Chapter 23)-tcp The keepalive timer

There may be such a standby reality TCP connection: circulating over.

Other words. Assume that both sides of the TCP connection do not send data to each other. There is no exchange of information between the two TCP modules, which means that we can start a client to establish a connection with the server, and then not use it for a long time, while the connection remains. The middle router can crash and restart, the phone line can be hung up and then connected, but only to the end of the host is not restarted. The connection remains established.

However, many times a server wants to know if the client host crashes and shuts down or crashes and starts again. Many implementations provide a keepalive timer that provides the ability to do so. KeepAlive is not part of the TCP specification.

Working principle of KeepAlive Timer:

Assume that a given connection does not have any action within 2 hours. Then the server sends a segment of the probing message to the customer.

The client host must be in one of the following 4 states:

(1) Customer host is still normal execution, and from the server can reach. The client's TCP response is normal. While the server also knows the other side of the normal work, the server within 2 hours will be keepalive timer reset.

(2) Customer host has crashed. And it shuts down or is starting again. In either case, the client's TCP is not responding. The server will not receive a response to the probe. and timed out after 75 seconds, sending a total of 10 probes. Each interval is 75 seconds. Assuming that the server does not receive a response, it feels that the client host has shut down and terminated the connection.
(3) Client host crashes and has been started again. This is where the server will receive a response to its keepalive probe. But this response is a rst reset. Causes the server to terminate this connection.

(4) Normal execution of client's host. However, the server is unreachable.

This is similar to state 2, because TCP cannot differentiate between state 4 and 2, and what it can find is that it does not receive a sniffing response.

The server does not care about the client host being shut down and another boot, and when the system is shut down by the operator, the entire application process is terminated. This causes the client's TCP to emit a fin on the connection. Receiving fin will cause TCP of the server to report the file end to the server process, allowing the server to detect this condition.

Original author, reprint please place: http://blog.csdn.net/xifeijian/article/details/44263873

Notes on detailed interpretation of TCP/IP (Chapter 23)-tcp The keepalive timer