蘋果比來更新了他們的推送提示辦事協定，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年的新功效吧。

【HTTP/2 協定用於 iOS 推送提示辦事 (APNS)】的相關資料介紹到這裡，希望對您有所幫助！ 提示：不會對讀者因本文所帶來的任何損失負責。如果您支持就請把本站添加至收藏夾哦！