Apple Push Notification Service(蘋果推送服務)
https://developer.apple.com/library/IOS/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html
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 for more information.
提供者與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 ; for further information about the notification payload, see.
注意：更多關於裝置號的資訊，請看安全工程這一章節，更多關於通知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 .
反饋服務提供給服務端關於哪些通知不能被傳輸的資訊-例如，目標應用已經不再在設別上安裝了。更多資訊，請看反饋服務。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 notifications.
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 or uniqueIdentifier property
of UIDevice or any other similar properties
such as the 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 . 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 .) 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. 應用必須註冊才能收到遠端推送。通常它只要在一臺裝置上安裝就會這麼做。（這個過程在.中介紹的）系統接收來自應用的註冊請求，與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 , 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.
-
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 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 ). 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 in .
為了支援無聲的遠端通知，在你的info.plist檔案中的UIBackgroundModes陣列中新增remote-nitification這個值。要了解更多關於這個陣列的情況，請看UIBackgroundModes和.
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 as
an object.
The dictionary contains the corresponding Cocoa (plus ).
當通知到達時目標應用沒有在執行，警鈴資訊或者圖示數字將會展示或者顯現。如果應用正在執行，系統將通知以字典物件的格式傳遞給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中的鍵以及期望值。