iPhone的Push(推送通知)功能原理浅析

核心提示：更高一层次：基于token(令牌)的认证在机制 简介里，我提到过APNS判断Push推送消息该发给哪台iPhone的依据是一个“目的iPhone的标识”，iPhone的Push(推送通知)功能原理浅析(2)，这个 标识就是device token(设备令牌)，设备令牌是怎么生成的呢?是每次建立TLS 连接时，而blac

更高一层次：基于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补丁