HTTP/2 協議用於 iOS 推送提醒服務 (APNS)_IOS

蘋果最新動向了他們的推送提醒服務合約，APNS。這個新版本的協議基於HTTP/2和JSON，相比於舊的二進位協議，新的協議有了巨大改進。

新的APNS協議基於HTTP/2：

新的特性和功能：

基於JSON的請求和響應

對於每個通知，如果成功響應，將會返回200標識 - 不用再去猜測通知是否被接收到

響應錯誤將會以JSON字元的形式返回

訊息的長度從2048個位元組增加到4096個位元組

串連狀態可以通過HTTP/2的ping架構來進行檢查

支援主題

通用的推送認證 - 開發和生產使用同一個認證即可

舊的APNS二進位協議

舊的二進位APNS協議有點奇特，一般來說，推送分發的伺服器要開啟一個同APNS閘道伺服器的socket串連，並保持這個串連。在舊的協議下，如果伺服器響應成功的話，你將不會收到任何回應，但是如果伺服器響應失敗（例如，使用了一個非法的Push token），伺服器將返回了一個錯誤編碼，並關閉這個socket。最重要的是，你必須重新發送使用這個無效token以後發送的所有通知。因此，你可能一直不能確定你的推送是否成功的被伺服器接收。許多系統使用這個漏洞，故意發送一個錯誤的token，這些駭客行為將導致系統效能低下。蘋果有一個名為"feedback"的服務，我們可以定時調用這個服務來擷取invalid tokens的列表。這個服務你只要調用一次就可以獲得所有的invalid tokens 列表。所以，如果一個應用有許多推播通知供應商，他們將會爭奪資源去輪詢尋找invalid tokens列表。invalidtoken越多，你系統效能將越低，所以APNS只要一發生錯誤就關閉這個串連。

不過仍然還有一些限制。擷取TLS認證比較複雜，而且儲存-轉寄能力弱爆了，APNS在裝置下線的時候只保留一個通知，並且裝置上線之後也不會向伺服器上傳資訊，Google Cloud Messaging就有所有這些特性。

考慮到GCM現在也支援iOS裝置了，那麼APNS和GCM現在形成了競爭關係。讓我共同期待APNS在2016年的新功能吧。