快捷導(dǎo)航

HTTP/2 協(xié)議用于 iOS 推送提醒服務(wù) (APNS)

更新時(shí)間：2016年04月26日 10:55:47 作者：涼涼_

基于JSON的請求和響應(yīng)對于每個(gè)通知，如果成功響應(yīng)，將會(huì)返回200標(biāo)識 - 不用再去猜測通知是否被接收到響應(yīng)錯(cuò)誤將會(huì)以JSON字符消息的長度從2048個(gè)字節(jié)增加到4096個(gè)字節(jié)連接狀態(tài)可以通過HTTP/2的ping框架來進(jìn)行檢查.

蘋果最近更新了他們的推送提醒服務(wù)協(xié)議，APNS。這個(gè)新版本的協(xié)議基于HTTP/2和JSON，相比于舊的二進(jìn)制協(xié)議，新的協(xié)議有了巨大改進(jìn)。

新的APNS協(xié)議基于HTTP/2：

新的特性和功能：

基于JSON的請求和響應(yīng)

對于每個(gè)通知，如果成功響應(yīng)，將會(huì)返回200標(biāo)識 - 不用再去猜測通知是否被接收到

響應(yīng)錯(cuò)誤將會(huì)以JSON字符的形式返回

消息的長度從2048個(gè)字節(jié)增加到4096個(gè)字節(jié)

連接狀態(tài)可以通過HTTP/2的ping框架來進(jìn)行檢查

支持主題

通用的推送證書 - 開發(fā)和生產(chǎn)使用同一個(gè)證書即可

舊的APNS二進(jìn)制協(xié)議

舊的二進(jìn)制APNS協(xié)議有點(diǎn)奇特，一般來說，推送分發(fā)的服務(wù)器要打開一個(gè)同APNS網(wǎng)關(guān)服務(wù)器的socket連接，并保持這個(gè)連接。在舊的協(xié)議下，如果服務(wù)器響應(yīng)成功的話，你將不會(huì)收到任何回應(yīng)，但是如果服務(wù)器響應(yīng)失敗（例如，使用了一個(gè)非法的Push token），服務(wù)器將返回了一個(gè)錯(cuò)誤編碼，并關(guān)閉這個(gè)socket。最重要的是，你必須重新發(fā)送使用這個(gè)無效token以后發(fā)送的所有通知。因此，你可能一直不能確定你的推送是否成功的被服務(wù)器接收。許多系統(tǒng)使用這個(gè)漏洞，故意發(fā)送一個(gè)錯(cuò)誤的token，這些黑客行為將導(dǎo)致系統(tǒng)性能低下。蘋果有一個(gè)名為"feedback"的服務(wù)，我們可以定時(shí)調(diào)用這個(gè)服務(wù)來獲取invalid tokens的列表。這個(gè)服務(wù)你只要調(diào)用一次就可以獲得所有的invalid tokens 列表。所以，如果一個(gè)應(yīng)用有許多推送通知提供商，他們將會(huì)爭奪資源去輪詢查找invalid tokens列表。invalidtoken越多，你系統(tǒng)性能將越低，所以APNS只要一發(fā)生錯(cuò)誤就關(guān)閉這個(gè)連接。

不過仍然還有一些限制。獲取TLS證書比較復(fù)雜，而且存儲(chǔ)-轉(zhuǎn)發(fā)能力弱爆了，APNS在設(shè)備下線的時(shí)候只保留一個(gè)通知，并且設(shè)備上線之后也不會(huì)向服務(wù)器上傳信息，Google Cloud Messaging就有所有這些特性。

考慮到GCM現(xiàn)在也支持iOS設(shè)備了，那么APNS和GCM現(xiàn)在形成了競爭關(guān)系。讓我共同期待APNS在2016年的新功能吧。

您可能感興趣的文章: