Keepalive vs. heart-beat in Network Programming

On the way to work this week, I read the book "valid TCP/IP programming". Below are some reading notes. This book is well written. It applies to people who often want to write network programming with certain quality, but don't have time to chew on the topic books about the TCPIP protocol.

 

Many people know that TCP does not actively detect the loss of connections, which means that if the two sides do not interact, if the network is disconnected or one machine crashes, the other party will never know that the connection is no longer available. There are two methods to check whether the connection is lost: keepalive and heart-beat.

Keepalive is a mechanism provided by many TCP implementations. It allows both parties to send special data segments when the connection is idle, and determine whether the connection is still alive by response or not (the so-called keep ~~ Alive ). I once wrote a blog about keepalive.
But later I found that keepalive is not common in actual applications. Why? This is due to the original intention of the keepalive design.Keepalive is applicable to clearing connections that have been killed for a long time.

For example, a user creates a TCP connection to access a Web server. After the user completes the operation, the user roughly dials the network cable. In this case, the TCP connection has been disconnected, but the Web server does not know that it will still guard the connection. If the Web server is configured with keepalive, it will be able to confirm that the connection has been interrupted after the user has disconnected the network cable for about a few hours, then discard the connection and Recycle resources.
When keepalive is used, it first requires that the connection is not active for a certain period of time (usually several hours), and then sends a data segment. After multiple attempts (there is also a time interval between each attempt ), if no response is received, the connection is interrupted. It can be imagined that the entire cycle takes a long time.
So, as in the previous scenario,Keepalive is a good option to clear and recycle connections that have been dead for a long time without the knowledge of the system.

However, in most cases, especially in distributed environments, what we need isThe mechanism for fast or real-time monitoring of the connection status. Here, heart-beat is a more suitable solution.

Heart-beat (Heartbeat), in my understanding, is similar to keepalive. It sends a signal to each other. If no response is sent for multiple times, the connection is interrupted. The difference between them is that keepalive is a built-in mechanism in TCP implementation. It starts the keepalive mechanism by setting parameters when creating a TCP connection, while heart-beat needs to be implemented at the application layer on TCP. A simple heart-beat is usually used to test whether the connection is interrupted at a relatively short interval, which can quickly determine whether the connection is interrupted. In addition, because it is implemented at the application layer, you can determine the behavior that should be taken after the connection is interrupted, while keepalive will only discard the connection after judging that the connection fails.
A very interesting question about heart-beat is whether to send a "Heartbeat" signal in the connection that transmits real data or create a connection that sends a "Heartbeat" signal. For example, machines A and B transmit data by connecting M. To detect the connection status between machines A and B, should we transmit the "Heartbeat" signal in the connection M, or create a new connection n to specifically transmit the "Heartbeat? I personally think both are acceptable. If you are concerned about the end-to-end connection status, you can achieve a "Heartbeat" directly in the connection ". However, most of the time, we are concerned with the network conditions and the connection status between the two hosts. In this case, creating a dedicated "Heartbeat" connection is not a problem.