本文是翻译的 APNs 的官方说明html
本身英文不是太好,花了很多时间来翻译,其实以前我是看不进去的。后来发现,只要你一点一点的看,老是能看进去的。web
APNs (Apple Push Ontification service) 服务是远程通知的核心。该服务健全、安全、高效,开发者能够方便的向 iOS tvOS macOS 终端设备推送通知。xcode
当应用在用户设备上运行的时候会在用户设备和 APNs 之间创建一个安全的数据交互链接。应用经过该链接接收通知。在下面的一节中说明安全
另外一半的链接是发送通知的链接,是在你的服务器与 APNs 之间的固定链接,须要在你的开发者账户中用苹果提供的加密证书配置。本质上讲,信息提供者是一个服务器,是由你配置及部署的,须要你来写服务端的功能。下图显示远程通知的传递过程:服务器
当服务器和手机应用中都配置好了以后,此时服务器能够向 APNs 发送推送请求。APNs 接收并向每一个目标设置发送对应的通知信息。在终端设备(iOS macOS tvOS)接收到通知以后,系统把信息传递能你的应用,并管理用户与通知的交互。并发
若是设备接收到通知的时候,你的应用没有处于运行状态,系统仍是能正常的显示通知。
若是 APNs 发送通知的时候,终端设备关机了,APNs 会保留通知信息,并在一段时间以后重试。app
你的服务器在跟 APNs 沟通链接的时候具备如下责任:ide
经过 APNs 接收关于你的app的全球惟一的设备验证码,及其它一些数据网站
根据app功能的须要,决定通知推送的时间ui
创建通知请求,并发送通知请求到 APNs, APNs 再将通知递送到相应的设备
对于每个通知请求,服务器须要作的:
组建一个 JSON 数据,其中包含通知的信息 具体看下一章节
添加 device token和通知信息到一个 HTTP/2 请求中。关于 device token 关于 HTTP/2 参数及回执信息
经过一个永久安全的线路 (Security Architecture,发送包含证书的 HTTP/2 请求到 APNs
工做图示以下图
多个服务器的时候,每一个服务器都须要经过证书或token 链接到 APNs,而后任意一个取得 device token 的服务器就能够发送通知了。
APNs 的服务质量组件能够实现存储而后发送的功能。当 APNs 发送通知到一个离线设备时,APNs 会把通知存储起来(必定的时间内),当设备上线时再递送给设备。这个存储功能只存储一个设备的一个app的最近的通知。若是设备离线中,发送一个到该设备的通知会消除前面存储的通知。若是设备处于离线过久,全部存储的发往该设备的通知都将被消除。
当发送通知的时候在头部添加合并id,可使发送的通知合并起来。当 apns-collapse-id
添加到你发送的 HTTP/2 通知请求中时,APNs 合并apns-collapse-id
值相同的通知。关于更多apns-collapse-id
的知识,点此查看
APNs 采用双层信任机制:链接信任
和 device token 信任
链接信任
工做在服务器与 APNs 之间 | APNs 与设备之间服务器与APNs之间的信任确保服务器与 APNs 之间的链接是安全的,你须要根据本节中提到的信息,按步骤确保服务器与 APNs 之间的安全链接
APNs与设备之间的信任确保只有验证的设备才能链接 APNs 收到通知,APNs 自动确保与设备之间的链接是安全正确的。
服务器与 APNs 通讯的时候,必须实现 验证证书
(基于token的验证)或者 SSL 证书
(基于证书的验证)。你在[开发者账户][]中须要实现这两种验证方式的任意一种,帮助在这。能够查看这里服务器与apns链接信任来肯定你须要选择哪一种验证方式。
device token 能够确保通知只在肯定的服务器与终端设备之间传送。
device token 是一个不透明的 NSData
,包含一个设备上的一个应用的惟一标识。只有 APNs 能解密并查看 device token 中的内容。每一个应用在向 APNs 发送远程推送注册请求的时候都会收到本身的 惟一的 device token,而后必须把 device token 转发给你app的服务器(详见 配置推送支持)。服务器在发送通知到相应的设备时,必须包含对应的 device token。APNs 经过 device token 来确保通知发送到对应设备的对应app中。
APNs 发行新 device token 的缘由有:
用户安装你的app到新设备上
用户经过备份恢复设备
用户重装系统后
其它系统层面的事件
因此,app在启动的时候必须请求 device token,参阅 APNs 到设备之间的链接信任 和 device token,看代码实例详见 推送注册请求
注意:为了保护用户隐私,不要用 device token 来标识用户
服务器与APNs之间有两种方式实现链接信任
基于 Token 的服务器与 APNs 之间的信任 服务器能够根据 基于HTTP/2 的API 用JSON web tokens (JWT) 来实现与 APNs 之间的链接信任。这这个模式下,你须要提供一个公共密钥给 Apple。服务器须要用该密钥来生成并添加到 JWT 服务器验证 token。 服务器发出的每一个推送请求必须包含该 token。
你就能用简单的基于token的链接,来实如今你开发者账户中的全部应用的推送请求。
服务器向 APNs 发出的每一个推送请求,都会收到 APNs 的 HTTP/2 反馈。
基于证书的服务器与 APNs 之间的信任 服务器也能够经过惟一的证书来实现链接信任。服务器证书能够从开发者账户中获取到,基于你 app 的惟一的证书。而后就可使用证书来实现推送请求了。
重要
为实现与 APNs 之间基于 HTTP/2的 SSL 链接,你的服务器中必须包含 GeoTrust Gloabl CA 做为根证书。若是你的服务器运行的是 macOS,这个根证书在 keychain 中。其它系统的服务器则就我的状况来安装。你能够从 GeoTrust Root Certificates 网站下载,也能够点这里直接下载证书。
Apple Push Notification Authentication Key (Sandbox & Production)
你须要在你的[开发者账户][]中进行配置,具体操做看 生成惟一的服务器Token
这个证书有如下特性:
一个证书能够用于向全部包含在账户下的 app 发送推送。一样可用于 voiceover-Internet Protocol(VoIP)。即便在你的app处于后台运行时,APNs 也会向app发送这个证书。详情参见APNs 服务器证书,在开发中的能耗指导查看关于Voice Over IP(VoIP)最好的应用的说明
发送推送请求时,必须在基于 JWT 链接中包含该证书
认证证书永不失效,但你能够随时经过[开发者账户][]从新获取,从新获取后旧的证书将不能再使用
下图为: 用 HTTP/2 在服务器与 APNs 之间创建信任链接,用 JWT 向 APNs 发送推送请求
如图所示,工做流程是这样的:
服务器向 APNs 请求基于 TLS(transport layer security)的安全链接请求
APNs 向服务器发送认证证书,到这里,服务器与 APNs 之间的链接已经创建,此时能够发送推送请求
服务器须要发送的每一个推送请求必须包含 JWT 认证 token
APNs 向服务器发送 HTTP/2 回执 参见HTTP/2
基于证书的服务器链接只支持特定的某一个应用。证书须要在你的服务器上根据你的应用 bundle 提早生成,具体参见 生成一个惟一的通往APNs 的 SSL 链接证书。根据你生成的证书的不一样,信任的链接也能够推送一些与你app相关的一些东西,如 apple watch 的并发和 VoIP (voice-over-Internet Protocol)。APNs 会传送推送这些,即便设备仅在后台运行。查阅与 APNs 沟通来获取更多知识,在开发中的能耗指导查看关于Voice Over IP(VoIP)最好的应用的说明。
在基于证书的信任链接中,APNs 会持有一个废止的证书列表,若是服务器的证书在这个列表中,APNs 会废止与服务器的信任链接(也就是说 APNs 会拒绝服务器的请求)
该链接方式的过程是这样的:
服务器向 APNs 发出 TLS 链接请求
APNs 把证书发给服务器
服务器须要把你以前从[开发者账户][]中生成的证书发给 APNs,具体参见生成一个惟一的通往APNs 的 SSL 链接证书
APNs 验证服务器提供的证书是否正确,若是正确,则肯定服务器与 APNs 的信任链接。此时服务器能够向 APNs 发送推送请求了。
APNs 与每一个设备之间的链接是自动创建的,这个过程当中,不须要你的 app 作什么。
每一个设备都有一个加密的证书和私有密钥,在设备激活的时候生成,并保存在设备的 keychain 中,在设备激活的时候,APNs 根据设备的证书和密钥验证并受权与设备之间的链接。
过程是这样的:
设备向 APNs 发送 TLS 链接请求,信任链接设置开始
APNs 回执 APNs 证书到设备上
设备操做系统验证接收到的 APNs 证书,并向 APNs 发送本身的设备证书
APNs 验证设备发来证书,若是正确,信任链接创建
当设备与 APNs 之间的信任链接创建以后,此时设备能够向 APNs 申请特定 app 的 device-token,具体参阅 配置远程推送支持 的注册接收远程推送
章节。
在收到 device token 以后,app 必须向其服务器发送接收到的 device token。由于服务器以后向 APNs 发送推送请求时须要用到 device token,代码请参阅 配置远程推送支持
设备激活申请 device token,和 APNs 新生成一个 device token 的过程是同样的,如图:
过程:
app 向 APNs 申请远程推送请求,若是设备已经注册了远程推送请求,而且特定 app 的 device token 并无变化,则 APNs 会返回已经存在的 device token 到设备上,跳转到步骤4
当一个新的设备须要注册推送请求时,APNs 根据接收到的设备证书来生成一个 device token,并回执给设备
设备系统把接收到的 device token 传给 app 并调用 AppDelegate 方法 application:didRegisterForRemoteNotificationWithDeviceToken:
设备接收到 device token 以后,须要把它按二进制或十六进制的格式发给你的服务器,服务器才能用该 device token 来发送推送请求
重要
APNs 提供的 device token 的长度不定,不要强行解码其大小
当服务器向 APNs 发送推送请求时,请求中包含中标识惟一设备惟一 app 的 device token,这个过程就是下图中 Token, Payload
过程。APNs 解密 device token 确保推送请求的目标。若是请求的发送者和接收者都合法,APNs 向设备发送请求的推送信息。
在设备接收到 APNs 发来的推送以后,操做系统会把通知递送给相应的 app。
APNs 可用于发布在 iOS 应用商店,tvOS 应用商店, macOS 应用商店中的应用,和企业应用。
你的 app 须要编写支持推送的功能。若是你是以团队合做的形式开发,那么大多数配置的过程都由管理来实现。由于须要用到开发者账户。
想查看更多关于如何配置推送的知识,参阅 配置远程推送通知