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

时间:2021-05-20

苹果最近更新了他们的推送提醒服务协议,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年的新功能吧。

声明:本页内容来源网络,仅供用户参考;我单位不保证亦不表示资料全面及准确无误,也不保证亦不表示这些资料为最新信息,如因任何原因,本网内容或者用户因倚赖本网内容造成任何损失或损害,我单位将不会负任何法律责任。如涉及版权问题,请提交至online#300.cn邮箱联系删除。

相关文章