iOS Push原理

转自 

http://www.cocoachina.com/newbie/basic/2010/0401/900.html

 

第一部分：Push原理
(以下绝大多数内容参考自、图片来自iPhone OS Reference Library)
机制简介
Push 的工作机制可以简单的概括为下图

图中，
Provider是指某个iPhone软件的Push服务器。
APNS 是Apple Push Notification Service（Apple Push服务器）的缩写，下文统一使用该缩写。
因 此，整个过程可以分为三个阶段，下面用大家常用的聊天客户端BeejiveIM来说明。（BeejiveIM是一款支持多账户登录的支持Push的 iPhone聊天客户端，支持MSN、Google Talk等）
此时Provider为BeejiveIM服务器，我们在 BeejiveIM上登陆MSN,其实软件是先把登录信息发送到BeejiveIM服务器，再通过其服务器来登陆MSN。因此，当我关 闭了BeejiveIM，BeejiveIM服务器会继续为我登陆MSN，此时如果有人对我的MSN账户发送了消息，那么就会触发Push。此时：
第 一阶段：BeejiveIM服务器把要发送的消息、目的iPhone的标识打包，发给APNS。
第二阶段：APNS在自身的已注册Push服务 的iPhone列表中，查找有相应标识的iPhone，并把消息发到iPhone。
第三阶段：iPhone把发来的消息传递给相应的应用程序， 并且按照设定弹出Push通知。
Push认证
许多朋友说Push不能用。其中一大部分，就是在认证阶段就出了问题。想了解原因？请细 看：
这里所说的认证机制，实际上包含两层。一层是物理连接上的认证，另一层则才是涉及到iPhone 设备令牌的认证。
物理连接上的认证：SSL/TLS链接

（如果你了解TLS，那么这里我几乎无需介绍。）
iPhone在开启Push的时候，会连接 APNS建立一条TLS加密链接。每一台正常的iPhone都有一个独有的设备证书，而APNS也有一个服务器证书。两者建立的时候，会验证彼此的证书有 效性。
TLS链接一旦建立，在没有数据的情况下，只需要每隔15分钟进行一次保活的握手，因此几乎不占流量。而 一旦因为意外原因导致链接中断，iPhone会不断重新尝试建立TLS链接，直到成功。
更高一层次：基于token(令牌)的认证
在机制 简介里，我提到过APNS判断Push推送消息该发给哪台iPhone的依据是一个“目的iPhone的标识”，这个 标识就是device token(设备令牌)。
设备令牌是怎么生成的呢？是每次建立TLS 连接时，APNS通过前一层次(TLS层)里我们提到的每台正常的iPhone唯一的设备证书(unique device certificate)，并用令牌密钥(token key)加密生成的。

在令牌生成了之后，APNS会把设备令牌(device token)返回给iPhone，而对应的Push应用程序（如BeejiveIM），则把返回来的设备令牌(device token)直接发送给Provider（如BeejiveIM服务器）。这样，当Provider有Push消息要发送时，就会把对应 帐号的设备令牌(device token)和消息一起发送给APNS，而APNS再依据设备令牌(device token)，找到相应TLS链接的iPhone，并发送相应的Push消息。
以上复杂的流程可以归纳为下面这幅图：

图中，Client App是iPhone上的Push应用程序。（图中缺了一条（当有Push消息时）由Provider到APNS的链接）
最重要的部分——每台 iPhone独有的设备证书和密钥的来历
正常的iPhone刷系统之后，是没有设备证书和密钥的。这就是为什么iPhone会需要连接到 iTunes上进行激活——激活过程中，Apple会分配给每台iPhone独一无二的设备证书(device certificate)和密钥(key)。
以上我仅仅介绍了从iPhone到APNS的链接建立。其实从Provider到 APNS也有一条TLS链接，但是与本文关系不大，所以不多加介绍了。
我的PUSH问题出在哪里？
相信许多同学都抱有这样的疑问。
正 如上文提到的，iPhone的Push需要APNS生成对应iPhone的设备令牌，但生成这个令牌又需要iPhone上的有效的设备证书(device certificate)和密钥(key)，但是：
iPhone OS 3.X 使用blacksn0w进行解锁的 过程，是不经过iTunes的，而blacksn0w本身又不生成对应的设备证书(device certificate)和密钥(key)，因此这样解锁完的iPhone根本不可能与APNS建立任何的TLS链接，Push自然废 了。
有关各种pushfix补丁
要修补这个问题，唯一的办法就是重新生成唯一且有效的设备证书(device certificate)和密钥(key)。
但是要知道，证书是需要机构签发的，自己一个人随便弄的一个证书，只会被APNS 认为是无效证书。（SSL证书一个多少钱大家可以去查查）
并且对应的文件似乎还和iPhone本机的一些内容相关，不是直接制作好的文件放进去就 可以的。
于是，最早，dev team推出了一个测试版补丁，Push fix by dev team（通过他们的twitter发布的，因此官网没有消息）。这个补丁初期很有效。但是仅在iPhone 2G上比较正常。
之后某人士发布 pushfix 1.0了。由于使用了不同的生成方法，因此在新版本iPhone上也正常工作了。于是风靡一时。
然而，以上两个 补丁都有严重的隐患——他们使用了一个固定的证书作为设备证书(device certificate)。因此在不同iPhone上的区别仅仅在于生成的密钥(key)不同。（待确认）
上面提到 过，APNS依靠每台iPhone独一无二的设备证书(device certificate)和密钥(key)来生成独一无二的设备令牌(device token)，用来标识每台iPhone。
但当多个iPhone的设备证书(device certificate)完全一致时，就存在一定几率使得多个iPhone获得相同的设备令牌(device token)
而 随着这两个补丁的使用人数不断增加，使得出现获得相同设备令牌(device token)的iPhone数量大大增加了。
当 这些相同设备令牌(device token)的iPhone上启用了同一个应用程序的Push的时候，就极有可能出现彼此间的Push串发的现象。——如某论坛目前N多人抱怨QQ的 Push到别人iPhone上的情况就是如此。