蘋果遠程推送通知 APNs 詳解，官方，iOS | Swift | UNNotification

本文是翻譯的 APNs 的官方說明

本身英文不是太好，花了很多時間來翻譯，其實以前我是看不進去的。後來發現，只要你一點一點的看，老是能看進去的。

APNs 概述

APNs (Apple Push Ontification service) 服務是遠程通知的核心。該服務健全、安全、高效，開發者能夠方便的向 iOS tvOS macOS 終端設備推送通知。

當應用在用戶設備上運行的時候會在用戶設備和 APNs 之間創建一個安全的數據交互鏈接。應用經過該鏈接接收通知。在下面的一節中說明

另外一半的鏈接是發送通知的鏈接，是在你的服務器與 APNs 之間的固定鏈接，須要在你的開發者賬戶中用蘋果提供的加密證書配置。本質上講，信息提供者是一個服務器，是由你配置及部署的，須要你來寫服務端的功能。下圖顯示遠程通知的傳遞過程：

當服務器和手機應用中都配置好了以後，此時服務器能夠向 APNs 發送推送請求。APNs 接收並向每一個目標設置發送對應的通知信息。在終端設備（iOS macOS tvOS）接收到通知以後，系統把信息傳遞能你的應用，並管理用戶與通知的交互。

若是設備接收到通知的時候，你的應用沒有處於運行狀態，系統仍是能正常的顯示通知。
若是 APNs 發送通知的時候，終端設備關機了，APNs 會保留通知信息，並在一段時間以後重試。

服務器的職責

你的服務器在跟 APNs 溝通鏈接的時候具備如下責任：

• 經過 APNs 接收關於你的app的全球惟一的設備驗證碼，及其它一些數據

• 根據app功能的須要，決定通知推送的時間

• 創建通知請求，併發送通知請求到 APNs， APNs 再將通知遞送到相應的設備

對於每個通知請求，服務器須要作的：

1. 組建一個 JSON 數據，其中包含通知的信息 具體看下一章節

2. 添加 device token和通知信息到一個 HTTP/2 請求中。關於 device token 關於 HTTP/2 參數及回執信息

3. 經過一個永久安全的線路 (Security Architecture，發送包含證書的 HTTP/2 請求到 APNs

對於使用多個服務器的

工做圖示以下圖
多個服務器的時候，每一個服務器都須要經過證書或token 鏈接到 APNs，而後任意一個取得 device token 的服務器就能夠發送通知了。

服務質量，存儲併發送，聯合通知

APNs 的服務質量組件能夠實現存儲而後發送的功能。當 APNs 發送通知到一個離線設備時，APNs 會把通知存儲起來（必定的時間內），當設備上線時再遞送給設備。這個存儲功能只存儲一個設備的一個app的最近的通知。若是設備離線中，發送一個到該設備的通知會消除前面存儲的通知。若是設備處於離線過久，全部存儲的發往該設備的通知都將被消除。

當發送通知的時候在頭部添加合併id，可使發送的通知合併起來。當 apns-collapse-id 添加到你發送的 HTTP/2 通知請求中時，APNs 合併apns-collapse-id值相同的通知。關於更多apns-collapse-id的知識，點此查看

安全結構

APNs 採用雙層信任機制：鏈接信任 和 device token 信任

鏈接信任工做在服務器與 APNs 之間 | APNs 與設備之間

服務器與APNs之間的信任確保服務器與 APNs 之間的鏈接是安全的，你須要根據本節中提到的信息，按步驟確保服務器與 APNs 之間的安全鏈接
APNs與設備之間的信任確保只有驗證的設備才能鏈接 APNs 收到通知，APNs 自動確保與設備之間的鏈接是安全正確的。

服務器與 APNs 通訊的時候，必須實現 驗證證書（基於token的驗證）或者 SSL 證書（基於證書的驗證）。你在[開發者賬戶][]中須要實現這兩種驗證方式的任意一種，幫助在這。能夠查看這裏服務器與apns鏈接信任來肯定你須要選擇哪一種驗證方式。

device token 信任

device token 能夠確保通知只在肯定的服務器與終端設備之間傳送。

device token 是一個不透明的 NSData，包含一個設備上的一個應用的惟一標識。只有 APNs 能解密並查看 device token 中的內容。每一個應用在向 APNs 發送遠程推送註冊請求的時候都會收到本身的 惟一的 device token，而後必須把 device token 轉發給你app的服務器（詳見 配置推送支持）。服務器在發送通知到相應的設備時，必須包含對應的 device token。APNs 經過 device token 來確保通知發送到對應設備的對應app中。

APNs 發行新 device token 的緣由有：

• 用戶安裝你的app到新設備上

• 用戶經過備份恢復設備

• 用戶重裝系統後

• 其它系統層面的事件

因此，app在啓動的時候必須請求 device token，參閱 APNs 到設備之間的鏈接信任 和 device token，看代碼實例詳見 推送註冊請求

注意：爲了保護用戶隱私，不要用 device token 來標識用戶

服務器與 APNs 之間的信任

服務器與APNs之間有兩種方式實現鏈接信任

基於 Token 的服務器與 APNs 之間的信任 服務器能夠根據 基於HTTP/2 的API 用JSON web tokens (JWT) 來實現與 APNs 之間的鏈接信任。這這個模式下，你須要提供一個公共密鑰給 Apple。服務器須要用該密鑰來生成並添加到 JWT 服務器驗證 token。 服務器發出的每一個推送請求必須包含該 token。

你就能用簡單的基於token的鏈接，來實如今你開發者賬戶中的全部應用的推送請求。

服務器向 APNs 發出的每一個推送請求，都會收到 APNs 的 HTTP/2 反饋。

基於證書的服務器與 APNs 之間的信任 服務器也能夠經過惟一的證書來實現鏈接信任。服務器證書能夠從開發者賬戶中獲取到，基於你 app 的惟一的證書。而後就可使用證書來實現推送請求了。

重要
爲實現與 APNs 之間基於 HTTP/2的 SSL 鏈接，你的服務器中必須包含 GeoTrust Gloabl CA 做爲根證書。若是你的服務器運行的是 macOS，這個根證書在 keychain 中。其它系統的服務器則就我的狀況來安裝。你能夠從 GeoTrust Root Certificates 網站下載，也能夠點這裏直接下載證書。

基於 Token 的服務器與 APNs 之間的信任

Apple Push Notification Authentication Key (Sandbox & Production)
你須要在你的[開發者賬戶][]中進行配置，具體操做看 生成惟一的服務器Token
這個證書有如下特性：

• 一個證書能夠用於向全部包含在賬戶下的 app 發送推送。一樣可用於 voiceover-Internet Protocol(VoIP)。即便在你的app處於後臺運行時，APNs 也會向app發送這個證書。詳情參見APNs 服務器證書，在開發中的能耗指導查看關於Voice Over IP(VoIP)最好的應用的說明

• 發送推送請求時，必須在基於 JWT 鏈接中包含該證書

• 認證證書永不失效，但你能夠隨時經過[開發者賬戶][]從新獲取，從新獲取後舊的證書將不能再使用

下圖爲： 用 HTTP/2 在服務器與 APNs 之間創建信任鏈接，用 JWT 向 APNs 發送推送請求

如圖所示，工做流程是這樣的：

1. 服務器向 APNs 請求基於 TLS(transport layer security)的安全鏈接請求

2. APNs 向服務器發送認證證書，到這裏，服務器與 APNs 之間的鏈接已經創建，此時能夠發送推送請求

3. 服務器須要發送的每一個推送請求必須包含 JWT 認證 token

4. APNs 向服務器發送 HTTP/2 回執 參見HTTP/2

基於證書的服務器與 APNs 之間的信任

基於證書的服務器鏈接只支持特定的某一個應用。證書須要在你的服務器上根據你的應用 bundle 提早生成，具體參見 生成一個惟一的通往APNs 的 SSL 鏈接證書。根據你生成的證書的不一樣，信任的鏈接也能夠推送一些與你app相關的一些東西，如 apple watch 的併發和 VoIP (voice-over-Internet Protocol)。APNs 會傳送推送這些，即便設備僅在後臺運行。查閱與 APNs 溝通來獲取更多知識，在開發中的能耗指導查看關於Voice Over IP(VoIP)最好的應用的說明。

在基於證書的信任鏈接中，APNs 會持有一個廢止的證書列表，若是服務器的證書在這個列表中，APNs 會廢止與服務器的信任鏈接（也就是說 APNs 會拒絕服務器的請求）

該鏈接方式的過程是這樣的：

1. 服務器向 APNs 發出 TLS 鏈接請求

2. APNs 把證書發給服務器

3. 服務器須要把你以前從[開發者賬戶][]中生成的證書發給 APNs，具體參見生成一個惟一的通往APNs 的 SSL 鏈接證書

4. APNs 驗證服務器提供的證書是否正確，若是正確，則肯定服務器與 APNs 的信任鏈接。此時服務器能夠向 APNs 發送推送請求了。

APNs 與設備之間的鏈接與 Device Tokens

APNs 與每一個設備之間的鏈接是自動創建的，這個過程當中，不須要你的 app 作什麼。

每一個設備都有一個加密的證書和私有密鑰，在設備激活的時候生成，並保存在設備的 keychain 中，在設備激活的時候，APNs 根據設備的證書和密鑰驗證並受權與設備之間的鏈接。

過程是這樣的：

1. 設備向 APNs 發送 TLS 鏈接請求，信任鏈接設置開始

2. APNs 回執 APNs 證書到設備上

3. 設備操做系統驗證接收到的 APNs 證書，並向 APNs 發送本身的設備證書

4. APNs 驗證設備發來證書，若是正確，信任鏈接創建

當設備與 APNs 之間的信任鏈接創建以後，此時設備能夠向 APNs 申請特定 app 的 device-token，具體參閱 配置遠程推送支持 的註冊接收遠程推送章節。

在收到 device token 以後，app 必須向其服務器發送接收到的 device token。由於服務器以後向 APNs 發送推送請求時須要用到 device token，代碼請參閱 配置遠程推送支持

設備激活申請 device token，和 APNs 新生成一個 device token 的過程是同樣的，如圖：

過程：

1. app 向 APNs 申請遠程推送請求，若是設備已經註冊了遠程推送請求，而且特定 app 的 device token 並無變化，則 APNs 會返回已經存在的 device token 到設備上，跳轉到步驟4

2. 當一個新的設備須要註冊推送請求時，APNs 根據接收到的設備證書來生成一個 device token，並回執給設備

3. 設備系統把接收到的 device token 傳給 app 並調用 AppDelegate 方法 application:didRegisterForRemoteNotificationWithDeviceToken:

4. 設備接收到 device token 以後，須要把它按二進制或十六進制的格式發給你的服務器，服務器才能用該 device token 來發送推送請求

重要
APNs 提供的 device token 的長度不定，不要強行解碼其大小

當服務器向 APNs 發送推送請求時，請求中包含中標識惟一設備惟一 app 的 device token，這個過程就是下圖中 Token, Payload 過程。APNs 解密 device token 確保推送請求的目標。若是請求的發送者和接收者都合法，APNs 向設備發送請求的推送信息。

在設備接收到 APNs 發來的推送以後，操做系統會把通知遞送給相應的 app。

準備步驟

APNs 可用於發佈在 iOS 應用商店，tvOS 應用商店， macOS 應用商店中的應用，和企業應用。
你的 app 須要編寫支持推送的功能。若是你是以團隊合做的形式開發，那麼大多數配置的過程都由管理來實現。由於須要用到開發者賬戶。

想查看更多關於如何配置推送的知識，參閱 配置遠程推送通知