蘋果最近更新了他們的推送提醒服務協議，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年的新功能吧。