Http / 2 protocol for IOS push reminder service (APNs)

Apple recently updated their push reminder service agreement, APNs. This new version of the protocol is based on HTTP / 2 and JSON. Compared with the old binary protocol, the new protocol has been greatly improved.

The new APNs protocol is based on HTTP / 2:

New features and functions:

JSON based requests and responses

For each notification, if the response is successful, 200 ID will be returned - there is no need to guess whether the notification is received

Response errors will be returned as JSON characters

The length of the message increased from 2048 bytes to 4096 bytes

The connection status can be checked through the Ping framework of HTTP / 2

Support topics

General push Certificate - the same certificate can be used for development and production

Old APNs binary protocol

The old binary APNs protocol is a little strange. Generally speaking, the push distribution server should open a socket connection with the APNs gateway server and maintain this connection. Under the old protocol, if the server responds successfully, you will not receive any response, But if the server fails to respond (for example, if an illegal push token is used), the server will return an error code and close the socket. Most importantly, you must resend all notifications sent after using this invalid token. Therefore, you may not be sure whether your push was successfully received by the server. Many systems use this vulnerability to deliberately send an error Wrong token, these hacking behaviors will lead to low system performance. Apple has a service called "feedback", which we can call regularly to get the list of invalid tokens. You can get the list of all invalid tokens by calling this service once. Therefore, if an application has many push notification providers, they will compete for resources to poll and find the invalid tokens list. The more invalidtokens, the lower the performance of your system, so APNs will close the connection as soon as an error occurs.

However, there are still some limitations. Obtaining TLS certificates is complicated, and the storage forwarding capability is weak. APNs only keeps a notification when the device goes offline, and will not upload information to the server after the device goes online. Google cloud messaging has all these features.

Considering that GCM now supports IOS devices, APNs and GCM now form a competitive relationship. Let me look forward to the new features of APNs in 2016.