More than 90% of iOS developers in China have a wrong understanding of APNs

[[165663]]

Preface:

The APNs protocol has been revised twice at WWDC in the past two years, and a revolutionary new feature was launched on December 17, 2015. However, the answers to APNs in blogs and interview questions circulated in China are all old and wrong.

text:

Complaints about APNs

APNs is the abbreviation of Apple Push Notification service (note the capitalization of APNs, the s does not need to be capitalized).

Here are some complaints I collected about APNs. Let’s take a look at which complaints are more “on point”:

The answers will be interspersed below.

APNs News

In June 2014, WWDC announced that the maximum payload size that can be received by iOS devices running iOS 8 and above has been increased to 2KB. Devices below iOS 8 and OS X devices maintain 256 bytes. Reference document: What's New in Notifications - WWDC 2014 - Session 713 - iOS

[[165664]]

In June 2015, WWDC announced that it would release a "new APNs protocol based on HTTP/2" in the near future, and released a version that only supports test certificates at the conference. Reference document: What's New in Notifications - WWDC 2015 - Session 720 - iOS, OS X

Starting from December 17, 2015, the "new APNs protocol based on HTTP/2" was released. The maximum payload size of iOS and OS X systems was increased to 4KB. Reference document: Apple Push Notification Service Update 12-17 2015

Comparison of the working diagrams of the new and old APNs protocols

Next, we will introduce the new and old protocols respectively:

The anti-human old APNs protocol design

Before introducing the new version of APNs, let's talk about how anti-human the old binary-based APNs protocol design is:

In theory, the push distribution server should open a connection with the APNs gateway server.

connect, and maintain this connection. However, under the old protocol, the APNs service does not guarantee that the socket can maintain this connection. If there is no message exchange on the channel and it arrives idle, the socket will be cut off by the router. In other words: the APNs connection can be disconnected at any time, and you can't do anything about it. What's interesting is: under the old protocol, if the server responds successfully, you will not receive any response, but if the server responds unsuccessfully (for example, an illegal Push token is used), the server will return an error code and close the socket. Most importantly, you must resend all pushes sent using this invalid token (see the diagram for details). Therefore, you may not be sure whether your push is successfully received by the APNs server.

Not responding when the message succeeds and responding only when the message fails is the biggest anti-humanity. So many developers came up with a tricky way: take advantage of this "loophole", for example, deliberately send a wrong token after sending every 10 messages. If APNs responds, it can be confirmed that APNs is in an available state, and then confirm that the 10 messages are sent successfully. If there is no response, it means that the connection may have been interrupted, then the 10 messages are likely to be lost, and then further processing is performed. But the cost is obvious: it will lead to poor performance of your push system. (The "your push system" mentioned in this article, if it is a push service completed by a third-party SDK, then it refers to the push system built by the SDK provider. If it is a push system built by your company, then it refers to your own push system.) Apple has a service called "feedback", which we can call regularly to obtain a list of invalid tokens. You only need to call this service once to get a list of all invalid tokens. Therefore, if an application uses push SDKs from many different companies, they will compete for resources to poll and find the list of invalid tokens. The more invalid tokens there are, the lower the performance of your push system will be. And APNs closes the connection as soon as an error occurs, and then reconnects, which is to "restart" the socket connection.

Schematic diagram:

Where did PN2 go? It was put into the feedback list, waiting to be resent the next time you call the feedback service.

Why did Apple design the "restart" strategy in the old APNs? For efficiency. Just like when a PC has a problem, we always say "restarting can solve 90% of the problems."

To understand the "restart" strategy, we can use an analogy. Friends who are familiar with Erlang/OTP may know that Erlang/OTP has a unique way of handling errors: supervision trees. Generally speaking, each Erlang process is initiated and monitored by a supervisor process. When a process encounters a problem, it exits. When a process exits, its supervisor process restarts it.

(These supervisory processes are initiated by a bootstrap process, which restarts the supervisory process if it encounters an error.)

The idea is that it's faster to fail fast and restart than to handle the error. Error handling like this seems counterintuitive - gaining reliability by giving up when an error occurs. But restarting is a panacea for transient errors.

This may also remind you of the history of DNS service development:

DNS was originally designed based on UDP. Obviously, such a design cannot meet the accuracy requirements of today's society, so DNS resolution services based on HTTP, such as DNSPod, emerged. But why it was designed this way at the time is actually easy to understand. UDP is highly efficient. Only two packets are transmitted on the network in a round trip, while HTTP requires three handshakes and three packets, and then four packets are needed for unpacking. This was limited by the low bandwidth level of the entire society at the time. Now no one will appreciate the traffic saved by UDP, and everyone is criticizing the DNS pollution problem. In this way, you may understand why the old APNs design is so anti-human. This is a necessary stage.

Then let's take a look at the new APNs protocol based on HTTP/2 launched by Apple to solve these problems.

New APNs protocol based on HTTP/2

Let’s take a look at the new features of the new version of APNs:

1) Request and Response support JSON network protocol

2) APNs supports status codes and returns error information

• When APNs push succeeds, Response will return status code 200. You no longer have to guess whether the remote notification was sent successfully!

• When APNs push fails, Response will return Error information in JSON format.

3) The maximum push length is increased to 4096 bytes (4Kb)

4) The “HTTP/2 PING” heartbeat packet function can be used to detect whether the current APNs connection is available and whether the current long connection can be maintained.

5) Supports defining "topic" topics for different push types

6) Different push types only require one push certificate: Universal Push Notification Client SSL certificate.

Schematic diagram:

The biggest change is that it is based on the HTTP/2 protocol, adopts a long connection design, and provides the "HTTP/2 PING" heartbeat packet function to detect and maintain the current APNs connection, solving the problem that the old APNs cannot maintain the connection.

The newly added status code feature also solves the problem of not being able to know whether the message was successfully delivered from your push system to APNs. In theory, you can guarantee that the message is 100% delivered to APNs, because you can accurately know which messages have arrived at APNs and which have not. It is possible to resend specific failed messages.

So one of the first complaints at the beginning of the article is "not in place", because now the SDK provider can accurately tell you which messages are pushed to APNs and which are not.

By the way, let me introduce HTTP/2:

HTTP/2 is the first update after the release of the HTTP protocol and was approved on February 17, 2015. It uses a series of optimization technologies to improve the overall transmission performance of the HTTP protocol, such as asynchronous connection multiplexing, header compression, etc. It can be said to be one of the preferred solutions for optimizing the network hierarchy architecture in the current Internet application development.

Apple is also very positive about HTTP/2. Shortly after HTTP/2 was officially released in May 2015, Apple announced to global developers at the WWDC 2015 conference held in June that iOS 9 began to support HTTP/2.

And if we want to use HTTP/2, then we must use NSURLSession when choosing the network library.

We all know that HTTP/2 reuses TCP pipe connections, and HTTP/2 is also known for its high reuse, which also makes the new APNs protocol more performant. (Off-topic: This is also reflected in the fact that the underlying NSURLSession reuses multiple tasks for each session.)

Universal Push Notification Client SSL Certificate

In development, a piece of content often needs to be pushed to multiple terminals, including iOS, tvOS, and OS X devices, and Apple Watch that uses iOS to push. In previous development, different pushes required different push certificates: we needed to configure: dev certificate, prod certificate, VOIP certificate, etc. However, starting from December 17, 2015, only one certificate is needed, and so many certificates are no longer needed. This certificate is called Universal Push Notification Client SSL Certificate (hereinafter referred to as Universal Push Certificate).

Improved, but still needs improvement.

APNs has indeed improved a lot, but there are still areas that need improvement. There are still some pitfalls:

In addition to the complexity of obtaining TLS certificates, there are also some pitfalls:

The following situation was mentioned at the beginning of the article:

I regret to tell you that your complaints are "on point": you will have to endure this anti-human design in the future.

What happened in between?

When APNs sends you 4 push notifications, but your device is offline due to poor network conditions, there are 4 tasks accumulated on the link from APNs to your phone. APNs handles this by only keeping the last message and notifying you of the number of push notifications. What about the other three messages? They will be discarded by APNs.

Some apps do not maintain a persistent connection for their IM functions, but rely entirely on push notifications. Usually, these apps have already considered the possibility of lost push notifications. After receiving a push notification, these apps will query their own servers for the current user's unread messages. However, APNs cannot guarantee that at least one of the four push notifications will reach your app. I regret to inform these apps that this update will not improve the problems you have encountered.

Why is it designed this way? APNs's storage-forwarding capability is too weak. A large amount of message storage and forwarding will consume Apple's server resources. This may be due to storage cost considerations or because Apple's forwarding capability is too weak. In short, APNs never guarantees the message arrival rate. And the device will not upload information to the server after it goes online.

Therefore, the first complaint at the beginning of the article also has the sentence "in place", because the SDK provider still cannot guarantee that the message is pushed to APNs and APNs can be pushed to the App.

But Google Cloud Messaging has these features. And GCM now supports iOS devices, so APNs and GCM are now in competition. Let's look forward to new improvements to APNs at the WWDC in June 2016.

Impact on App Development

If you want to use the new protocol, if you use a third-party push service, the most obvious operation here is that you must update to the SDK version that supports the new protocol. Because the new protocol requires the SDK to upload your app's bundle id and generate topics for push on various platforms. If you build your own service, you need to upload it yourself. The old protocol does not need to be uploaded.

The new APNs supports push content up to 4096 bytes for all versions such as iOS6. The old APNs only supported 256 bytes before June 2014, and 2048 bytes after that for iOS8 and above. In the past, due to the limitation of push bytes, for example, when pushing article URLs, developers chose to push IDs after exceeding 256, or even directly push IDs without judgment, and then request the full URL after receiving it. Once the request is wrong, the push content may be lost. Now it can be avoided.

How to create a Universal Push Notification Client SSL certificate

Now that you know what a Universal Push Notification Client SSL certificate is, how do you create one?

The other methods in the figure are called non-universal methods (hereinafter referred to as non-universal push certificates):

It is also recommended to use the Universal Push Certificate for push service. The detailed creation steps are as follows:

• Go to the Apple Developer Center, log in, and click "Certificates, Identifiers & Profiles".

• Select "All" under the Certificates column.

• Click the plus button in the red border in the image below.

• Select “Apple Push Notification service SSL (Sandbox & Production)” under the “Production” column, check the box, and click Next.

• Select the App ID you need from the App ID drop-down menu and click Next.

• The About Creating a Certificate Signing Request (CSR) page will appear.

• Create a Certificate Signing Request according to its instructions.

• Click the "Choose File" button as shown below:

• Upload the .certSigningRequest file you just generated to generate the APNs Push Certificate.

• Download the certificate.

• Double-click the certificate to open it. When the certificate opens, the Keychain Access tool will be launched.

• In the Keychain Access tool, your certificate will be displayed in "Certificates". Be sure to select "Certificates" in the lower left corner and "Login" in the upper left corner.

Conclusion

For APNs, this update of iOS 9 is of epoch-making significance. Please urge your company's server to upgrade immediately, or use SDK that supports the new APNs protocol for push service. If there are any errors in the article, please help correct them. Please send feedback to Weibo @iOS程序犭袁.

Reference Links:

Configuring Push Notifications

APNs Provider API

HTTP/2 Protocol for iOS Push Notification Server(APNS)