HTTP/2 协议用于 iOS 推送提醒服务 (APNS)

127 阅读 0 评论 84 点赞

我是靠谱客的博主快乐黄蜂，最近开发中收集的这篇文章主要介绍HTTP/2 协议用于 iOS 推送提醒服务 (APNS)，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

苹果最近更新了他们的推送提醒服务协议，APNS。这个新版本的协议基于HTTP/2和JSON，相比于旧的二进制协议，新的协议有了巨大改进。

新的APNS协议基于HTTP/2：

新的特性和功能：

基于JSON的请求和响应

对于每个通知，如果成功响应，将会返回200标识 - 不用再去猜测通知是否被接收到

响应错误将会以JSON字符的形式返回

消息的长度从2048个字节增加到4096个字节

连接状态可以通过HTTP/2的ping框架来进行检查

支持主题

通用的推送证书 - 开发和生产使用同一个证书即可

旧的APNS二进制协议

旧的二进制APNS协议有点奇特，一般来说，推送分发的服务器要打开一个同APNS网关服务器的socket连接，并保持这个连接。在旧的协议下，如果服务器响应成功的话，你将不会收到任何回应，但是如果服务器响应失败（例如，使用了一个非法的Push token），服务器将返回了一个错误编码，并关闭这个socket。最重要的是，你必须重新发送使用这个无效token以后发送的所有通知。因此，你可能一直不能确定你的推送是否成功的被服务器接收。许多系统使用这个漏洞，故意发送一个错误的token，这些黑客行为将导致系统性能低下。苹果有一个名为"feedback"的服务，我们可以定时调用这个服务来获取invalid tokens的列表。这个服务你只要调用一次就可以获得所有的invalid tokens 列表。所以，如果一个应用有许多推送通知提供商，他们将会争夺资源去轮询查找invalid tokens列表。invalidtoken越多，你系统性能将越低，所以APNS只要一发生错误就关闭这个连接。

不过仍然还有一些限制。获取TLS证书比较复杂，而且存储-转发能力弱爆了，APNS在设备下线的时候只保留一个通知，并且设备上线之后也不会向服务器上传信息，Google Cloud Messaging就有所有这些特性。

考虑到GCM现在也支持iOS设备了，那么APNS和GCM现在形成了竞争关系。让我共同期待APNS在2016年的新功能吧。