iOS的推送服务APNs详解无锡网站开发公司：设计思绪、技术原理及缺

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

本文重点引见APNs的设计思绪、技术原理以及各种毛病槽点，也宿愿能给自已设计推送系统的同行带来启示。
更多材料
无关推送技术的精选文章精参见：?mod=collection&action=view&ctid=11
对 APNs 的吐槽
APNs 是 Apple Push Notification service 的简称（留意 APNs 的大小写, s不需求大写）。

以下是我搜集的一些关于 APNs 的吐槽，你先看下哪些吐槽比较“到位”：

QQ20160601-0.png (235.16 KB, 下载次数: 373)

下载附件  

5 年前 上传

答案会交叉在下文中。
无关APNs的旧事一览

QQ20160601-1.png (148.96 KB, 下载次数: 390)

下载附件  

5 年前 上传

新旧 APNs 协定工作示用意对比
基于二进制的旧 APNs 协定：

1.png (19.29 KB, 下载次数: 382)

下载附件  

5 年前 上传

基于 HTTP/2 的新 APNs 协定：

2.png (18.37 KB, 下载次数: 371)

下载附件  

5 年前 上传

接上去咱们分别对新旧协定停止一下引见。
反人类的旧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 (19.29 KB, 下载次数: 360)

下载附件  

5 年前 上传