APNs 2014、2015年的变更

写在前面

声明:此篇博文非本人原创,本人只是在原作者的基础上进行总结学习,此为原文链接

近两年变化历程

2014年6月份 WWDC 搭载 iOS8 及以上系统的 iOS 设备,能够接收的最大 playload 大小提升到2KB。低于 iOS8 的设备以及 OS X 设备维持256字节。

2015年12月17日起,发布 “基于 HTTP/2 的全新 APNs 协议”,iOS 系统以及 OS X 系统,统一将最大 playload 大小提升到4KB。

旧版本的 APNs 是基于二进制的,新版本的 APNs 是基于 HTTP 2.0 的。


1.关于推送长度的限制

新 APNs 支持 iOS6 等全版本推送内容达4096字节,旧 APNs 是14年6月之前只支持256字节,在此之后支持 iOS8 以上2048字节。

2.关于推送是否成功的判断

基于二进制的APNs旧协议下:APNs 成功失败全靠猜!
在旧的协议下,如果服务器响应成功的话,你将不会收到任何回应,但是如果服务器响应失败(例如,使用了一个非法的 Push token),服务器将返回了一个错误编码,并关闭这个socket。最重要的是,你必须重新发送使用这个无效 token 以后发送的所有推送。因此,你可能一直不能确定你的推送是否成功的被 APNs 服务器接收。

基于 HTTP/2 的全新协议下:APNs 成功失败都会收到Response。
APNs推送成功时,Response 将返回状态码200,远程通知是否发送成功再也不用靠猜了!
APNs推送失败时,Response 将返回 JSON 格式的 Error 信息。

其中最大的变化就是基于了 HTTP/2 协议,采用了长连接设计,并提供 “HTTP/2 PING ” 心跳包功能检测、维持当前 APNs 连接,解决了老 APNs 无法维持连接的问题。

而且新增的状态码特性,也解决了这个问题:无法获知消息是否成功地从你们的推送系统投递到了 APNs 上。理论上,你们可以保证消息是100%投递到了APNs的,因为你可以准确的知道哪条消息到达了APNs,哪些没到。重发特定失败消息成为可能。

3.关于推送证书

从2015年12月17日起,新增Universal Push Notification Client SSL 证书。

在开发中,往往一条内容,需要向多个终端进行推送,终端有:iOS、tvOS、 and OS X devices, 和借助iOS来实现推送的 Apple Watch。在以往的开发中,不同的推送,需要配置不同的推送证书:我们需要配置:dev证书、prod证书、VOIP证书、等等。而从2015年12月17日起,只使用一种证书就可以了,不再需要那么多证书,这种证书就叫做Universal Push Notification Client SSL 证书(下文统一简称:Universal推送证书)。

一句话:新的Universal Push Notification Client SSL 证书支持所有Apple设备的开发测试环境的推送。

推荐阅读更多精彩内容