默认
打赏 发表评论 21
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
iOS的推送服务APNs详解:设计思路、技术原理及缺陷等
微信扫一扫关注!

前言


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

本文重点介绍APNs的设计思路、技术原理以及各种缺陷槽点,也希望能给自已设计推送系统的同行带来启发。

更多资料


有关推送技术的精选文章精参见:http://www.52im.net/forum.php?mod=collection&action=view&ctid=11

对 APNs 的吐槽


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

以下是我收集的一些关于 APNs 的吐槽,你先看下哪些吐槽比较“到位”:
QQ20160601-0.png
答案会穿插在下文中。

有关APNs的新闻一览


QQ20160601-1.png

新旧 APNs 协议工作示意图对比


基于二进制的旧 APNs 协议:
1.png

基于 HTTP/2 的新 APNs 协议:
2.png

接下来我们分别对新旧协议进行一下介绍。

反人类的旧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 连接。

示意图:
3.png

图中的 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 的新特性:
  • Request 和 Response 支持JSON网络协议
  • APNs支持状态码和返回 error 信息:
       - APNs推送成功时 Response 将返回状态码200,远程通知是否发送成功再也不用靠猜了!
       - APNs推送失败时,Response 将返回 JSON 格式的 Error 信息。
  • 最大推送长度提升到4096字节(4Kb)
  • 可以通过 “HTTP/2 PING ” 心跳包功能检测当前 APNs 连接是否可用,并能维持当前长连接。
  • 支持为不同的推送类型定义 “topic” 主题
  • 不同推送类型,只需要一种推送证书 Universal Push Notification Client SSL 证书。

示意图:
4.png

其中最大的变化就是基于了 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,那么在网络库的选择上必然要使用 NSURLSession。

我们都知道 HTTP/2 是复用 TCP 管道连接的,而且 HTTP/2 也以高复用著称,这也使新的 APNs 协议更加高性能。(题外话:这点也同样体现在 NSURLSession 底层对于每个 session 是对多个 task 进行连接的复用。)

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推送证书)。

改进了,但仍需改进:还是有坑


APNs的确改进来不少,但仍有需要改进对地方。除了获取TLS证书比较复杂未解决外,还有一些坑。

文章开头提到过以下这种情况:
5.jpg

很遗憾的告诉你,你的吐槽是“到位的”:你以后还得忍受这种反人类的设计。这中间发生了什么?

当 APNs 向你发送了4条推送,但是你的设备网络状况不好,在 APNs 那里下线了,这时 APNs 到你的手机的链路上有4条任务堆积,APNs 的处理方式是,只保留最后一条消息推送给你,然后告知你推送数。那么其他三条消息呢?会被APNs丢弃。

有一些 App 的 IM 功能没有维持长连接,是完全通过推送来实现到,通常情况下,这些 App 也已经考虑到了这种丢推送的情况,这些 App 的做法都是,每次收到推送之后,然后向自己的服务器查询当前用户的未读消息。但是APNs也同样无法保证这四条推送能至少有一条到达你的 App。很遗憾的告诉这些App,这次的更新对你们所遭受对这些坑,没有改善。

为什么这么设计?APNs的存储-转发能力太弱,大量的消息存储和转发将消耗Apple服务器的资源,可能是出于存储成本考虑,也可能是因为 Apple 转发能力太弱。总之结果就是 APNs 从来不保证消息的达到率。并且设备上线之后也不会向服务器上传信息。

所以上文开头的吐槽中第一条,也有一句是“到位的”,因为现在SDK的提供商依然无法保证,消息推到了 APNs,APNs能推到 App 那里。

但Google Cloud Messaging就有这些特性。而且 GCM 现在也支持iOS设备了,那么 APNs 和 GCM 现在就形成了竞争关系。让我共同期待 APNs 在2016年6月的 WWDC 的能有新的改进吧。

对App开发的影响


想使用新协议,如果你用的第三方推送,这里最明显的操作,就是你必须更新到支持新协议的SDK版本。因为新协议需要 SDK 上传你 app 的 bundle id ,生成各个平台推送用的 topic。如果你们自己搭建的服务,则需要你自己上传。老协议不用上传。

新 APNs 支持 iOS6 等全版本推送内容达4096字节,旧 APNs 是14年6月之前只支持256字节,在此之后支持 iOS8 以上2048字节。以前受限于推送字节,比如推文章 url,开发者选择超出256后推送id,甚至不判断直接推 id,接收后再请求完整 url。一旦请求错误,推送内容可能丢失。现在可以避免了。

如何创建 Universal Push Notification Client SSL 证书


现在你知道什么是 Universal Push Notification Client SSL 证书了,那么如何创建它?
a.png

图中其他方式,就叫做非 Universal 方式(下文简称:非 Universal 推送证书):
b.png

结束语


对于 APNs 而言,iOS9 的这一更新是有划时代意义的,请即刻敦促你们公司的服务端进行升级,或者使用支持新 APNs 协议的 SDK 进行推送服务。 文中如有错误,并请帮忙指正,反馈请发往微博@iOS程序犭袁。

全站即时通讯技术资料分类


[1] 网络编程基础资料:
TCP/IP详解 - 第11章·UDP:用户数据报协议
TCP/IP详解 - 第17章·TCP:传输控制协议
TCP/IP详解 - 第18章·TCP连接的建立与终止
TCP/IP详解 - 第21章·TCP的超时与重传
理论经典:TCP协议的3次握手与4次挥手过程详解
理论联系实际:Wireshark抓包分析TCP 3次握手、4次挥手过程
计算机网络通讯协议关系图(中文珍藏版)
NAT详解:基本原理、穿越技术(P2P打洞)、端口老化等
UDP中一个包的大小最大能多大?
Java新一代网络编程模型AIO原理及Linux系统AIO介绍
NIO框架入门(三):iOS与MINA2、Netty4的跨平台UDP双向通信实战
NIO框架入门(四):Android与MINA2、Netty4的跨平台UDP双向通信实战
>> 更多同类文章 ……

[2] 有关IM/推送的通信格式、协议的选择:
为什么QQ用的是UDP协议而不是TCP协议?
移动端即时通讯协议选择:UDP还是TCP?
如何选择即时通讯应用的数据传输格式
强列建议将Protobuf作为你的即时通讯应用数据传输格式
移动端IM开发需要面对的技术问题(含通信协议选择)
简述移动端IM开发的那些坑:架构设计、通信协议和客户端
理论联系实际:一套典型的IM通信协议设计详解
58到家实时消息系统的协议设计等技术实践分享
>> 更多同类文章 ……

[3] 有关IM/推送的心跳保活处理:
Android进程保活详解:一篇文章解决你的所有疑问
Android端消息推送总结:实现原理、心跳保活、遇到的问题等
为何基于TCP协议的移动端IM仍然需要心跳保活机制?
微信团队原创分享:Android版微信后台保活实战分享(进程保活篇)
微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)
移动端IM实践:实现Android版微信的智能心跳机制
移动端IM实践:WhatsApp、Line、微信的心跳策略分析
>> 更多同类文章 ……

[4] 有关WEB端即时通讯开发:
新手入门贴:史上最全Web端即时通讯技术原理详解
Web端即时通讯技术盘点:短轮询、Comet、Websocket、SSE
SSE技术详解:一种全新的HTML5服务器推送事件技术
Comet技术详解:基于HTTP长连接的Web端实时通信技术
WebSocket详解(一):初步认识WebSocket技术
socket.io实现消息推送的一点实践及思路
>> 更多同类文章 ……

[5] 有关IM架构设计:
浅谈IM系统的架构设计
简述移动端IM开发的那些坑:架构设计、通信协议和客户端
一套原创分布式即时通讯(IM)系统理论架构方案
从零到卓越:京东客服即时通讯系统的技术架构演进历程
蘑菇街即时通讯/IM服务器开发之架构选择
腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT
微信技术总监谈架构:微信之道——大道至简(演讲全文)
如何解读《微信技术总监谈架构:微信之道——大道至简》
快速裂变:见证微信强大后台架构从0到1的演进历程(一)
17年的实践:腾讯海量产品的技术方法论
>> 更多同类文章 ……

[6] 有关IM安全的文章:
即时通讯安全篇(一):正确地理解和使用Android端加密算法
即时通讯安全篇(二):探讨组合加密算法在IM中的应用
即时通讯安全篇(三):常用加解密算法与通讯安全讲解
即时通讯安全篇(四):实例分析Android中密钥硬编码的风险
传输层安全协议SSL/TLS的Java平台实现简介和Demo演示
理论联系实际:一套典型的IM通信协议设计详解(含安全层设计)
微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解
来自阿里OpenIM:打造安全可靠即时通讯服务的技术实践分享
>> 更多同类文章 ……

[7] 有关实时音视频开发:
即时通讯音视频开发(一):视频编解码之理论概述
即时通讯音视频开发(二):视频编解码之数字视频介绍
即时通讯音视频开发(三):视频编解码之编码基础
即时通讯音视频开发(四):视频编解码之预测技术介绍
即时通讯音视频开发(五):认识主流视频编码技术H.264
即时通讯音视频开发(六):如何开始音频编解码技术的学习
即时通讯音视频开发(七):音频基础及编码原理入门
即时通讯音视频开发(八):常见的实时语音通讯编码标准
即时通讯音视频开发(九):实时语音通讯的回音及回音消除概述
即时通讯音视频开发(十):实时语音通讯的回音消除技术详解
即时通讯音视频开发(十一):实时语音通讯丢包补偿技术详解
即时通讯音视频开发(十二):多人实时音视频聊天架构探讨
即时通讯音视频开发(十三):实时视频编码H.264的特点与优势
即时通讯音视频开发(十四):实时音视频数据传输协议介绍
即时通讯音视频开发(十五):聊聊P2P与实时音视频的应用情况
即时通讯音视频开发(十六):移动端实时音视频开发的几个建议
即时通讯音视频开发(十七):视频编码H.264、V8的前世今生
简述开源实时音视频技术WebRTC的优缺点
良心分享:WebRTC 零基础开发者教程(中文)
>> 更多同类文章 ……

[8] IM开发综合文章:
移动端IM开发需要面对的技术问题
开发IM是自己设计协议用字节流好还是字符流好?
请问有人知道语音留言聊天的主流实现方式吗?
IM系统中如何保证消息的可靠投递(即QoS机制)
谈谈移动端 IM 开发中登录请求的优化
完全自已开发的IM该如何设计“失败重试”机制?
微信对网络影响的技术试验及分析(论文全文)
即时通讯系统的原理、技术和应用(技术论文)
开源IM工程“蘑菇街TeamTalk”的现状:一场有始无终的开源秀
>> 更多同类文章 ……

[9] 开源移动端IM技术框架资料:
开源移动端IM技术框架MobileIMSDK:快速入门
开源移动端IM技术框架MobileIMSDK:常见问题解答
开源移动端IM技术框架MobileIMSDK:压力测试报告
开源移动端IM技术框架MobileIMSDK:Android版Demo使用帮助
开源移动端IM技术框架MobileIMSDK:Java版Demo使用帮助
开源移动端IM技术框架MobileIMSDK:iOS版Demo使用帮助
开源移动端IM技术框架MobileIMSDK:Android客户端开发指南
开源移动端IM技术框架MobileIMSDK:Java客户端开发指南
开源移动端IM技术框架MobileIMSDK:iOS客户端开发指南
开源移动端IM技术框架MobileIMSDK:Server端开发指南
>> 更多同类文章 ……

[10] 有关推送技术的文章:
iOS的推送服务APNs详解:设计思路、技术原理及缺陷等
Android端消息推送总结:实现原理、心跳保活、遇到的问题等
扫盲贴:认识MQTT通信协议
一个基于MQTT通信协议的完整Android推送Demo
求教android消息推送:GCM、XMPP、MQTT三种方案的优劣
移动端实时消息推送技术浅析
扫盲贴:浅谈iOS和Android后台实时消息推送的原理和区别
绝对干货:基于Netty实现海量接入的推送服务技术要点
移动端IM实践:谷歌消息推送服务(GCM)研究(来自微信)
为何微信、QQ这样的IM工具不使用GCM服务推送消息?
>> 更多同类文章 ……

[11] 更多即时通讯技术好文分类:
http://www.52im.net/forum.php?mod=collection&op=all

(原文链接:http://www.jianshu.com/p/ace1b422bad4#

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

标签:推送技术
上一篇:Android端消息推送总结:实现原理、心跳保活、遇到的问题等下一篇:自已写的推送服务在小米系统遇到的后台心跳停止问题

本帖已收录至以下技术专辑

推荐方案
评论 21
这篇文章终于跟上ios的版本了,哈哈
签名: 好想把妹!
讲的很清楚,赞一个!
很有意义的文章
受教了·
感谢楼主分享
好贴,干得漂亮!
对APNs有了新的了解
签名: 该会员没有填写今日想说内容.
好贴,干得漂亮!
签名: ········
好帖
签名: 心情好
不错不错不错不错不错不错不错不错
相当清晰的说明
现在消息免打扰怎么做呢?特定时间特定用户特定用户特定消息免打扰 就是A 用户在i1手机上 10:00-20:00这个时间段内 群消息免打扰或者@消息免打扰 ,i2手机上一切正常,由于安卓可以拦截显示,iOS 能拦截吗
引用:xiaowuqing 发表于 2021-02-23 14:18
现在消息免打扰怎么做呢?特定时间特定用户特定用户特定消息免打扰 就是A 用户在i1手机上 10:00-20:00这个 ...

ios估计只能在自已的服务端来实现推送时段逻辑的处理
楼主,有遇到过这个问题吗?APP注销后,重新输入密码重登(这个过程devicetoken没有改变,重登后推送的token一样。注销动作也只是普通的业务逻辑)。服务端apns推送,apns回调推送成功,但是,app就是无法接受到通知。除非杀进程,重新打开app,才能收到apns通知。有遇到这个问题吗?客户端和服务端的代码查阅后都没问题,apns推送回调也告知推送成功,但是,用户就是收不到,必现的。
引用:小张 发表于 2021-09-08 16:04
楼主,有遇到过这个问题吗?APP注销后,重新输入密码重登(这个过程devicetoken没有改变,重登后推送的toke ...

没有遇到这种情况,你这台手机的ios是什么版本?
引用:JackJiang 发表于 2021-09-08 17:54
没有遇到这种情况,你这台手机的ios是什么版本?

ios 13+  ios12+ 等都会。我这边是有个IM APP,刚好遇到这种情况,尴尬
引用:小张 发表于 2021-09-08 21:02
ios 13+  ios12+ 等都会。我这边是有个IM APP,刚好遇到这种情况,尴尬

这两个版本的ios我也都用过,貌似没遇到过你说的情况,会不会是你推送服务端搞错了证书或token?
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部