最早的心跳机制用于服务器的安全备份机制，是为了防止服务器死机，而在服务器之间采用专用的端口和线路，周期性传送简短的信息，心跳就是形象的比喻。一旦收不到对方的心跳信息，服务器可以接管对方的业务，避免业务的停滞。为了业务的顺畅进行，服务器发送的心跳信息可以非常频密。

 这种机制被手机上的互联网应用所借用，无论是Android的原生应用，还是QQ、微博和微信，都采用了这种心跳机制，也就是终端定时向应用服务器发送简短的信息。但是与服务器之间的心跳机制相比，

还是有一些差别：

  1. 心跳信息是单方向的，只有终端发到应用服务器；
  2. 心跳信息的周期比较长，比如旧版QQ的心跳周期为30s，新版QQ为180s，微信为300s，Google原生应用为1680s左右。

  另外，互联网应用的心跳包除了宣告终端在线外，还有一项重要的任务，就是提供终端的即时地址，方便应用服务器的寻址。

  有了互联网应用的心跳机制，应用服务器可以及时下发（Push）用户相关的信息，比如微信中的短消息、图片或者语音等。

  心跳包也会带来很多副作用，比如终端更为费电，还可能给移动通信网络带来信令风暴。

  看起来很完美的心跳机制，为什么会给移动网络带来信令风暴呢？

  原来，移动通信网络中由于用户众多、资源稀缺，每个用户都是动态占用资源，比如IP地址以及无线信道。每次发送心跳包，都需要移动通信网络为用户分配资源，分配的过程体现在信令的发送和接收上。一次心跳包的发送过程，牵涉的信令多达几十条。

  随着互联网APP的普及，大量的终端周期性地发送心跳包，效果类似于IP网络中的DDOS，必然对移动通信网络设备带来冲击，造成拥塞等情况，这种现象就是信令风暴。信令风暴不仅中国移动的GPRS网络存在，中国联通的WCDMA网络、中国电信的CDMA网络都存在。由于中国移动用户数量庞大，因此信令风暴的影响更显著而已，简而言之，就是50步与100步的差别。

  解决的办法也是有的，一方面心跳机制还需要优化，比如降低心跳包的发送频率，允许用户调低心跳包的发送频率，多应用联合发送心跳包。

  另外一方面还可以做大胆的革新，互联网APP不用IP来寻址，而是用电话号码来寻址，这样借用移动通信网络原生的寻呼机制，就可以不用心跳包了。

  关于整个网络的讨论，这里有我发起的一个讨论，不妨看看：http://gprshome.com/thread-3894-1-1.html

  与这篇文章的思路：《基于IP PUSH实现移动互联网应用的永远在线》http://www.cqvip.com/qk/91404x/201208/43452193.html类似。

  移动网络内部寻址可以不用IP，而直接用MSISDN。