写在前面
声明：此篇博文非本人原创，本人只是在原作者的基础上进行总结学习，此为原文链接。
近两年变化历程
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设备的开发测试环境的推送。
网友评论