iOS的即时通讯推送服务APNs

最新推荐文章于 2025-10-10 17:16:56 发布

原创

最新推荐文章于 2025-10-10 17:16:56 发布 · 856 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#ios

本文介绍了Apple Push Notification service (APNs) 的历史和旧协议的问题，包括连接不稳定和反馈机制不明确等。苹果在2015年引入了基于HTTP/2的新APNs协议，解决了长连接、状态反馈和推送长度限制等问题，提供了更高效的推送服务。新协议支持JSON格式、状态码和错误信息，允许开发者更准确地跟踪推送状态，同时简化了证书管理。然而，APNs仍然存在推送到达率不保证的问题，与Google Cloud Messaging形成竞争。开发者需要更新SDK或服务以支持新协议。

APNs 协议15 年 12 月 17 日更是推出了革命性的新特性。但在国内传播的博客、面试题里关于 APNs 的答案全都是旧的、且是不准确的。

对 APNs 的吐槽

APNs 是 Apple Push Notification service 的简称（注意 APNs 的大小写, s不需要大写）。

反人类的旧APNs协议设计

在介绍新版 APNs 前，让我们来吐槽下旧的基于二进制的 APNs 协议设计是多么反人类。

在理论上，推送分发的服务器要打开一个同 APNs 网关服务器的连接，并保持这个连接。但在旧的协议下，APNs 服务却不保证 socket 能维持这个连接。如果通道上没有消息往来，空闲下来到话，socket将被路由掐断。也就是说：APNs 连接说断就断，而你无能为力。有意思的是：在旧的协议下，如果服务器响应成功的话，你将不会收到任何回应，但是如果服务器响应失败（例如，使用了一个非法的 Push token），服务器将返回了一个错误编码，并关闭这个socket。最重要的是，你必须重新发送使用这个无效 token 以后发送的所有推送（详情见示意图）。因此，你可能一直不能确定你的推送是否成功的被 APNs 服务器接收。

成功了不响应，失败了才响应，这个是最大的反人类。于是许多开发者想到了一个很 tricky 的办法：利用这个“漏洞”，比如在每发送10条后故意发送一个错误的token，如果APNs有响应了，就可以确认 APNs 是处在可用状态的，进而确认这10条消息是发送成功的。如果没有响应就说明可能连接已经中断，那么这10条消息很可能是丢失的，然后做进一步的处理。但代价显而易见：将导致你们的推送系统性能低下。（本文中所说到“你们的推送系统”，如果是使用的第三方的SDK完成的推送服务，那么就是指SDK提供商所搭建的推送系统。如果是你们公司自己搭建的推送系统，那么就是指你们自己的推