The development of mobile IM based on TCP still needs to keep the heartbeat alive

Many people think that ,TCP The agreement itself is born with KeepAlive Mechanism , Why based on its communication links , You still need to implement additional heartbeat preservation at the application layer ？ This article will start from the mobile terminal IM From a practical point of view , Even if you use TCP agreement , The heartbeat of the application layer is still essential .

 

What is heartbeat preservation ？

In the use of TCP Long connection IM Service design , It often involves the heartbeat . Heartbeat usually refers to a certain end ( In most cases, it is the client ) Send custom instructions to the opposite end at regular intervals , To determine whether the two sides survive , Because it is sent at regular intervals , It's like a heartbeat , So it is called heartbeat command .

TCP The agreement does not come with it KeepAlive Yes, I don't know ？

Then the problem comes ： Why do I need to heartbeat in the application layer , Don't TCP Isn't it a reliable connection ？ We can't rely on TCP Do you want to do a disconnection test ？ For example, use TCP Of KeepAlive Mechanism to achieve . Is application layer heartbeat a current best practice ？ What kind of heartbeat is the best practice .

Many are mobile terminals IM My colleagues , It is true that these problems have not been carefully considered before , Subconsciously take it for granted that this is just a simple heartbeat . ok , The fact is not so simple , Please read on .

IM The importance of maintaining effective long connections in

For clients , Use TCP The biggest driving force to realize business through long connections is ： When the current connection is available , Each request is just a simple data sending and receiving , Save it. DNS analysis , Time to set up the connection , It's greatly speeding up requests , At the same time, it is also conducive to receiving real-time messages from the server . But only if the connection is available .

If the connection does not hold well , Every request becomes a stroke of luck ： Good luck , Send requests over long connections and receive feedback . Bad luck , The current connection has expired , The request did not receive feedback until it timed out , Another connection establishment process is required , It is not even as efficient as HTTP. The premise of connection maintenance is to check the availability of the connection , And actively abandon the current connection and establish a new connection when the connection is unavailable .

Based on this premise , There must be a mechanism to detect connection availability . At the same time, the particularity of mobile network also requires the client to send certain signaling in spare time , Avoid connections being recycled .

For servers , It is also important to be informed of connection availability in a timely manner ： On the one hand, the server needs to clean up invalid connections in time to reduce the load , On the other hand, it is also the demand of the business , For example, the server in the game copy needs to deal with the problems caused by the player's disconnection in time .

TCP Of KeepAlive The reason why the application layer heartbeat keeping alive mechanism cannot be replaced

It says the importance of staying connected , Now let's go back to the implementation . Why do we need to use application layer heartbeat for detection , Instead of using it directly TCP The characteristics of ？ Instant messaging chat software app Development of the v：weikeyun24 consulting

 

We know TCP Is a connection based protocol , Its connection status is maintained by a state machine , After connecting , Both sides will be in established state , After that, the state will not change actively . This means that if the upper layer does not make any calls , Always make TCP Connection free , So the connection doesn't have any data , But still stay connected , One day 、 A week 、 Even a month , Even if the intermediate route crashes and restarts countless times during this period . For example, chestnuts are often encountered in reality ： When we ssh To your own VPS On , Then accidentally kick off the network cable , The network changes at this time will not be TCP Detected , When we plug the cable back in , It can still be used normally ssh, At the same time, nothing happened at this time TCP Reconnection of .

Someone will say TCP Not having KeepAlive Mechanism , It's OK to implement it through this mechanism ？ But in fact ,TCP KeepAlive The mechanism of does not apply to this .Keep Alive When the mechanism is turned on ,TCP The layer will send the corresponding... After the timing time KeepAlive Probe to determine connection availability . The general time is 7200 s, Try again after failure 10 Time , Each time the timeout is 75 s. Obviously, the default values do not meet our needs , Can it be satisfied after modifying the settings ？ The answer is still No .

because TCP KeepAlive It is used to detect whether the connection is alive or dead , The heartbeat mechanism comes with an additional function ： Check the survival status of both communication parties . The two seem to have the same meaning , But it's actually quite different .

Consider a situation , A server is overloaded for some reason ,CPU 100%, Unable to respond to any business requests , But use TCP The probe can still determine the connection status , This is the typical state where the connection is alive but the service provider is dead , For clients , At this time, the best choice is to disconnect and reconnect to other servers , Instead of always thinking that the current server is available , Keep sending requests to the current server that are bound to fail .

From above we can know ,KeepAlive It is not suitable for detecting the survival of both parties , This scenario also depends on the heartbeat of the application layer . The application layer heartbeat has greater flexibility , The detection timing can be controlled , Interval and processing flow , You can even attach additional information to the heartbeat package . From this point of view , The heartbeat of the application layer is indeed a best practice .

Implementation scheme reference of heartbeat keeping alive mechanism

From the above we can come to the conclusion that , For now , The application layer heartbeat is really used to detect the validity of the connection , Best practices for survival of both parties , So the remaining question is how to achieve .

The simplest and crudest course of action is a timed heartbeat , Every time 30 One heartbeat per second ,15 If no heartbeat packet is received within seconds, the current connection is considered invalid , Disconnect and reconnect . This approach is the most direct , The implementation is also simple . The only problem is to compare the power consumption with the flow consumption . With a protocol package 5 Byte count , Send and receive in one day 2880 A heartbeat packet , One month is 5 * 2 * 2880 * 30 = 0.8 M Of traffic , If you install more on your mobile phone IM Software , Every moonlight heartbeat has lost several megabytes of traffic , Not to mention the power loss caused by frequent heartbeat .

Since frequent heartbeat will bring the disadvantages of power consumption and flow consumption , The natural direction of improvement is to reduce the heart rate , However, the real-time performance of connection detection should not be affected too much . Based on this demand , Generally, the heartbeat interval can be adjusted according to the program status , When the program is in the background ( Android is mainly considered here ), Try to lengthen the heartbeat interval ,5 minute 、 even to the extent that 10 Every minute is OK .

And when App At the front desk, you will operate according to the original rules . The judgment of connection reliability can also be relaxed , Avoid the case that the connection is considered invalid after a heartbeat timeout , Use error accumulation , Only when the heartbeat times out n The current connection is determined to be unavailable after . Of course, there are some small trick For example, the heartbeat packet cycle is timed from the last instruction packet received instead of a fixed time , This can also reduce the number of heartbeats to a certain extent .