Apple Push Notification Service
苹果推送服务
Apple Push Notification service (APNs for short) is the centerpiece of the remote notifications feature. It is a robust and highly efficient service for propagating information to iOS and OS X devices. Each device establishes an accredited and encrypted IP connection with the service 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和OS X设备传播信息的服务。每一台设备通过这种服务建立了一个认证并加密的IP链接并且通过这种持续的连接接收通知。如果一个应用的通知到达时这个应用并没有在运行，设备就会告知用户应用这个app有了一些待处理的数据。
Software developers (“providers”) originate the notifications in their server software. The provider connects with APNs through a persistent and secure channel while monitoring incoming data intended for their client apps. When new data for an app arrives, the provider prepares and sends a notification through the channel to APNs, which pushes the notification to the target device.
软件开发者（供应者）在他们的服务软件组织这种通知。供应者通过一个持续而又安全的渠道连接APNs并且监视即将到达他们客户应用的数据。当一个应用的新数据到来时，供应者通过这个渠道准备好并发送一个通知给APNs，而正是APNs把通知发送给了目标设备。
In addition to being a simple but efficient and high-capacity transport service, APNs includes a default quality-of-service component that provides store-and-forward capabilities. See Quality of Service
Provider Communication with Apple Push Notification Service and Scheduling, Registering, and Handling Notifications
APNs除了是一种简单，高效，高容量的传输服务之外，还包括一种默认的Qos组件来提供存储并转发的能力。请看Quality of Service来获取更新信息。
提供者与APNs的交流和调度，注册和处理通知两个章节分别讨论了针对提供者（即服务端）和iOS应用的具体实施要求。
A Remote Notification and Its Path
Apple Push Notification service transports and routes a remote notification from a given provider to a given device. A notification is a short message consisting of two major pieces of data: the device token and the payload. The device token is analogous to a phone number; it contains information that enables APNs to locate the device on which the client app is installed. APNs also uses it to authenticate the routing of a notification. The payload is a JSON-defined property list that specifies how the user of an app on a device is to be alerted.
APNs服务传输并发送一个来自特定服务器的远程通知给一台特定的设备。通知就是一个简短的信息，这条信息包含两块主要的数据：设备token和有效载荷。设备号类似于电话号码，它包含了能够促使APNs定位到安装了客户端应用的设备。APNs 还使用它来认证一个通知的发送。payload就是一个JSON格式的属性列表，它详细描述了某台设备上的应用的使用者将被如何被通知。
Note: For more information about the device token, see Security Architecture; for further information about the notification payload, seeThe Notification Payload.
注意：更多关于设备号的信息，请看安全工程这一章节，更多关于通知payload，请看通知payload
The remote-notification data flows in one direction. The provider composes a notification package that includes the device token for a client app and the payload. The provider sends the notification to APNs which in turn pushes the notification to the device.
When a provider authenticates itself to APNs, it sends its topic to the APNs server, which identifies the app for which it’s providing data. The topic is currently the bundle identifier of the target app.
远程通知的数据通过一个方向流入。服务端合成一个通知包，这个包包含了客服端应用的设备号和payload。服务端发送通知给APNs而APNs转而把通知发送给设备。当服务端向APNs认证时，它发送他的主题给APNs服务器，APNs据此识别它即将提供数据的应用。现在的主题指的就是目标应用的bundle identifier.
Figure 3-1 Pushing a remote notification from a provider to a client app
图标3-1 从服务端向客户端推送一个远程通知
服务端 - APNs - 设备 - 应用
Figure 3-1 is a greatly simplified 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. Figure 3-2 is a slightly more realistic depiction.
图3-1是一个关于虚拟网络APNs怎样使服务端和设备之间的联络成为可能的极其简明的描述。APNs的面向设备和面向服务端都有多点连接。服务端方面，被称为网关。这些是典型的多点服务端，每一个都通过网关和APNs建立一个或者多个持续安全的连接。并且这些服务端通过APNs向众多安装了他们的客户端应用的设备发送通知。图表3-2是一个更实际一些的描述。
Figure 3-2 Pushing remote notifications from multiple providers to multiple devices
图表3-2 从多个服务端向多个设备推送远程通知
The feedback service gives providers information about notifications that could not be delivered—for example, because the target app is no longer installed on that device. For more information, see The Feedback Service.
反馈服务提供给服务端关于哪些通知不能被传输的信息-例如，目标应用已经不再在设别上安装了。更多信息，请看反馈服务。
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, each new notification causes the prior notification to be discarded. This behavior of keeping only the newest notification is referred to as coalescing
If the device remains offline for a long time, any notifications that were being stored for it are discarded.
苹果推送服务器包含了具有存储和转发功能的Qos组件。
如果APNs试图传递信息但是设备不在线，信息在一段有限的时间内会被存储，并且当设备在线时传送给设备。
只有特定应用的最新一条信息会被存储。如果设备不在线时，有多个通知被发送，每一条新的通知会使前一条通知被丢弃。这种只保留最新通知的行为被称为合并通知。
如果设备很长一段时间都不在线，所有为它存储的通知都会被丢弃。
Security Architecture
To enable communication between a provider and a device, Apple Push Notification service must expose certain entry points to them. But then to ensure security, it must also regulate access to these entry points. For this purpose, APNs requires two different levels of trust for providers, devices, and their communications. These are known as connection trust and token trust.
为了使服务端和设备之间可以联系，APNs服务器必须为他们提供特定的进入点。但是为了保证安全，它必须组织调节通往这些进入点的通道。因此，APNs对服务端，设备以及他们之间的交流要求两种不同级别的信任度。也就是连接信任和token信任。
Connection trust establishes certainty that, on one side, the APNs connection is with an authorized provider with whom Apple has agreed to deliver notifications. At the device side of the connection, APNs must validate that the connection is with a legitimate device.
连接信任一方面建立在，APNs的连接是和苹果已经同意发送通知的已授权的服务端的。在设备方面的连接，APNs必须验证连接是和一台合法的设备之间建立的。
After APNs has established trust at the entry points, it must then ensure that it conveys notifications to legitimate end points only. To do this, it must validate the routing of messages traveling through the transport; only the device that is the intended target of a notification should receive it.
APNs在进入点建立了信任之后，他还必须保证他只传达通知给合法的终端。为此，它必须验证通过传输过程中的路由，只有特定的目标设备才能够接收通知。
In APNs, assurance of accurate message routing—or
token trust
—is made possible through the device token. A device token is an opaque identifier of a device that APNs gives to the device when it first connects with it. The device shares the device token with its provider. Thereafter, this token accompanies each notification from the provider. It is the basis for establishing trust that the routing of a particular notification is legitimate.
在APNs中，准确的消息路由或者是token信任，是通过设备号保证实现的。设备号是APNs第一次与设备建立连接时它发送给设备的一个不透明的标识。设备将设备号告知服务端。此后，设备号伴随着服务端发出的每一条通知。它是对一条特定通知的路由建立信任的基础。
Note: A device token is not the same thing as the device UDID returned by the identifierForVendor or uniqueIdentifier property of UIDevice or any other similar properties such as the advertisingIdentifier property of ASIdentifierManager.
注意：设备号不同于identifierForVenfor产生的设备UDID，也不同于UIDevice的uniqueIdnetifier属性或者任何例如ASIdentifierManager的广告标识属性的类似属性。
The following sections discuss the requisite components for connection trust and token trust as well as the four procedures for establishing trust.
以下几个部分讨论关于连接信任，设备号信任以及建立信任的四个步骤的必要组件。
Service-to-Device Connection Trust
服务-设备之间的连接信任
APNs establishes the identity of a connecting device through TLS peer-to-peer authentication. (Note that the system takes care of this stage of connection trust; you do not need to implement anything yourself.) In the course of this procedure, a 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.
APNs通过TLS点对点的认证确定一台连接设备的身份。（注意系统负责该阶段的连接信任，你本身不需要做任何事情。）在这个过程期间，一台设备初始化了与APNs之间的TLS连接，APNs返回它的服务证书。设备验证这份证书并且给APNs发送它的设备证书，APNs验证它发送过来的证书。
Provider-to-Service Connection Trust
服务端到APNs的连接信任
Connection trust between a provider and APNs is also established through TLS peer-to-peer authentication. The procedure is similar to that described in Service-to-Device Connection Trust. The provider initiates a TLS connection, gets the server certificate from APNs, and validates that certificate. Then the provider sends its provider certificate to APNs, which validates it on its end. Once this procedure is complete, a secure TLS connection has been established; APNs is now satisfied that the connection has been made by a legitimate provider.
服务端和APNs之间的连接信任也是通过TLS点到点的认证来建立的。这个过程就类似于APNs和设备之间的连接信任。服务端初始化一个TLS连接，从APNs获取服务证书，并且验证这个证书。然后服务端把它的证书发送给APNs，APNs验证这个证书。一旦这个过程完成，一个安全的TLS连接就被建立起来了。APNs就会知道现在的连接是与一个合法的服务器建立的。
Note that provider connection is valid for delivery to only one specific app, identified by the topic (bundle ID) specified in the certificate. APNs also maintains a certificate revocation list; if a provider’s certificate is on this list, APNs may revoke provider trust (that is, refuse the connection).
注意服务端连接只对一个特定的app的传输是合法的，这个app是根据证书中指定的bundle ID来确定的。APNs也建立了一套证书废止列表。如果一个服务端证书在他的列表上，APNs可能会吊销服务端的信任（也就是说，拒绝连接）。
Token Generation and Dispersal
token的产生与消散
Apps must register to receive remote notifications; it typically does this right after it is installed on a device. (This procedure is described in Scheduling, Registering, and Handling Notifications .) The system receives the registration request from the app, connects with APNs, and forwards the request. APNs generates a device token using information contained in the unique device certificate. The device token contains an identifier of the device. It then encrypts the device token with a token key and returns it to the device.
应用必须注册才能收到远程推送。通常它只要在一台设备上安装就会这么做。（这个过程在Scheduling, Registering, and Handling Notifications.中介绍的）系统接收来自应用的注册请求，与APNs建立连接，并转发这个请求。APNs使用唯一的设备证书中的信息产生设备编号。设备号中包含设备的标识。然后它使用一个token key将设备号加密并返回给设备。
The device returns the device token to the requesting app as an
NSData object. The app must then deliver the device token to its provider in either binary or hexadecimal format. Figure 3-3 also illustrates the token generation and dispersal sequence, but in addition shows the role of the client app in furnishing its provider with the device token.
设备将设备号以NSData对象返回给请求token的应用。然后应用必须以二进制或者十六进制的格式将设备号传输给他的服务端。图表3-3也列举了设备号的产生与消散的流程，此外也展示了客户端应用在给他的服务端提供设备号的过程中扮演的角色。
Figure 3-3 Sharing the device token
图表3-3 共享设备号
The form of this phase of token trust ensures that only APNs generates the token which it will later honor, and it can assure itself that a token handed to it by a device is the same token that it previously provisioned for that particular device—and only for that device.
该阶段token信任建立的方式保证了只有APNs可以产生设备号，而这将非常有用。它可以保证，一台设备传递给他的设备号就是他之前提供给那台设备的，并且是那台设备唯一的token。
Token Trust (Notification)
token信任（通知）
After the system obtains a device token from APNs, as described in Token Generation and Dispersal , it must provide APNs with the token every time it connects with it. APNs decrypts the device token and validates that the token was generated for the connecting device. To validate, APNs ensures that the device identifier contained in the token matches the device identifier in the device certificate.
当系统从APNs获取一个设备号之后，就像在Token Generation and Dispersal中描述的，它每次跟APNs连接时都必须提供设备号。APNs将设备号解密并且验证设备号是由与他连接的设备产生的。为了验证，APNs会保证设备号中包含的设备标识与设备证书中的设备标识是匹配的。
Every notification that a provider sends to APNs for delivery to a device must be accompanied by the device token it obtained from an app on that device. APNs decrypts the token using the token key, thereby ensuring that the notification is valid. It then uses the device ID contained in the device token to determine the destination device for the notification.
每一条服务端通过APNs发送给设备的通知都必须伴随着从那台设备的应用上面获取的设备号。APNs使用token key来解密token，因此保证了通知的合法性。然后它使用在设备号中包含的设备ID来决定这条通知的目标设备。
Trust Components
信任组件
To support the security model for APNs, providers and devices must possess certain certificates, certificate authority (CA) certificates, or tokens.
为了支持APNs中的安全模型，服务端和设备必须具有某些证书，CA证书或者是token.
- Provider: Each provider requires a unique provider certificate and private cryptographic key for validating their connection with APNs. This certificate, provisioned by Apple, must identify the particular topic published by the provider; the topic is the bundle ID of the client app. For each notification, the provider must furnish APNs with a device token identifying the target device. The provider may optionally wish to validate the service it is connecting to using the public server certificate provided by the APNs server.
服务端：每一个服务端需要一个唯一的服务端证书和私有的秘钥来验证他们与APNs之间的连接。这个证书，是由苹果提供的，它必须能够鉴别出服务端发布的特定主题，这个特定的主题就是客户端应用的bundle ID.服务端发送给APNs的每一条通知，都带有能鉴别目标设备的设备号。服务端会希望使用APNs服务器提供的服务端证书来验证它正在连接的服务器。
- Device: The system uses the public server certificate passed to it by APNs to authenticate the service that it has connected to. It has a unique private key and certificate that it uses to authenticate itself to the service and establish the TLS connection. It obtains the device certificate and key during device activation and stores them in the keychain. The system also holds its particular device token, which it receives during the service connection process. Each registered client app is responsible for delivering this token to its content provider.
设备：系统使用APNs传递给它的公共服务证书来认证它已经连接的服务器。它有一个唯一的私有的钥匙来向服务器认证自己并建立TLS连接。它在设备活动期间获取设备证书和钥匙并把他们存储在钥匙串中。系统也持有他的特有的设备号，这是他在与服务器的连接过程中获取的。每一个已经注册的客户端应用都有责任向他的服务端传递这个设备号。
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证书，秘钥（公有的和私有的）来验证连接和服务端与设备的身份。
The Notification Payload
Each remote notification includes a payload. The payload contains information about how the system should alert the user as well as any custom data you provide. In iOS 8 and later, the maximum size allowed for a notification payload is 2 kilobytes; Apple Push Notification service refuses any notification that exceeds this limit. (Prior to iOS 8 and in OS X, the maximum payload size is 256 bytes.）
每一个远程通知都包含一个payload.payload包含了系统以怎样的方式通知用户和任何你提供的自定义数据的信息。在iOS8及以后，一个通知的最大字节是2000字节。苹果推送服务拒绝任何超过这个范围的通知（在iOS8之前和OS X系统中，最大的payload是256字节）。
For each notification, compose a JSON dictionary object (as defined by RFC 4627). This dictionary must contain another dictionary identified by the key aps. The apsdictionary can contain one or more properties that specify the following user notification types:
- An alert message to display to the user
- A number to badge the app icon with
- A sound to play
每一个通知，都形成了一个JSON字典格式的对象（在RFC 4627中定义的）。这个字典必须包含另外一个由key aps确认的字典。这个aps字典可以包含一个或者多个属性来阐述以下用户通知类型。
一个警铃信息来展示给用户
在应用图标上附上的数字
一段播放的声音
The aps dictionary can also contain the content-available property. The content-available property with a value of 1 lets the remote notification act as a “silent” notification. When a silent notification arrives, iOS wakes up your app in the background so that you can get new data from your server or do background information processing. Users aren’t told about the new or changed information that results from a silent notification, but they can find out about it the next time they open your app.
一个aps字典也能包含内容可用的属性。当content-available属性的值为1时可以让远程通知成为无声的通知。当一个无声通知到达时，iOS唤醒在后台的应用所以你可以从你的服务单获取新的数据或者进行后台信息处理。用户不会被告知来自无声通知的的新的或者变更的信息，但是他们可以在下次打开应用的时候发现。
To support silent remote notifications, add the remote-notification value to the UIBackgroundModes array in your Info.plist file. To learn more about this array, see UIBackgroundModes in Information Property List Key Reference.
为了支持无声的远程通知，在你的info.plist文件中的UIBackgroundModes数组中添加remote-nitification这个值。要了解更多关于这个数组的情况，请看UIBackgroundModes和Information Property List Key Reference.
If the target app isn’t running when the notification arrives, the alert message, sound, or badge value is played or shown. If the app is running, the system delivers the notification to the app delegate as an NSDictionary object. The dictionary contains the corresponding Cocoa property-list objects (plus NSNull).
当通知到达时目标应用没有在运行，警铃信息或者图标数字将会展示或者显现。如果应用正在运行，系统将通知以字典对象的格式传递给appDelegate.字典包含了对应的cocoa 属性列表对象。
Providers can specify custom payload values outside the Apple-reserved aps namespace. Custom values must use the JSON structured and primitive types: dictionary (object), array, string, number, and Boolean. You should not include customer information (or any sensitive data) as custom payload data. Instead, use it for such purposes as setting context (for the user interface) or internal metrics. For example, a custom payload value might be a conversation identifier for use by an instant-message client app or a timestamp identifying when the provider sent the notification. Any action associated with an alert message should not be destructive—for example, it should not delete data on the device.
服务端可以在苹果保留的aps命名空间之后自定义payload值。自定义值必须使用JSON格式和原始的类型：字典，数组，字符串，数字，布尔。不能包含用户信息或者任何敏感数据在自定义的payload中。相反，你可以在设置背景（关于用户交互的）或者内部的数据中来使用它（自定义payload）。例如，自定义的payload值可以在即时通讯类的客户端应用中作为对话标识来使用或者服务端何时发通知的时间戳。任何一个与警铃信息相联系的动作都不能是有害的-例如，它不能删除设备上的数据。
Important: Delivery of notifications is a “best effort”, not guaranteed. It is not intended to deliver data to your app, only to notify the user that there is new data available
重要提示：对一个通知的发送是一种最努力的尝试，而并非保证。它不是给你的应用传输数据，而是通知用户有可用的数据。
Table 3-1 lists the keys and expected values of the aps payload.
表格3-1 列出了aps payload中的键以及期望值。
Table 3-1 Keys and values of the aps dictionary
表格3-1 aps字典中的键值对。
Key | Value type | Comment |
| string or dictionary 字符串或者字典 | If this property is included, the system displays a standard alert. You may specify a string as the value of 如果这个属性被包含了，系统就播放一段标准警铃。你可以创建一个字符串作为alert的值，也可以用一个字典作为他的值。如果用的字符串，它就会称为信息内容并且包含两个button：关闭和查看按钮。如果用户点击了查看，应用就被启动了。 Alternatively, you can specify a dictionary as the value of 另外，你可以使用字典作为alert的值。请看表格3-2中对这个字典中键的描述。 |
| number 数字 | The number to display as the badge of the app icon. 就是在应用右上角展示的那个数字 If this property is absent, the badge is not changed. To remove the badge, set the value of this property to 如果这个属性没有赋值，这个badge就不会有变化。要移除badge,就把这个属性设置为0. |
| string | The name of a sound file in the app bundle. The sound in this file is played as an alert. If the sound file doesn’t exist or 在应用bundle中的声音文件中的名字。这个文件中的声音作为警铃播放。如果这个声音文件不存在或者有默认值，将会播放默认的铃声。音频格式必须与系统相兼容。详情请看 Preparing Custom Alert Sounds |
| number | Provide this key with a value of 给这个键赋值1的时候说明新的内容是可用的。包含这个键值意味着当你的应用在后台启动或者回复的时候，application:didReceiveRemoteNotification:fetchCompletionHandler:这个方法会被调用。 (Newsstand apps are guaranteed to be able to receive at least one push with this key per 24-hour window.) |
Table 3-2
lists the keys and expected values for the
alert dictionary.
图表3-2 列出了alert字典中的键和期望值
Table 3-2 Child properties of the alert property
图表3-2 alert属性的子属性
Key键 | Value type值 | Comment注解 |
标题 | string 字符串 | A short string describing the purpose of the notification. Apple Watch displays this string as part of the notification interface. This string is displayed only briefly and should be crafted so that it can be understood quickly. This key was added in iOS 8.2. 一段短小的文字来描述通知的目的。apple watch把title作为通知界面的一部分来展示。这个字符串应该是简洁的并且被精心推敲过的以至于可以快速被理解。这个键在iOS8.2中被添加。 |
| string 字符串 | The text of the alert message. 警铃信息的文字 |
| string or | The key to a title string in the 它代表当前本地化的本地化文件中的标题字符串的键。通过使用%@和%n$@等标示符将键格式化来代表title-loc-args数组中详述的变量。更多信息请看本地格式化字符串。这个键实在iOS8.2中添加的。 |
| array of strings or | Variable string values to appear in place of the format specifiers in 变量字符串的出现是为了代替title-loc-key中的格式化标识。更多信息请看本地格式化字符串。这个key是在iOS8.2中添加的。 |
| string or | If a string is specified, the system displays an alert that includes the Close and View buttons. The string is used as a key to get a localized string in the current localization to use for the right button’s title instead of “View”. See Localized Formatted Strings 如果指定一个字符串，系统就会打开一个弹框包含关闭和查看两个按钮。这个字符串被当做一个键来获取当前本地化中的本地化字符串来替换按钮上的“view”. |
| string | A key to an alert-message string in a 它是在当前本地化的本地化文件中弹窗提示语的键（是根据用户的语言偏好来设置的）。 |
| array of strings | Variable string values to appear in place of the format specifiers in |
| string | The filename of an image file in the app bundle; it may include the extension or omit it. The image is used as the launch image when users tap the action button or move the action slider. If this property is not specified, the system either uses the previous snapshot,uses the image identified by the This property was added in iOS 4.0. 在应用bundle中的图片文件的文件名。它可能包含它的一个延展或者省略掉它。当用户点击任务按钮或者滑动任务滑块的时候这个图片被作为加载图片使用。如果这个属性没有给出，系统要么使用之前的快照，使用应用的info.plist文件中由UILaunchImageFile这个键指定的图片，或者是default.png.这个属性是在iOS4.0中添加的。 |
Note: This general pattern is also followed when the value of the action-loc-key property is a string. This string is a key into the Localizable.strings in the localization directory for the currently selected language. iOS uses this key to get the title of the button on the right side of an alert message (the “action” button).
注意：如果action-loc-key的值也是字符串的话这个一般化的形式也会被遵循。这个字符串是为了选择当前语言的本地化目录中的本地化字符串中的键。iOS使用这个键来获取提示信息右边的按钮的标题。
To make this clearer, let’s consider an example. The provider specifies the following dictionary as the value of the alert property:
为了更清晰一些，我们来举个例子。服务端规定下面的字典作为alert属性的值。
"alert" : {
"loc-key" : "GAME_PLAY_REQUEST_FORMAT",
"loc-args" : [ "Jenna", "Frank"]
}