Instant Messaging long links in the application layer's heartbeat instead of TCP keepalive?

We know that TCP is a connection-based protocol, its connection state is maintained by a state machine, after the connection is completed, both sides will be in the established state, after which the state will not be actively changed. This means that if the upper layer does not make any calls and keeps the TCP connection idle, the connection is still in a connected state for a day, a week, or even one months, even though the intermediate routing crashes are restarted countless times during this time. For a reality often encountered chestnuts: when we ssh to their own VPS, and then accidentally kicked off the network cable, at this time the net changes will not be detected by TCP, when we re-plug back into the network cable, still can use SSH, and there is no TCP reconnect at this time.

Some people will say that TCP is not a KeepAlive mechanism, through this mechanism to achieve it can do it. But in fact, the TCP KeepAlive mechanism does not really apply to this. After the Keep Alive mechanism is turned on, the TCP layer will send the appropriate KeepAlive probe after the timing time to determine the connection availability. The general time is 7200 s, failed to retry 10 times, each time out of the time of the S. Obviously the default value does not meet our needs, and the modified settings can be satisfied. The answer is still negative.

Because the TCP KeepAlive is used to detect the death and death of the connection, the heartbeat mechanism comes with an additional function: Detecting the surviving state of the communicating parties. Both may sound like a meaning, but they are actually quite different.

Consider a situation in which a server is overloaded for some reason, CPU 100%, unable to respond to any business request, but the use of a TCP probe is still able to determine the state of the connection, the typical connection is alive but the business provider is dead, for the client, The best option at this point is to reconnect to the other server after the disconnection, instead of always thinking that the current server is available and has been sending some requests that will inevitably fail to the current server.

As we can see from the above, KeepAlive is not suitable for detecting scenarios where both sides survive, and this scenario relies on the heartbeat of the application layer. The application-level heartbeat has greater flexibility to control the timing, spacing, and process of detection, and even provides additional information on the heartbeat pack. From this perspective, the heartbeat of the application layer is indeed a best practice.