APNS 学习总结（一）

APNs Overview

Apple Push Notification service (APNs) 在初始化加载时，你的app会通过用户的设备和apns创建一个可靠和加密的ip连接。后面apns就会使用这个长链接。如果notification过来了而app没有运行，设备就会接收通知并且会在适当时机将通知投递出来。

除了apns和你的app，你也必须配置你自己的server来产生这些notifications。你的server，被看作provider，有以下的任务：

• 他负责接收device tokens和你app发来的有用的数据
  

• 他确定什么时候远程notifications需要被发送到设备上
  

• 他负责将notification数据和apns链接
  

对每一个远程推送，你的provider：

1.  构造一个json字典
   

2. 将device token和payload附加给一个HTTP/2请求
   

3. Sends the request to APNs over a persistent and secure channel that uses the HTTP/2 network protocol.
   

The Path of a Remote Notification

你的provider负责引发和你app相关的远程通知。当你决定要发送一条通知的时候，你的provider会打包notification data到json字典中，然后投递到你的设备。你再将他打包进你的http／2请求中，这个请求包含device token和其它用于投递通知的信息。然后provider把这个请求发送给apns。

Figure 6-1Delivering a remote notification from a provider to an app

每个请求中所包含的device token代表了要接收通知的设备标识。apns使用device token来作为特定app并且和设备绑定。他也使用device token来认证发送到设备上的远程推送。每次你的app在设备上运行时，会从apns来请求这个token并且转发到你的provider。你的provider存储这个token并且当发送特定的通知到你的app和设备时使用这个token。token时持久的，只有在设备数据和设置被清除的时候才会改变。只有apns可以解码并且读取这个device token。

Figure 6-2 depicts the sort of virtual network that APNs enables among multiple providers and devices. To handle the notification load for your apps, you would typically employ multiple providers, each one with its own persistent and secure connection to APNs. Each provider can then route notifications to any device for which it has a valid device token.

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

Quality of Service, Store-and-Forward, and Coalesced Notifications

apns包含一个默认的Qos 来实行存储并转发的功能。如果apns尝试投递一个通知并且设备离线了，apns会将notiication存储一定的时间并且当设备再次可用的时候就再重新投递。这个机制只会为每一个设备和app存储最近的notification。如果设备离线，新来的通知会导致之前的通知被忽略掉。如果一个设备长期离线，那么所有存储的通知都会被忽略掉。

为了允许类似通知的合并，你可以在推送请求中添加一个折叠标识。通常的，当设备在线时，每一个你发送的通知都会投递到设备上。但是，当一个apns-collapse-id key 在你的request header中存在时，apns 就会将key相同的通知合并在一起。例如，一个新的设备将同样的标题发送了两次，这样这些通知就会使用同一个合并identifier。然后apns会将两个请求合并为一个notification投递给设备。

Security Architecture

为了确保安全通信，apns serers采用了链接认证，认证机构认证和用密码编写的keys（包括private和public）来验证链接。apns在providers和设备中间使用两层信任保护：连接trust和设备token trust。

连接trust建立apns和authorized provider之间的，被apple所批准的投递通知的公司所拥有。你必须按照步骤确保在你的provider servers和apns之间存在connection trust。apns也在各个设置之间使用connection trust来确保设备的合法化。同设备的连接trust自动被apns所掌控。

device token trust确保notifications 只能在合法的起止点进行发送。一个device token时一个被分配给特定设备特定app的唯一的标识。每一个app实例在注册apns时都会收到一个唯一的token。app必须把这个token共享给他的provider从而provider可以在同apns的通讯中包含这个token。这就保证了在通知被派发的时候只会发送到和app绑定的设备上。

Important

为了保护用户的隐私，不要使用device token来标识用户设备。当用户更新操作系统或者当设备数据和设置被抹掉后device token都会改变。因此，app应当在启动时总是获取当前的device token。

Provider-to-APNs Connection Trust

There are two schemes available for negotiating connection trust between your provider servers and Apple Push Notification service:

• Token-based connection trust 一个provider正在使用基于HTTP/2的api的可以使用ingjson web tokens （jwt）来验证provider和apns之间的链接。provider不需要certificate－plus－private key来创建连接。取而代之的，你提供一个由apple保留的public key和一个自己保留的private key。你的provider会使用你的private key来生成并且签名JWTauthentication tokens.你的每一个push请求都必须包含一个认证token
  
• Certificate-based connection trust 一个provider能够，作为一种选择，采取一个唯一的provider certificate和私有加密的key。这个provider认证，当你在你的在线developer account创建你的push service服务时候会提供。bunde id和你的apps来进行绑定关联。
  

Token-Based Provider-to-APNs Trust

Figure 6-3 illustrates using the HTTP/2-based APNs provider API to establish trust, and using JWT provider authentication tokens for sending notifications. It works as follows:

1. 你的provider使用tls请求一个安全连接。
   

2.  apns给你的provider一个apns认证。此时，信任连接已经建立起来并且你的provider server 可以发送远程通知到apns了
   

3.  每一个你的provider发送的通知必须通过jwt 认证token相随。
   

4. apns回应每一个push，
   

   For specifics on the responses your provider can receive for this step, seeHTTP/2 Response from APNs.

Figure 6-3Establishing and using token-based connection trust between a provider and APNs

Important

To establish TLS sessions with APNs, you must ensure that a GeoTrust Global CA root certificate is installed on each of your providers. If a provider is running macOS, this root certificate is in the keychain by default. On other systems, this certificate might require explicit installation. You can download this certificate from theGeoTrust Root Certificates website.

The HTTP/2-based provider connection is valid for delivery to one specific app, identified by the topic (the app bundle ID) specified in the certificate. Depending on how you configure and provision your APNs Transport Layer Security (TLS) certificate, the trusted connection can also be valid for delivery of remote notifications to other items associated with your app, including Apple Watch complications and voice-over-Internet Protocol (VoIP) services. APNs delivers these notifications even when those items are running in the background. See Communicating with APNs for details, and see Voice Over IP (VoIP) Best Practices in Energy Efficiency Guide for iOS Apps.

APNs maintains a certificate revocation list; if a provider’s certificate is on the revocation list, APNs can revoke provider trust (that is, APNs can refuse the TLS initiation connection).

Certificate-Based Provider-to-APNs Trust

Figure 6-4 illustrates the use of an Apple-issued certificate to establish trust between a provider and APNs. UnlikeFigure 6-3, this figure does not show a notification push itself, but stops at the establishment of a Transport Layer Security (TLS) connection. In the certificate-based trust scheme, pushes are not authenticated but each push is validated.

Certificate-based provider-to-APNs trust works as follows:

1. Your provider asks for a secure connection with APNs using transport layer security (TLS), represented as the arrow labeled “TLS initiation” in the figure.

2. APNs then gives your provider an APNs certificate, represented by the next arrow in the figure (labeled “APNs certificate”), which your provider then validates.

3. Your provider must then send its Apple-provisioned provider certificate back to APNs, represented as the arrow labeled “Provider certificate.”

4. APNs then validates your provider certificate, thereby confirming that the connection request originated from a legitimate provider, and establishes your TLS connection.

   At this point, connection trust is established and your provider server is enabled to send push notifications to APNs.

Figure 6-4Establishing certificate-based connection trust between a provider and APNs

As with token-based trust, a certificate-based provider-to-APNs connection is valid for delivery to only one specific app. That app is identified by the topic (bundle ID) specified in the provider certificate.

APNs maintains a certificate revocation list; if a provider’s certificate is on the revocation list, APNs can revoke provider trust (that is, APNs can refuse the TLS initiation connection).

APNs-to-Device Connection Trust

Trust between APNs and each device is established automatically by the device’s operating system upon initial device activation (and without participation by your app), as described in this section.

Each device has a cryptographic certificate and a private cryptographic key, obtained at initial device activation and stored in the device’s keychain. During activation, APNs uses the certificate and key to validate the device’s connection using peer-to-peer authentication, as shown in Figure 6-5.

Trust negotiation begins when the device operating system initiates a TLS connection with APNs, which returns its server certificate. The operating system validates this certificate and then sends the device certificate. Finally, APNs validates the device certificate, establishing trust.

Figure 6-5Establishing connection trust between a device and APNs

With a TLS connection established between the device and APNs, APNs can then provide an app-specific device token to each app that registers for remote notifications.

Device Token Generation and Dispersal

Each time an app launches, it must register with the system to receive remote notifications as described inRegistering to Receive Remote Notifications. Upon successful registration, the app receives a device token for its provider to use when sending notifications to the device.

When a new device token is needed, APNs generates that token 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 inFigure 6-6. The system delivers the device token back to your app as anNSData 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 6-6Managing the device token

Important

APNs device tokens are of variable length. Do not hard-code their size.

Device Token Trust for Notifications

Every notification that your provider sends to APNs must be accompanied by a device token identifying the recipient device. APNs decrypts the device 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 inFigure 6-7.

Figure 6-7Identifying a device using the device token

Provisioning Procedures

APNs is available to apps distributed through the iOS App Store, tvOS App Store, and Mac App Store, as well as to enterprise apps. Your app must be provisioned and code signed to use APNs. If you are working in a company, most of these configuration steps can be performed only by a team agent or admin.

For information on how to configure your push notification support, search for “Configure push notifications” inXcode help.