系统推送的集成（十二） —— 本地和远程通知编程指南之Legacy信息 - 二进制Provider API（一）

版本记录

版本号	时间
V1.0	2018.07.15

前言

我们做APP很多时候都需要推送功能，以直播为例，如果你关注的主播开播了，那么就需要向关注这个主播的人发送开播通知，提醒用户去看播，这个只是一个小的方面，具体应用根据公司的业务逻辑而定。前面已经花了很多篇幅介绍了极光推送，其实极光推送无非就是将我们客户端和服务端做的很多东西封装了一下，节省了我们很多处理逻辑和流程，这一篇开始，我们就利用系统的原生推送类结合工程实践说一下系统推送的集成，希望我的讲解能让大家很清楚的理解它。感兴趣的可以看上面几篇。
1. 系统推送的集成（一） —— 基本集成流程（一）
2. 系统推送的集成（二） —— 推送遇到的几个坑之BadDeviceToken问题（一）
3. 系统推送的集成（三） —— 本地和远程通知编程指南之你的App的通知 - 本地和远程通知概览（一）
4. 系统推送的集成（四） —— 本地和远程通知编程指南之你的App的通知 - 管理您的应用程序的通知支持（二）
5. 系统推送的集成（五） —— 本地和远程通知编程指南之你的App的通知 - 调度和处理本地通知（三）
6. 系统推送的集成（六） —— 本地和远程通知编程指南之你的App的通知 - 配置远程通知支持（四）
7. 系统推送的集成（七） —— 本地和远程通知编程指南之你的App的通知 - 修改和显示通知（五）
8. 系统推送的集成（八） —— 本地和远程通知编程指南之苹果推送通知服务APNs - APNs概览（一）
9. 系统推送的集成（九） —— 本地和远程通知编程指南之苹果推送通知服务APNs - 创建远程通知Payload（二）
10. 系统推送的集成（十） —— 本地和远程通知编程指南之苹果推送通知服务APNs - 与APNs通信（三）
11. 系统推送的集成（十一） —— 本地和远程通知编程指南之苹果推送通知服务APNs - Payload Key参考（四）

Binary Provider API - 二进制Provider API

legacy二进制接口要求provider服务器使用本附录中描述的二进制API。 所有开发人员都应将其远程通知provider服务器迁移到与Communicating with APNs中描述的功能更强大且更高效的基于HTTP / 2的API。

---

General Provider Requirements - 基本Provider要求

作为provider，您可以通过二进制接口与Apple Push Notification服务进行通信。 该接口对于providers是一个高速，高容量接口；它使用流式TCP套接字设计和二进制内容。 二进制接口是异步的。 支持该接口，但如果可能，您应该最好使用APNs API。

生产环境的二进制接口可通过gateway.push.apple.com，port 2195获得; 开发环境的二进制接口可通过gateway.sandbox.push.apple.com，port 2195获得。

对于每个接口，使用TLS（或SSL）建立安全通信通道。 这些连接所需的SSL证书是从您的开发者帐户获得的。 （有关详细信息，请参阅APNs Overview。），要建立可信的provider身份，请在连接时使用对等身份验证将此证书提供给APNs。

注意：要与APNs建立TLS会话，必须在provider的服务器上安装Entrust Secure CA根证书。 如果服务器正在运行macOS，则此根证书已存在于钥匙串中。 在其他系统上，证书可能不可用。 您可以从Entrust SSL Certificates website下载此证书。

作为provider，您负责远程通知的以下方面：

• 您必须合成通知payload（请参阅Creating the Remote Notification Payload）。

• 您有责任提供要在应用程序图标上显示的徽章编号。

• 定期与反馈服务连接，并获取反复报告失败传递尝试的那些设备的当前列表。然后停止向与这些应用关联的设备发送通知。有关更多信息，请参阅The Feedback Service。

如果您打算支持多种语言的通知消息，但不使用aps有效负载字典的loc-key和loc-args属性进行客户端提取本地化警报字符串，则需要本地化服务器端警报消息的文本。为此，您需要从客户端应用程序中找出当前的语言首选项。 Supplying the User’s Language Preference to Your Server讲述了获取此信息的方法。有关loc-key和loc-args属性的信息，请参阅 Creating the Remote Notification Payload。

---

The Binary Interface and Notification Format - 二进制接口和通知格式

二进制接口使用普通的TCP套接字来实现流式传输的二进制内容。 为了获得最佳性能，可以通过接口批量或使用TCP / IP Nagle算法在单个传输中批量多个通知。 通知格式如图A-1所示。

注意：所有数据都按网络顺序指定，即大端。

通知格式的顶层由以下组成，按照顺序排列：

Table A-1 Top-level fields for remote notifications

帧数据由一系列项组成。 每个项按以下顺序组成：

Table A-2 Fields for remote notification frames

项目及其标识符如下：

Table A-3 Item identifiers for remote notifications

如果您发送APNs接受的通知，则不会返回任何内容。

如果发送格式错误或无法识别的通知，APNs将返回错误响应数据包并关闭连接。 在使用相同连接的格式错误通知后发送的任何通知都将被丢弃，并且必须重新发送。 图A-2显示了错误响应数据包的格式。

Figure A-2 Format of error-response packet

数据包的命令值为8，后跟一个字节的状态代码和格式错误的通知的通知标识符。 表A-4列出了可能的状态代码及其含义。

Table A-4 Codes in error-response packet

状态代码10表示APNs服务器关闭连接（例如，执行维护）。 错误响应中的通知标识符指示已成功发送的上一个通知。 您发送的任何通知被丢弃后，必须重新发送。 收到此状态代码后，请停止使用此连接并打开新连接。

请注意，生产环境中的设备令牌和开发环境中的设备令牌不是相同的值。

---

The Feedback Service - 反馈服务

Apple推送通知服务包括反馈服务，为您提供有关失败的远程通知的信息。如果由于设备上不存在预期的应用程序而无法传递远程通知，则反馈服务会将该设备的令牌添加到其列表中。在传递之前过期的远程通知不被视为传递失败，并且不会影响反馈服务。通过使用此信息来停止发送无法传递的远程通知，可以减少不必要的消息开销并提高整体系统性能。

每天查询反馈服务以获取设备令牌列表。使用时间戳来验证自生成反馈条目以来尚未重新注册设备令牌。对于尚未重新注册的每个设备，请停止发送通知。 APNs监控providers在检查反馈服务方面的努力，并避免向设备上不存在的应用程序发送远程通知。

注意：反馈服务为每个推送主题维护单独的列表。 如果您有多个应用，则必须使用相应的证书为每个应用连接一次反馈服务，以便接收所有反馈。

反馈服务具有类似于用于发送远程通知的接口的二进制接口。 您可以通过端口2196上的feedback.push.apple.com访问生产反馈服务，并通过端口2196上的feedback.sandbox.push.apple.com访问开发反馈服务。与远程通知的二进制接口一样，使用TLS（或SSL） ）建立安全的通信渠道。 在用于发送通知时，使用相同的SSL证书连接到反馈服务。 要建立可信的提供者身份，请在连接时使用对等身份验证将此证书提供给APNs。

连接后，立即开始传输；您不需要向APNs发送任何命令。 从反馈服务中读取流，直到没有更多数据要读取。 收到的数据采用以下格式的元组：

Figure A-3 Binary format of a feedback tuple

Table A-5 Table

阅读后，反馈服务列表将被清除。 每次连接到反馈服务时，它返回的信息仅列出自上次连接以来发生的故障。

后记

本篇主要讲述了二进制Provider API，感兴趣的给个赞或者关注~~~~