Idle say the keepalive mechanism of heartbeat heartbeat packet and TCP protocol

Many application-layer protocols have a heartbeat mechanism, usually the client sends a packet to the server every other time, notifying the server that it is still online and transmitting some data that may be necessary. Typical protocols for using heartbeat packets are IM, such as qq/msn/fetion.

Students who have learned TCP/IP should know that the two main protocols of the transport layer are UDP and TCP, where UDP is non-connected, packet-oriented, and the TCP protocol is a connected, stream-oriented protocol.

So it is very easy to understand, using the UDP protocol client (such as the early "OICQ", heard that oicq.com two days was squatting, good old memories) need to send a heartbeat packet to the server, tell the server itself online.

However, MSN and now QQ tend to use TCP connection, although the TCP/IP underlying provides an optional keepalive (Ack-Ack package) mechanism, but they also implemented a higher-level heartbeat package. It seems to be a waste of traffic and a waste of CPU, a bit baffling.

Specifically, the TCP keepalive mechanism is like this, first of all it seems to default is not open,to use setsockopt will sol_socket. So_keepalive is set to 1, and three parameters can be set TCP_KEEPALIVE_TIME/TCP_KEEPALIVE_PROBES/TCP_KEEPALIVE_INTVL, respectively, how long the connection to start sending KeepAlive ACK packet, send several ACK packets do not reply only when the other side dead, two ACK packets between the length of the interval, in my test of Ubuntu Server 10.04 The default value is 7,200 seconds (2 hours, to not such an egg pain ah! ), 9 times, 75 seconds. So the connection has a time-out window, if there is no communication between the connection, the time window will gradually reduce, when it is reduced to zero, the TCP protocol will send an ACK flag with an empty packet (KeepAlive probe), the other side after receiving the ACK packet, if the connection is normal, Should reply to an ACK, if the connection is wrong (for example, the other party restarts, the connection status is lost), you should reply to a RST, if the other party does not reply, the server every INTVL time to send an ACK, if the successive probes packets are ignored, indicating that the connection was disconnected.

Here is a very detailed introduction to the article: Http://tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO, including the introduction of Keepalive, the relevant kernel parameters, C programming interface, How to enable the KeepAlive mechanism for existing applications (which can or cannot be modified) is well worth reading.

Section 2.4 of this article says "preventing disconnection due to network inactivity", which prevents a connection interruption due to an inactive network connection (no packet for a long time).Many network devices, especially NAT routers, cannot maintain all of their connections due to their hardware limitations (such as memory, CPU processing power), and therefore, when necessary, select inactive connections in the connection pool to kick off。 The typical practice is LRU, the longest data-free connection to t off.by using the TCP keepalive mechanism (which modifies the time parameter), you can make the connection generate some ACK packets every other short period to reduce the risk of being dropped by T, which, of course, is at the expense of additional network and CPU burdens。

As mentioned earlier, many IM protocols implement their own heartbeat mechanism, rather than relying directly on the underlying mechanism, and do not know what the real cause is.

In my opinion, some simple protocols, directly using the underlying mechanism can be completely transparent to the upper layer, reducing the development difficulty, do not need to manage the status of the connection. The protocols that implement the heartbeat mechanism are expected to transmit some data at the same time as the heartbeat packet is sent, so that the server can learn more about the state. For example, some clients like to collect information about a user ... Anyway is to send a package, it is better to plug some data, or Baotou and wasted ...

That is probably the case, if you have Daniel know the real reason, but also hope to enlighten.


@2012-04-21

P.S. By consulting a colleague who has done IM, the answer should be,its own implementation of the heartbeat mechanism common, can ignore the underlying UDP or TCP protocol. If it is only with the TCP protocol, then the direct use of the keepalive mechanism is sufficient。

@2015-09-14
To add @Jack response:
“In addition to demonstrating that the application is still alive (the process is still on, the network is unobstructed), it is more important to indicate that the application is still working properly. While the TCP keepalive has an operating system for sniffing, even if the process is deadlocked or blocked, the operating system will send and receive TCP keepalive messages as usual. The other person is not aware of this exception. From "Linux Multithreaded Server Programming"

1.KeepAlive mechanism can not be detected in many cases, such as the network connection is disabled by the software, not reliable, the network state is complex situation this situation is particularly serious. 2. Self-realization of the heartbeat can be added more flexible and practical mechanisms, such as the lack of a heartbeat, you can check again immediately, check the interval is reduced, so that you can more quickly sense the network state, rather than waiting for a fixed time.

--

Reprint please specify from http://www.felix021.com/blog/read.php?2076 , if reproduced text is indicated original source, thank you:)

Idle say the keepalive mechanism of heartbeat heartbeat packet and TCP protocol