對APNs的正確解讀

　　反人類的舊APNs協議設計

　　在介紹新版 APNs 前，讓我們來吐槽下舊的基于二進制的 APNs 協議設計是多么反人類：

　　在理論上，推送分發的服務器要打開一個同 APNs 網關服務器的

　　連接，并保持這個連接。但在舊的協議下，APNs 服務卻不保證 socket 能維持這個連接。如果通道上沒有消息往來，空閑下來到話，socket將被路由掐斷。也就是說：APNs 連接說斷就斷，而你無能為力。有意思的是：在舊的協議下，如果服務器響應成功的話，你將不會收到任何回應，但是如果服務器響應失?。ɡ?，使用了一個非法的 Push token），服務器將返回了一個錯誤編碼，并關閉這個socket。最重要的是，你必須重新發送使用這個無效 token 以后發送的所有推送（詳情見示意圖）。因此，你可能一直不能確定你的推送是否成功的被 APNs 服務器接收。

　　成功了不響應，失敗了才響應，這個是最大的反人類。于是許多開發者想到了一個很 tricky 的辦法：利用這個“漏洞”，比如在每發送10條后故意發送一個錯誤的token，如果APNs有響應了，就可以確認 APNs 是處在可用狀態的，進而確認這10條消息是發送成功的。如果沒有響應就說明可能連接已經中斷，那么這10條消息很可能是丟失的，然后做進一步的處理。但代價顯而易見：將導致你們的推送系統性能低下。（本文中所說到“你們的推送系統”，如果是使用的第三方的SDK完成的推送服務，那么就是指SDK提供商所搭建的推送系統。如果是你們公司自己搭建的推送系統，那么就是指你們自己的推送系統。）蘋果有一個名為“feedback”的服務，我們可以定時調用這個服務來獲取invalid tokens的列表。這個服務你只要調用一次就可以獲得所有的invalid tokens 列表。所以，如果一個應用使用了很多不同公司的推送SDK，他們將會爭奪資源去輪詢查找invalid tokens列表。invalid token越多，你們的推送系統性能將越低。而且 APNs 只要一發生錯誤就關閉這個連接，然后重新連接。也就是“重啟” socket 連接。

　　示意圖：

　　圖中的 PN2 去哪里了？它被放到了 feedback 列表里，等待下次你調用 feedback 服務，然后重發。

　　為什么Apple要在舊APNs中設計出“重啟”的策略？為了效率。就像PC機出問題，我們總說“重啟能解決90%的問題”。

　　為了理解“重啟”策略，我們可以類比下，熟悉 Erlang/OTP 的朋友可能知道， Erlang/OTP 在處理錯誤方面有獨到之處：監督樹（supervision trees）。大致來說，每一個 Erlang 進程都由一個監督進程發起并監視。當一個進程遇到了問題的時候，它就會退出。當進程退出的時候，其監督進程會將其重啟。

　?。ㄟ@些監督進程由一個引導進程（bootstrap process）發起，當監督進程遇到錯誤的時候，引導進程會將其重啟）

　　其思想是，快速的失敗然后重啟比去處理錯誤要快。像這樣的錯誤處理看起來跟直覺相反 —— 當錯誤發生的時候通過放棄處理來獲得可靠性。但是重啟的確是解決暫時性錯誤的靈丹妙藥。

　　這也可能讓你想到 DNS 服務發展史：

　　DNS 在設計之初是基于 UDP 的，顯然這樣的設計不能滿足當今社會的準確性的需求，于是涌現了如 DNSPod 這樣的基于 HTTP 的 DNS 解析服務。但是當時為什么這樣設計，實際也很好理解，UDP 效率高，一來一回網絡上傳輸的只有兩個包，而 HTTP則需要三次握手三個包，再一拆包，就需要四個包。這是受限于當時整個社會的帶寬水平較低，而現在沒人會感激 UDP 所節省的流量，所有人都在詬病DNS污染問題。這樣你也許就理解了，為什么舊的 APNs 設計如此反人類。這個是必經階段。

　　那么接下來就讓我們看看Apple為解決這些問題而推出的基于 HTTP/2 的全新 APNs 協議。

　　基于 HTTP/2 的全新 APNs 協議

　　來看下新版的 APNs 的新特性：

　　1）Request 和 Response 支持JSON網絡協議

　　2）APNs支持狀態碼和返回 error 信息

　　APNs推送成功時 Response 將返回狀態碼200，遠程通知是否發送成功再也不用靠猜了！

　　APNs推送失敗時，Response 將返回 JSON 格式的 Error 信息。

　　3）最大推送長度提升到4096字節（4Kb）

　　4）可以通過 “HTTP/2 PING ” 心跳包功能檢測當前 APNs 連接是否可用，并能維持當前長連接。

　　5）支持為不同的推送類型定義 “topic” 主題

　　6）不同推送類型，只需要一種推送證書 Universal Push Notification Client SSL 證書。

　　示意圖：

　　其中最大的變化就是基于了 HTTP/2 協議，采用了長連接設計，并提供 “HTTP/2 PING ” 心跳包功能檢測、維持當前 APNs 連接，解決了老 APNs 無法維持連接的問題。

　　而且新增的狀態碼特性，也解決了這個問題：無法獲知消息是否成功地從你們的推送系統投遞到了 APNs 上。理論上，你們可以保證消息是100%投遞到了APNs的，因為你可以準確的知道哪條消息到達了APNs，哪些沒到。重發特定失敗消息成為可能。

　　所以上文開頭的吐槽中第一條，有一句是“不到位的”，因為現在SDK的提供商能夠準確地告訴你哪些消息推送到APNs了，哪些沒有。

　　順便介紹下 HTTP/2：

　　HTTP/2 是 HTTP 協議發布后的首個更新，于2015年2月17日被批準。它采用了一系列優化技術來整體提升 HTTP 協議的傳輸性能，如異步連接復用、頭壓縮等等，可謂是當前互聯網應用開發中，網絡層次架構優化的首選方案之一。

　　Apple 對于 HTTP/2 的態度也非常積極，2015年5月 HTTP/2 正式發表后不久，便在緊接著6月召開的WWDC 2015大會中，向全球開發者宣布，iOS 9 開始支持HTTP/2。

　　而且如果我們要使用 HTTP/2，那么在網絡庫的選擇上必然要使用 NSURLSession。

　　我們都知道 HTTP/2 是復用 TCP 管道連接的，而且 HTTP/2 也以高復用著稱，這也使新的 APNs 協議更加高性能。（題外話：這點也同樣體現在 NSURLSession 底層對于每個 session 是對多個 task 進行連接的復用。）

　　Universal Push Notification Client SSL 證書

　　在開發中，往往一條內容，需要向多個終端進行推送，終端有：iOS、tvOS、 and OS X devices， 和借助iOS來實現推送的 Apple Watch。在以往的開發中，不同的推送，需要配置不同的推送證書：我們需要配置：dev證書、prod證書、VOIP證書、等等。而從2015年12月17日起，只使用一種證書就可以了，不再需要那么多證書，這種證書就叫做Universal Push Notification Client SSL 證書（下文統一簡稱：Universal推送證書）。

　　改進了，但仍需改進。還是有坑

　　APNs的確改進來不少，但仍有需要改進對地方。還是有坑：

　　除了獲取TLS證書比較復雜未解決外，還有一些坑：