反人類的舊APNs協(xié)議設(shè)計(jì)

　　在介紹新版 APNs 前，讓我們來(lái)吐槽下舊的基于二進(jìn)制的 APNs 協(xié)議設(shè)計(jì)是多么反人類：

　　在理論上，推送分發(fā)的服務(wù)器要打開(kāi)一個(gè)同 APNs 網(wǎng)關(guān)服務(wù)器的

　　連接，并保持這個(gè)連接。但在舊的協(xié)議下，APNs 服務(wù)卻不保證 socket 能維持這個(gè)連接。如果通道上沒(méi)有消息往來(lái)，空閑下來(lái)到話，socket將被路由掐斷。也就是說(shuō)：APNs 連接說(shuō)斷就斷，而你無(wú)能為力。有意思的是：在舊的協(xié)議下，如果服務(wù)器響應(yīng)成功的話，你將不會(huì)收到任何回應(yīng)，但是如果服務(wù)器響應(yīng)失敗（例如，使用了一個(gè)非法的 Push token），服務(wù)器將返回了一個(gè)錯(cuò)誤編碼，并關(guān)閉這個(gè)socket。最重要的是，你必須重新發(fā)送使用這個(gè)無(wú)效 token 以后發(fā)送的所有推送（詳情見(jiàn)示意圖）。因此，你可能一直不能確定你的推送是否成功的被 APNs 服務(wù)器接收。

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

　　示意圖：

　　圖中的 PN2 去哪里了？它被放到了 feedback 列表里，等待下次你調(diào)用 feedback 服務(wù)，然后重發(fā)。

　　為什么Apple要在舊APNs中設(shè)計(jì)出“重啟”的策略？為了效率。就像PC機(jī)出問(wèn)題，我們總說(shuō)“重啟能解決90%的問(wèn)題”。

　　為了理解“重啟”策略，我們可以類比下，熟悉 Erlang/OTP 的朋友可能知道， Erlang/OTP 在處理錯(cuò)誤方面有獨(dú)到之處：監(jiān)督樹(shù)（supervision trees）。大致來(lái)說(shuō)，每一個(gè) Erlang 進(jìn)程都由一個(gè)監(jiān)督進(jìn)程發(fā)起并監(jiān)視。當(dāng)一個(gè)進(jìn)程遇到了問(wèn)題的時(shí)候，它就會(huì)退出。當(dāng)進(jìn)程退出的時(shí)候，其監(jiān)督進(jìn)程會(huì)將其重啟。

　?。ㄟ@些監(jiān)督進(jìn)程由一個(gè)引導(dǎo)進(jìn)程（bootstrap process）發(fā)起，當(dāng)監(jiān)督進(jìn)程遇到錯(cuò)誤的時(shí)候，引導(dǎo)進(jìn)程會(huì)將其重啟）

　　其思想是，快速的失敗然后重啟比去處理錯(cuò)誤要快。像這樣的錯(cuò)誤處理看起來(lái)跟直覺(jué)相反 —— 當(dāng)錯(cuò)誤發(fā)生的時(shí)候通過(guò)放棄處理來(lái)獲得可靠性。但是重啟的確是解決暫時(shí)性錯(cuò)誤的靈丹妙藥。

　　這也可能讓你想到 DNS 服務(wù)發(fā)展史：

　　DNS 在設(shè)計(jì)之初是基于 UDP 的，顯然這樣的設(shè)計(jì)不能滿足當(dāng)今社會(huì)的準(zhǔn)確性的需求，于是涌現(xiàn)了如 DNSPod 這樣的基于 HTTP 的 DNS 解析服務(wù)。但是當(dāng)時(shí)為什么這樣設(shè)計(jì)，實(shí)際也很好理解，UDP 效率高，一來(lái)一回網(wǎng)絡(luò)上傳輸?shù)闹挥袃蓚€(gè)包，而 HTTP則需要三次握手三個(gè)包，再一拆包，就需要四個(gè)包。這是受限于當(dāng)時(shí)整個(gè)社會(huì)的帶寬水平較低，而現(xiàn)在沒(méi)人會(huì)感激 UDP 所節(jié)省的流量，所有人都在詬病DNS污染問(wèn)題。這樣你也許就理解了，為什么舊的 APNs 設(shè)計(jì)如此反人類。這個(gè)是必經(jīng)階段。

　　那么接下來(lái)就讓我們看看Apple為解決這些問(wèn)題而推出的基于 HTTP/2 的全新 APNs 協(xié)議。

　　基于 HTTP/2 的全新 APNs 協(xié)議

　　來(lái)看下新版的 APNs 的新特性：

　　1）Request 和 Response 支持JSON網(wǎng)絡(luò)協(xié)議

　　2）APNs支持狀態(tài)碼和返回 error 信息

　　APNs推送成功時(shí) Response 將返回狀態(tài)碼200，遠(yuǎn)程通知是否發(fā)送成功再也不用靠猜了！

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

　　3）最大推送長(zhǎng)度提升到4096字節(jié)（4Kb）

　　4）可以通過(guò) “HTTP/2 PING ” 心跳包功能檢測(cè)當(dāng)前 APNs 連接是否可用，并能維持當(dāng)前長(zhǎng)連接。

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

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

　　示意圖：

　　其中最大的變化就是基于了 HTTP/2 協(xié)議，采用了長(zhǎng)連接設(shè)計(jì)，并提供 “HTTP/2 PING ” 心跳包功能檢測(cè)、維持當(dāng)前 APNs 連接，解決了老 APNs 無(wú)法維持連接的問(wèn)題。

　　而且新增的狀態(tài)碼特性，也解決了這個(gè)問(wèn)題：無(wú)法獲知消息是否成功地從你們的推送系統(tǒng)投遞到了 APNs 上。理論上，你們可以保證消息是100%投遞到了APNs的，因?yàn)槟憧梢詼?zhǔn)確的知道哪條消息到達(dá)了APNs，哪些沒(méi)到。重發(fā)特定失敗消息成為可能。

　　所以上文開(kāi)頭的吐槽中第一條，有一句是“不到位的”，因?yàn)楝F(xiàn)在SDK的提供商能夠準(zhǔn)確地告訴你哪些消息推送到APNs了，哪些沒(méi)有。

　　順便介紹下 HTTP/2：

　　HTTP/2 是 HTTP 協(xié)議發(fā)布后的首個(gè)更新，于2015年2月17日被批準(zhǔn)。它采用了一系列優(yōu)化技術(shù)來(lái)整體提升 HTTP 協(xié)議的傳輸性能，如異步連接復(fù)用、頭壓縮等等，可謂是當(dāng)前互聯(lián)網(wǎng)應(yīng)用開(kāi)發(fā)中，網(wǎng)絡(luò)層次架構(gòu)優(yōu)化的首選方案之一。

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

　　而且如果我們要使用 HTTP/2，那么在網(wǎng)絡(luò)庫(kù)的選擇上必然要使用 NSURLSession。

　　我們都知道 HTTP/2 是復(fù)用 TCP 管道連接的，而且 HTTP/2 也以高復(fù)用著稱，這也使新的 APNs 協(xié)議更加高性能。（題外話：這點(diǎn)也同樣體現(xiàn)在 NSURLSession 底層對(duì)于每個(gè) session 是對(duì)多個(gè) task 進(jìn)行連接的復(fù)用。）

　　Universal Push Notification Client SSL 證書(shū)

　　在開(kāi)發(fā)中，往往一條內(nèi)容，需要向多個(gè)終端進(jìn)行推送，終端有：iOS、tvOS、 and OS X devices， 和借助iOS來(lái)實(shí)現(xiàn)推送的 Apple Watch。在以往的開(kāi)發(fā)中，不同的推送，需要配置不同的推送證書(shū)：我們需要配置：dev證書(shū)、prod證書(shū)、VOIP證書(shū)、等等。而從2015年12月17日起，只使用一種證書(shū)就可以了，不再需要那么多證書(shū)，這種證書(shū)就叫做Universal Push Notification Client SSL 證書(shū)（下文統(tǒng)一簡(jiǎn)稱：Universal推送證書(shū)）。

　　改進(jìn)了，但仍需改進(jìn)。還是有坑

　　APNs的確改進(jìn)來(lái)不少，但仍有需要改進(jìn)對(duì)地方。還是有坑：

　　除了獲取TLS證書(shū)比較復(fù)雜未解決外，還有一些坑：