手机推送原理

Posted 2022-12-06 我来看烟花

      最近做一个物流类的app,要实现把订单推送到送货员手机上,于是就想搞清楚推送这个原理....移动手机推送消息的方式很常见，手机每天都能收到好多推送消息，经过研究发现，这些推送服务的原理都是维护一个长连接（要不不可能达到实时效果），但普通的socket连接对服务器的消耗太大了，所以才会出现像MQTT这种轻量级低消耗的协议来维护长连接。

      我们首先了解一下为什么android维护长连接需要心跳机制，首先我们知道，维护任何一个长连接都需要心跳机制，客户端发送一个心跳给服务器，服务器给客户端一个心跳应答，这样就形成客户端服务器的一次完整的握手，这个握手是让双方都知道他们之间的连接是没有断开，客户端是在线的。如果超过一个时间的阈值，客户端没有收到服务器的应答，或者服务器没有收到客户端的心跳，那么对客户端来说则断开与服务器的连接重新建立一个连接，对服务器来说只要断开这个连接即可。那么在智能手机上的长连接心跳和在Internet上的长连接心跳有什么不同的目的呢？原因就在于智能手机使用的是移动无线网络，那么我们在讲长连接之前我们首先要了解无线移动网络的特点。

       当一台智能手机连上移动网络时，其实并没有真正连接上Internet，运营商分配给手机的IP其实是运营商的内网IP，手机终端要连接上Internet还必须通过运营商的网关进行IP地址的转换，这个网关简称为NAT(NetWork Address Translation)，简单来说就是手机终端连接Internet 其实就是移动内网IP，端口，外网IP之间相互映射。相当于在手机终端在移动无线网络这堵墙上打个洞与外面Internet相连。

      GGSN(GateWay GPRS Support Note 网关GPRS支持节点)模块就实现了NAT功能，由于大部分的移动无线网络运营商为了减少网关NAT映射表的负荷，如果一个链路有一段时间没有通信时就会删除其对应表，造成链路中断，正是这种刻意缩短空闲连接的释放超时，原本是想节省信道资源的作用，没想到让互联网的应用不得以远高于正常频率发送心跳来维护推送的长连接。这也是为什么会有之前的信令风暴，微信摇收费的传言，因为这类的应用发送心跳的频率是很短的，既造成了信道资源的浪费，也造成了手机电量的快速消耗。

     关于信令风暴,我们可以这样理解:由于之前的IM软件少, 移动很节俭的把连接存活时间砍到很短，IM软件商也很机灵的增加保持连接的努力。苹果等智能机为了保证省电而又尽量保持连接，将连接活动设定为很短，然后强制从用户侧发起半释放请求，再把待机拖的很长，尽量长到运营商允许的范围，而且预测网络侧即将发起释放请求的时候再唤醒一次，这样手机的数据连接IP以及GSN处的NAT规则就保住了。再加上手机上各种软件都在尝试保持连接，最终我们在网络上就想象看到这样的活动：

1.用户开机，注册网络，附着数据连接;
2.开个微信，在数据连接上建立个TCP;
3.微信等待，数据连接很快进入半休眠（这个不止一层，浅睡深睡分好几层，期间可能根据协议自动切换或者手动从两侧发起，这就又占用信道），只留几个基本的信道;
4.移动看你快睡熟了，打算掐死你;
5.微信估计移动该来掐死我们了，发起连接保持请求，系统唤醒RF，请求将数据连接开到全活动模式，向服务器发个呵呵，然后马上接着睡，留下移动一人眼睁睁看着两边傻子;
     然后别忘了移动的GSM／EDGE还残留着上个世纪的思路，保持连接的固定开销比较大，而这样为了保持连接两边互斗的开销更大。手机尤其是iphone已经针对这类情况优化，可以保持连接并且待机省电，网络侧有数据可以先从网络测唤醒连接，接受完马上睡，这就是在移动数据上建立push连接的基本原理。       而想象一下手机上同时挂三五个IM，互相之间不知道对方存在，一直自顾自发心跳包，而一个基站又挂几百个手机的情况吧。就好像几百个人打电话说个喂再挂掉，开销估计要超过实际传输的数据，所以移动哭了，然后微信和移动开始互骂, 所以现在3G的信道设计以及网络优化策略已经完全改变，在尽量减少信令负荷的情况下保持长连接，这样手机app可以减少心跳，更省电。有push的话更是如此。最新的移动通信协议其实是可以做到低速信道承载简短的数据业务，可以说专为推送以及IM设计，这才是正道。

     上面又闲扯了一下, 其实我只要想说, 所有的推送功能必须有一个客户端和服务器的长连接，因为推送是由服务器主动向客户端发送消息，如果客户端和服务器之间不存在一个长连接那么服务器是无法来主动连接客户端的。因而推送功能都是基于长连接的基础是上的。

     ios长连接是由系统来维护的，也就是说苹果的IOS系统在系统级别维护了一个客户端和苹果服务器的长链接，IOS上的所有应用上的推送都是先将消息推送到苹果的服务器然后将苹果服务器通过这个系统级别的长链接推送到手机终端上，这样的的几个好处为：1.在手机终端始终只要维护一个长连接即可，而且由于这个长链接是系统级别的不会出现被杀死而无法推送的情况。2.省电，不会出现每个应用都各自维护一个自己的长连接。3.安全，只有在苹果注册的开发者才能够进行推送，等等。

       android的长连接是由每个应用各自维护的，但是google也推出了和苹果技术架构相似的推送框架，C2DM,云端推送功能，但是由于google的服务器不在中国境内，其他的原因你懂的。所以导致这个推送无法使用，android的开发者不得不自己去维护一个长链接，于是每个应用如果都24小时在线，那么都得各自维护一个长连接，这种电量和流量的消耗是可想而知的。虽然国内也出现了各种推送平台，但是都无法达到只维护一个长连接这种消耗的级别。

  那么唠叨到这里,我总结一下吧,其实Apple Push Notification Service,实现的很简单,很环保.原理如下:

• 财大气粗的苹果提供了一堆服务器,每个ios设备和这些服务器保持了一个长连接,ios版本更新提示,手机时钟校准什么的都是通过这个连接.

• 苹果把这个长连接开放出来给大家推送消息用,很积德,因为这是个全球服务,几十亿台ios设备,服务器少说也需要上万台,还没有钱可以赚. andorid的爸爸就不做这个,于是各个app为了发消息,只能直接拼命赖在后台维持一个长连接,电就是这样被耗光的

• 苹果提供消息服务简称为APNS,只是是长连接机器的一部分,你要向你的用户发消息,必须通过apns中转,你写程序发给它,它转发给你的手机,你的推送程序和用户手机没有直接联系

• 消息推送不支持群发,只能一个一个发.如果你的App有100万个用户,要发消息怎么办? 一个一个的发呗,发100万次.消息包大概包括两部分:标示用户手机的id(32个字节)+消息体(<=256Bytes),消息体是json字符串,传输过程用ssl加密的

• 标示用户手机的ID 叫做 device tokens,每个手机都不一样,deviceToken非常重要