在 iOS 平台上，大部分应用是不允许在后台运行并连接网络的。在应用没有被运行的时候，只能通过 Apple Push Notification Service (APNs) 把数据发送到终端用户。对于互联网应用，正确高效的使用 APNs 显然非常重要。

Apple 为应用开发者提供了一个 APNs  推送接口，称为 binary interface。

Binary Interface V1

最初版本的 binary interface 协议如下图，这里我们称之为 v1。

Binary Interface V1

v1 协议有几个问题：

1. 消息是否发送成功没有明确的反馈；
2. 如果一个消息发送失败，比如因为 deviceToken 不合法，APNs 会在大约 500ms 后断掉链接，在断链前发送的消息也会发送失败；
3. 经我们验证，feedback service 只有报告应用被卸载后，造成 deviceToken 失效的错误。而不会报告 deviceToken 不合法这种类型的推送错误。

也就是说如果我们给一批用户发消息，只要有一个 deviceToken 不合法，将会有可能造成若干个用户收不到消息。并且没办法确认哪些 deviceToken 不合法，哪些 deviceToken 需要被重发。这应该是 APNs 丢消息的一个重要的原因。

Binary Interface V2

经过开发者不断的向 Apple 反馈这个问题，Apple 终于推出了一个新版本的 binary interface，称为 enhanced binary interface，我们称这为 v2。

Binary Interface V2

我们发现，在 v1 的基础上增加了两个字段：

Identifier —— 一个任意的值，用于一条消息的识别。如果发送出现问题，错误应答里会把 Identifier 带回来。

Expiry —— 离线消息超时的时间，如果为0或者小于0，APNs 不会保存这条消息。

和 v1 一样，如果消息发送没有问题，APNs 不会有任何返回。和 v1 不同，并且很重要的改进是，如果发送出现错误，v2 会在断链之前返回一个错误应答，带上发消息时的 Identifier 和一个错误码。

error-response packet

根据这个错误应答，我们有机会找到是哪条消息发送出错，并确定哪些消息需要被重发。

参考：

http://blog.jiguang.cn/apns/
http://blog.csdn.net/xcl168/article/details/49790221

The problem with Apples Push Notification Service… Solutions and Workarounds…