Apple has recently updated the protocol push notifications delivery service, called APNS. The newer version of this protocol is based upon HTTP/2 and JSON, which signals a huge improvement compared to the older binary protocol.

News HTTP/2 based APNS  Protocol

ServerServerAPNSAPNSHTTP/2 TLS  ConnectionSend Push Notification PN1200 OK PN1Send Push Notification PN2Send Push Notification PN3400 Invalid Token PN2200 OK PN3...

New features and capabilities:

• A JSON based request response protocol

• APNS will send 200 Success Response on each notification - No more guessing whether a notification has been accepted or not.

• Error response is a JSON string

• Message length increased from 2048 bytes to 4096 bytes

• The connection status can be checked with help of HTTP/2 PING Frame

• Support for topics

• Universal Push Notification Certificate - Use the same credentials for Development and Production

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

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

新的特性和功能：

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

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

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

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

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

• 支持主題

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

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

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

新的特性和功能：

• 基于json的請(qǐng)求和響應(yīng)

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

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

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

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

• 支持主題

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

Old APNS Binary Protocol

ServerServerAPNSAPNSTLS Socket ConnectionSend Push Notification PN1Send Push Notification PN2Send Push Notification PN3Send Push Notification PN4Invalid Token PN2DisconnectTLS Socket ConnectionResend Push Notification PN3...

The old binary APNS protocol was very idiosyncratic. Basically, the push delivery server had to open a socket to the APNS gateway server, and keep on writing to the socket. With this old model, you wouldn’t receive a response if you were successful, but if there were any errors (for example in case of an Invalid Push token) then the server sent back an error code and closed down the socket. On top of that, you had to resend all notifications that you had sent after this invalid token. As a result, you could never be sure if your push was accepted successfully by the server. Many systems used tricks like sending an invalid token on purpose. All of these hacks resulted in lower performance for the system. Apple has a "feedback" service, which you can call periodically to get a list of invalid tokens. The main problem with this service is that you could only call it once to get a list of invalid tokens. So, if an app is using multiple push notification providers, they are going to compete in order to get the list of invalid tokens. The more invalid tokens you have, the lower your performance is, as APNS drops connection for any error.

舊的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ì)爭(zhēng)奪資源去輪詢查找invalid tokens列表。invalid token越多，你系統(tǒng)性能將越低，所以APNS只要一發(fā)生錯(cuò)誤就關(guān)閉這個(gè)連接。

Some other limitations are still present. It is a complex process to obtain the TLS certificates. There are poor store-and-forward capabilities - APNS stores only a single notification on its server if the device is offline.  In addition, there is no upstream messaging from the device back to the server. Google Cloud Messaging has all of these capabilities.

There is a bit of competition with GCM and APNS, especially considering the fact that GCM now has added support for iOS. Let's hope for additional APNS features in 2016

不過仍然還有一些限制。獲取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)在形成了競(jìng)爭(zhēng)關(guān)系。讓我共同期待APNS在2016年的新功能吧。

新的協(xié)議還是存在一些限制。要想獲取TLS證書相當(dāng)復(fù)雜，并且在存儲(chǔ)-轉(zhuǎn)發(fā)能力上也比較弱（在設(shè)備下線時(shí)，APNS僅保留最后一條通知，而且當(dāng)設(shè)備上線后，之前丟失的信息也無法繼續(xù)發(fā)送）。Google Cloud Messaging 就不會(huì)有這些問題。

考慮到現(xiàn)在GCM也開始支持iOS，與APNS形成了競(jìng)爭(zhēng)關(guān)系。讓我們期待在2016年APNS會(huì)有更多新的特性吧。