前言:
APNs 协议在近两年的 WWDC 上改过两次,2015年12月17日更是推出了革命性的新特性。
正文:
对 APNs 的吐槽
APNs 是 Apple Push Notification service 的简称(注意 APNs 的大小写, s不需要大写)。
以下是我收集的一些关于 APNs 的吐槽,你先看下哪些吐槽比较“到位”:
答案会穿插在下文中。
APNs新闻
2014年6月份WWDC搭载iOS8及以上系统的iOS设备,能够接收的最大playload大小提升到2KB。低于iOS8的设备以及OS X设备维持256字节。参考文档:What's New in Notifications - WWDC 2014 - Session 713 - iOS
2015年6月份WWDC宣布将在不久的将来发布 “基于 HTTP/2 的全新 APNs 协议”,并在大会上发布了仅仅支持测试证书的版本。参考文档:What's New in Notifications - WWDC 2015 - Session 720 - iOS, OS X
2015年12月17日起,发布 “基于 HTTP/2 的全新 APNs 协议”,iOS 系统以及 OS X 系统,统一将最大 playload 大小提升到4KB。参考文档:Apple Push Notification Service Update 12-17 2015
新旧 APNs 协议工作示意图对比
接下来我们分别对新旧协议进行一下介绍:
反人类的旧APNs协议设计
在介绍新版 APNs 前,让我们来吐槽下旧的基于二进制的 APNs 协议设计是多么反人类:
在理论上,推送分发的服务器要打开一个同 APNs 网关服务器的
连 接,并保持这个连接。但在旧的协议下,APNs 服务却不保证 socket 能维持这个连接。如果通道上没有消息往来,空闲下来到话,socket将被路由掐断。也就是说:APNs 连接说断就断,而你无能为力。有意思的是:在旧的协议下,如果服务器响应成功的话,你将不会收到任何回应,但是如果服务器响应失败(例如,使用了一个非法 的 Push token),服务器将返回了一个错误编码,并关闭这个socket。最重要的是,你必须重新发送使用这个无效 token 以后发送的所有推送(详情见示意图)。因此,你可能一直不能确定你的推送是否成功的被 APNs 服务器接收。
成功了不响应,失败了才响 应,这个是最大的反人类。于是许多开发者想到了一个很 tricky 的办法:利用这个“漏洞”,比如在每发送10条后故意发送一个错误的token,如果APNs有响应了,就可以确认 APNs 是处在可用状态的,进而确认这10条消息是发送成功的。如果没有响应就说明可能连接已经中断,那么这10条消息很可能是丢失的,然后做进一步的处理。但代 价显而易见:将导致你们的推送系统性能低下。(本文中所说到“你们的推送系统”,如果是使用的第三方的SDK完成的推送服务,那么就是指SDK提供商所搭 建的推送系统。如果是你们公司自己搭建的推送系统,那么就是指你们自己的推送系统。)苹果有一个名为"feedback"的服务,我们可以定时调用这个服 务来获取invalid tokens的列表。这个服务你只要调用一次就可以获得所有的invalid tokens 列表。所以,如果一个应用使用了很多不同公司的推送SDK,他们将会争夺资源去轮询查找invalid tokens列表。invalid token越多,你们的推送系统性能将越低。而且 APNs 只要一发生错误就关闭这个连接,然后重新连接。也就是“重启” socket 连接。
示意图:
图中的 PN2 去哪里了?它被放到了 feedback 列表里,等待下次你调用 feedback 服务,然后重发。
为什么Apple要在旧APNs中设计出“重启”的策略?为了效率。就像PC机出问题,我们总说“重启能解决90%的问题”。
为 了理解“重启”策略,我们可以类比下,熟悉 Erlang/OTP 的朋友可能知道, Erlang/OTP 在处理错误方面有独到之处:监督树(supervision trees)。大致来说,每一个 Erlang 进程都由一个监督进程发起并监视。当一个进程遇到了问题的时候,它就会退出。当进程退出的时候,其监督进程会将其重启。
(这些监督进程由一个引导进程(bootstrap process)发起,当监督进程遇到错误的时候,引导进程会将其重启)
其思想是,快速的失败然后重启比去处理错误要快。像这样的错误处理看起来跟直觉相反 —— 当错误发生的时候通过放弃处理来获得可靠性。但是重启的确是解决暂时性错误的灵丹妙药。
这也可能让你想到 DNS 服务发展史:
DNS 在设计之初是基于 UDP 的,显然这样的设计不能满足当今社会的准确性的需求,于是涌现了如 DNSPod 这样的基于 HTTP 的 DNS 解析服务。但是当时为什么这样设计,实际也很好理解,UDP 效率高,一来一回网络上传输的只有两个包,而 HTTP则需要三次握手三个包,再一拆包,就需要四个包。这是受限于当时整个社会的带宽水平较低,而现在没人会感激 UDP 所节省的流量,所有人都在诟病DNS污染问题。这样你也许就理解了,为什么旧的 APNs 设计如此反人类。这个是必经阶段。
那么接下来就让我们看看Apple为解决这些问题而推出的基于 HTTP/2 的全新 APNs 协议。
基于 HTTP/2 的全新 APNs 协议
来看下新版的 APNs 的新特性:
1)Request 和 Response 支持JSON网络协议
2)APNs支持状态码和返回 error 信息
3)最大推送长度提升到4096字节(4Kb)
4)可以通过 “HTTP/2 PING ” 心跳包功能检测当前 APNs 连接是否可用,并能维持当前长连接。
5)支持为不同的推送类型定义 “topic” 主题
6)不同推送类型,只需要一种推送证书 Universal Push Notification Client SSL 证书。
示意图:
其中最大的变化就是基于了 HTTP/2 协议,采用了长连接设计,并提供 “HTTP/2 PING ” 心跳包功能检测、维持当前 APNs 连接,解决了老 APNs 无法维持连接的问题。
而且新增的状态码特性,也解决了这个问题:无法获知消息是否成功地从你们的推送系统投递到了 APNs 上。理论上,你们可以保证消息是100%投递到了APNs的,因为你可以准确的知道哪条消息到达了APNs,哪些没到。重发特定失败消息成为可能。
所以上文开头的吐槽中第一条,有一句是“不到位的”,因为现在SDK的提供商能够准确地告诉你哪些消息推送到APNs了,哪些没有。
顺便介绍下 HTTP/2:
HTTP/2 是 HTTP 协议发布后的首个更新,于2015年2月17日被批准。它采用了一系列优化技术来整体提升 HTTP 协议的传输性能,如异步连接复用、头压缩等等,可谓是当前互联网应用开发中,网络层次架构优化的首选方案之一。
Apple 对于 HTTP/2 的态度也非常积极,2015年5月 HTTP/2 正式发表后不久,便在紧接着6月召开的WWDC 2015大会中,向全球开发者宣布,iOS 9 开始支持HTTP/2。
而且如果我们要使用 HTTP/2,那么在网络库的