Why does the mobile IM based on TCP still need to keep the heartbeat alive?

1、 Preface

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 .

of TCP Introduction to the authoritative theory of agreement , Please see the 《TCP/IP Detailed explanation 》 This book .

explain ： This article quotes the technical data of Netease Yunxin xiangwangfeng , Thanks for sharing. . （ This article is published synchronously in ：http://www.52im.net/thread-33-1-1.html）

2、 Exchange of learning  

- Instant messaging development communication group ： 215891622 [ recommend ]

- Mobile IM Develop recommended articles ：《 Beginner level one is enough ： Develop mobile from scratch IM》

3、 Reference material

《TCP/IP Detailed explanation  -  The first 11 Chapter ·UDP： User datagram protocol 》
《TCP/IP Detailed explanation  -  The first 17 Chapter ·TCP： Transmission control protocol 》
《TCP/IP Detailed explanation  -  The first 18 Chapter ·TCP Connection establishment and termination 》
《TCP/IP Detailed explanation  -  The first 21 Chapter ·TCP Over time and retransmission 》
《 Easy to understand - In depth understanding of TCP agreement （ On ）： Theoretical basis 》
《 Easy to understand - In depth understanding of TCP agreement （ Next ）：RTT、 The sliding window 、 Congestion handling 》
《 Theoretical Classics ：TCP Agreed 3 Shake hands with 4 Detailed explanation of the wave process 》
《 Computer network communication protocol diagram （ Chinese Collection Edition ）》
《NAT Detailed explanation ： The basic principle 、 Crossing technology (P2P Hole digging )、 Port aging, etc 》

4、 Origin of this article

do  Mobile IM Over the years , Often discuss and communicate with relevant personnel . We often meet some serious technicians who ask for technical details , Such as the mainstream mobile terminal IM How to do heartbeat 、 How to ensure that the news will reach 、 How to speed up file uploading . Because I'm too busy at work , There is no time for in-depth collation and summary , Often only a brief introduction , It cannot be expanded in detail , So I decided to write it in words , There's also something about moving IM A series of articles on problem solving .

5、 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 .

Interested in learning about IM/ Push the article of heartbeat keeping alive technology , Please see the ：

《Android Detailed explanation of process assurance ： One article solves all your questions 》
《Android End message push summary ： Realization principle 、 The heartbeat keeps alive 、 Problems encountered, etc 》
《 Wechat team original sharing ：Android Version of wechat backstage to keep the real battle sharing ( Keep the process alive )》
《 Wechat team original sharing ：Android Version of wechat backstage to keep the real battle sharing ( Network security chapter )》
《 Mobile IM practice ： Realization Android Version of wechat's intelligent heartbeat mechanism 》
《 Mobile IM practice ：WhatsApp、Line、 Heartbeat strategy analysis of wechat 》
>>  More articles of the same kind ……

6、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 .

7、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 . See Wechat and operators B（ For another research article on signaling storm technology for wechat, please see ：《 Technical test and analysis of the influence of wechat on the network 》）.

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 .

8、TCP Of KeepAlive unable  The reason for replacing the application layer heartbeat keeping alive mechanism

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 ？

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（ For details, see 《TCP/IP Detailed explanation 》 in The first 23 Chapter ）, 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 .

9、 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 .

（ This article is published synchronously in ：http://www.52im.net/thread-33-1-1.html）

author ：Jack Jiang ( Click the author name to enter Github) 
Source ：http://www.52im.net/space-uid-1.html 
communication ： Welcome to the instant messaging development exchange group  215891622 
Discuss ：http://www.52im.net/ 
Jack Jiang At the same time 【 original Java Swing Appearance engineering BeautyEye】 and 【 Lightweight mobile instant messaging framework MobileIMSDK】 The author of , You can go to download and exchange .