Apple Push Notification Service 苹果推送通知服务 - 翻译

Apple Push Notification Service 苹果推送通知服务

Apple Push Notification service (APNs) is the centerpiece of the remote notifications feature. It is a robust and highly efficient service for propagating information to iOS (and, indirectly, watchOS), tvOS, and OS X devices. Each device establishes an accredited and encrypted IP connection with APNs and receives notifications over this persistent connection. If a notification for an app arrives when that app is not running, the device alerts the user that the app has data waiting for it.

苹果推送通知服务 (简称APNs) 是实现远程通知功能的主要内容. 它是一项将信息发送至 iOS 设备 (间接至 watchOS ), tvOS, OS X 设备强大且高效的服务. 每个设备都与 APNs 建立了一个可信任的加密的 IP 链接, 并使用这个持续链接来接受通知. 如果一个 app 有新的通知到达而这个 app 没有运行时, 设备会弹出提示框来告诉用户这个 app 有新的消息到达了.

You provide your own server to generate the remote notifications for your users. This server, known as the provider, gathers data for your users and decides when a notification needs to be sent. For each notification, the provider generates the notification payload and attaches that payload to an HTTP/2 request, which it then sends to APNs using a persistent and secure channel using the HTTP/2 multiplex protocol. Upon receipt of your request, APNs handles the delivery of your notification payload to your app on the user’s device.

你提供自己的服务器为你的用户生成远程通知. 这个服务器被称为提供者, 为您的用户收集数据并在需要时发送通知. 每个通知, 提供者生成通知的信息和通知的内容并使用 HTTP 2 发送请求, 然后发送到使用 HTTP 2 复用协议的具有持续和安全连接的 APN. 一旦收到您的请求, APNs 负责将您的通知信息交付到您指定设备上的 app 应用中.  

For information about the format of the requests that you send to APNs, and the responses and errors you can receive, see APNs Provider API. For information about how to implement notification support in your app, see Registering, Scheduling, and Handling User Notifications.

关于发送的 APNs 的要求, 和可以接受响应的和错误的格式信息, 请参阅 APN 提供的 API. 

关于如何在您的 app 内实现远程通知, 请参阅 注册, 安排及处理用户通知

The Path of a Remote Notification 远程通知流程

Apple Push Notification service transports and routes remote notifications for your apps from your provider to each user’s device. Figure 3-1 shows the path each notification takes. When your provider determines that a notification is needed, you send the notification and a device token to the APNs servers. The APNs servers handle the routing of that notification to the correct user device, and the operating system handles the deliver of the notification to your client app. 

APNs 在你的服务器和用户设备之间将远程通知传递到您的 apps. 图 3-1 显示了每个通知的流程. 当你的服务器要发送一条通知时, 你发送这个通知和一个 device token 到 APNs 服务器. APNs 服务器选择适当的路由将每条通知发送到用户设备, 操作系统把每条通知发送到您指定的 app 上.

Figure 3-1  Pushing a remote notification from a provider to a client app

The device token you provide to the server is analogous to a phone number; it contains information that enables APNs to locate the device on which your client app is installed. APNs also uses it to authenticate the routing of a notification. The device token is provided to you by your client app, which receives the token after registering itself with the remote notification service. 

Device token 类似于一个手机号; 它的信息使 APNs 能够定位到安装了您的 app 的手机. APNs 也使用它来验证远程通知的路由 (路径). 您的每个 app 在注册了远程通知服务后都会收到一个 device token. 

The notification payload is a JSON dictionary containing the data you want sent to the device. The payload contains information about how you want to notify the user, such as using an alert, badge or sound. It can also contain custom data that you define.

通知报文是一个 JSON 字典, 里面含有您想要发送到设备上的信息. 通知报文包含有您希望如何通知用户, 如使用提示框, 小角标以及声音. 还可包含自定义的数据.

Figure 3-2 shows a more realistic depiction of the virtual network APNs makes possible among providers and devices. The device-facing and provider-facing sides of APNs both have multiple points of connection; on the provider-facing side, these are called gateways. There are typically multiple providers, each making one or more persistent and secure connections with APNs through these gateways. And these providers are sending notifications through APNs to many devices on which their client apps are installed.

图 3-2 展示了在虚拟网络中 APNs 将消息从您的服务器发送到设备的真实流程. APNs 在设备端和服务器端都拥有多点链接; 在服务器端, 叫做网关. 通常有很多服务器, 其中每个服务器都会通过网关与 APNs 建立一个或多个持续和安全的链接. 然后这些服务器通过 APNs 对安装了它们 app 的设备发送远程通知.

Figure 3-2  Pushing remote notifications from multiple providers to multiple devices

For information about getting the device token, see Token Generation and Dispersal. For information about the notification payload, see The Remote Notification Payload.

关于获取 device token 的更多消息, 请参阅 Token 的产生和散布;

关于通知报文的信息, 请参阅 远程通知报文

Quality of Service 服务质量

Apple Push Notification service includes a default Quality of Service (QoS) component that performs a store-and-forward function. If APNs attempts to deliver a notification but the device is offline, the notification is stored for a limited period of time, and delivered to the device when it becomes available. Only one recent notification for a particular app is stored. If multiple notifications are sent while the device is offline, the new notification causes the prior notification to be discarded. This behavior of keeping only the newest notification is referred to as coalescing notifications.

APNs 含有一个默认的质量服务 (QoS) 组件来执行存储和转发的功能. 当 APNs 尝试为一个暂未连接网络的设备发送一条通知时, 这条通知会在有限的时间内保存起来, 在设备联网时发送到设备. 对于每个 app 只能保存一条最近的通知. 当多条通知发送到未联网的设备时, 最新的通知会使之前的通知失效. 只保留最新通知的特性被称之为聚合性通知.

If the device remains offline for a long time, any notifications that were being stored for it are discarded.

如果设备离线时间过长, 被储存的所有通知都将失效.

Security Architecture 安全体系

To ensure secure communication, APNs regulates the entry points between providers and devices using two different levels of trust: connection trust and token trust. 

为保证安全通信, APNs 在服务器和设备的接入点中规定了俩种不同级别的可信方式, 可信链接和可信 token.   

Connection trust establishes certainty that APNs is connected to an authorized provider for whom Apple has agreed to deliver notifications. APNs also uses connection trust with the device to ensure the legitimacy of that device. Connection trust with the device is handled automatically by APNs but you must take steps to ensure connection trust exists between your provider and APNs.

可信连接表示 APNs 必须与经过 Apple 授权可以传递通知的服务器连接. APNs 也使用可信链接确保设备的合法性. APNs 会自动处理与设备的可信链接, 但你必须使用指定步骤确保 APNs 与服务器之间使用了可信链接.

Token trust ensures that notifications are routed only between legitimate start and end points. Token trust involves the use of a device token, which is an opaque identifier assigned to a specific app on a specific device. Each app instance receives its unique token when it registers with APNs and must share this token with its provider. Thereafter, the token must accompany each notification sent by your provider. Providing the token ensures that the notification is delivered only to the app/device combination for which it is intended.

Token 信任确保通知只会从合法的开始发送到合法的结束点. Token 信任涉及 device token 的使用, device token 标示着特定设备上的特定应用. 每个 app 在向 APNs 注册时都会收到一个 device token, 并将它发送至服务器. 之后, 服务器每次向 APNs 发送推送时必须包含 device token. 确保指定的通知信息发送到指定的应用/设备中.

Note: A device token is not a unique ID that you can use to identify a device. Device tokens can change after updating the operating system on a device. As a result, apps should send their device token 

注: Device token 不是设备的唯一标识. Device token 会在系统更新后改变, 因此, 每次系统更新后 apps 应该再次发送 device token 至服务器. 译者注, 在 app 内嵌入用户信息追溯功能, 当操作系统更新后, 发送新的 device token 至服务器;

APNs servers also have the necessary certificates, CA certificates, and cryptographic keys (private and public) for validating connections and the identities of providers and devices. 

APNs 服务器还有一个必要的 CA 证书, 和用来验证服务器与设备的链接有效的密钥(公钥和私钥).

Provider-to-APNs Connection Trust 服务器-to-APNs 信任链接

Each provider must have a unique provider certificate and private cryptographic key, which are used to validate the provider’s connection with APNs. The provider certificate (which is provisioned by Apple) identifies the topics supported by the provider. (A topic is the bundle ID associated with one of your apps.) 

每个服务器必须具有唯一的远程推送证书和私有密钥, 用于验证服务器与 APNs 之间的链接. 远程推送证书 (由 Apple 公司提供) 其中标识服务器提供的主题, (主题是您 app 的 bundle ID.)

Your provider establishes connection trust with APNs through TLS peer-to-peer authentication. After the TLS connection is initiated, you get the server certificate from APNs and validate that certificate on your end. Then you send your provider certificate to APNs, which validates that certificate on its end. After this procedure is complete, a secure TLS connection is established; APNs is now satisfied that the connection has been made by a legitimate provider.

Figure 3-3  Establishing connection trust between a provider and APNs

The HTTP/2 provider connection is valid for delivery to one specific app, identified by the topic (bundle ID) specified in the certificate. Depending on how you configure and provision your APNs SSL certificate, the connection can also be valid for delivery of remote notifications to any Apple Watch complications or backgrounded VoIP services associated with that primary app. See APNs Provider API for details. APNs also maintains a certificate revocation list; if a provider’s certificate is on this list, APNs can revoke provider trust (that is, refuse the connection). 

APNs-to-Device Connection Trust

Each device has a device certificate and private cryptographic key, which are used to validate the device’s connection with APNs. The device obtains its certificate and key at device activation time and stores them in the keychain. 

You do not have to do anything to establish connection trust between APNs and a device. APNs establishes the identity of a connecting device through TLS peer-to-peer authentication. In the course of this procedure, the device initiates a TLS connection with APNs, which returns its server certificate. The device validates this certificate and then sends its device certificate to APNs, which validates that certificate. 

Figure 3-4  Establishing connection trust between a device and APNs

Token Generation and Dispersal

An app must register with the system to receive remote notifications, as described in Registering for Remote Notifications. Upon receiving a registration request, the system forwards the request to APNs, which generates a unique device token, for the app, using information contained in the device’s certificate. It then encrypts the token using a token key and returns it to the device, as shown in Figure 3-5. The system delivers the device token to your app as an NSData object. Upon receiving this token, your app must forward it to your provider in either binary or hexadecimal format. Your provider cannot send notifications to the device without this token.

Figure 3-5  Managing the device token

Important: APNs device tokens are of variable length. Do not hardcode their size.

Figure 3-6 illustrates the token generation and dispersal sequence, but in addition shows the path of the token as it is returned by APNs and subsequently forwarded to your custom provider.

Figure 3-6  Sharing the device token

Token Trust (Notification)

Every notification that your provider sends to APNs must be accompanied by the device token associated of the device for which the notification is intended. APNs decrypts the token using its token key to ensure the validity of the notification source—that is, your provider. APNs uses the device ID contained in the device token to determine the identity of the target device. It then sends the notification to that device, as shown in Figure 3-7. 

Figure 3-7  Identifying a device using the device token