More than 90% of IOS developers in China, the understanding of APNs is wrong

Ext.: http://toutiao.com/a6276578687162040578/?tt_from=weixin&utm_campaign=client_share&app=news_article &utm_source=weixin&iid=4155521039&utm_medium=toutiao_android&wxshare_count=1

This article is for posting articles, iOS program Dogs Yuan (blog)

Objective:

The APNs agreement was changed two times in the last two years of the WWDC, and the new revolutionary features were introduced on December 17, 2015. But in the domestic spread of the blog, interview questions about APNs The answer is all old, wrong.

Body:

The APNs of the tank

APNs is the abbreviation for Apple Push Notification Service (note the case of APNs, S does not need to be capitalized).

Here are some of the APNs I've collected about the tank, and you'll see which ones are "in place":

The answers are interspersed below.

APNs News

June 2014 WWDC with iOS devices with iOS8 and above, the maximum playload size that can be received is increased to 2KB. Devices below iOS8 and OS X devices maintain 256 bytes. Reference document: What's New in NOTIFICATIONS-WWDC 2014-session 713-ios

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

With effect from December 17, 2015, the "New APNs protocol based on HTTP/2", IOS system and OS X system, has been released to increase the maximum playload size to 4KB. Reference Document: Apple Push Notification Service Update 12-17 2015

Comparison of new and old APNs agreement work

Next we introduce the old and new protocols separately:

Design of anti-human old APNs protocol

Before introducing the new APNs, let's spit out the old binary-based APNs protocol design is how anti-human:

In theory, the server that pushes the distribution to open a APNs gateway server

Connect, and keep this connection. However, under the old protocol, the APNs service does not guarantee that the socket will maintain the connection. If there is no message on the channel, the socket will be routed and snapped when it is idle. That is: APNs connection is broken, and you can do nothing. Interestingly: Under the old protocol, if the server responds successfully, you will not receive any response, but if the server fails to respond (for example, using an illegal Push token), the server will return an error code and close the socket. Most importantly, you must resend all pushes sent after using this invalid token (see details). Therefore, you may not be able to determine whether your push was successfully received by the APNs server.

Success did not respond, failed to respond, this is the largest anti-human. So many developers think of a very tricky approach: using this "loophole", for example, after each send 10 to deliberately send a wrong token, if APNs has a response, you can confirm that APNs is in a usable state, and then confirm that the 10 messages are sent successfully. If there is no response to the possibility that the connection has been interrupted, then the 10 messages are likely to be lost and then further processed. But the price is obvious: it will lead to poor performance of your push system. (In this article, "Your Push system", if you are using a third-party SDK to complete the push service, then refers to the SDK provider built by the push system.) If it's your company's own push system, it means your own push system. Apple has a service called "feedback", and we can call this service periodically to get a list of invalid tokens. This service you can only call once to get all the invalid tokens list. So, if an app uses a lot of different companies ' push SDKs, they'll scramble for resources to poll for the invalid tokens list. The more invalid tokens, the less performance your push system will have. And APNs just shut down the connection and reconnect as soon as an error occurs. That is, "reboot" the socket connection.

：

Where did the PN2 go in the picture? It is placed in the feedback list, waiting for the next time you call the feedback service and then re-send.

Why did Apple design a "restart" strategy in the old APNs? For efficiency. Like a PC problem, we always say, "Restarting solves 90% of problems."

In order to understand the "restart" strategy, we can analogy, a friend familiar with ERLANG/OTP may know that ERLANG/OTP in dealing with errors is unique: the supervisory tree (supervision trees). In general, each Erlang process is initiated and monitored by a monitoring process. When a process encounters a problem, it exits. When the process exits, its watchdog process restarts it.

(These monitoring processes are initiated by a boot process (bootstrap), which restarts the boot process when the monitoring process encounters an error)

The idea is that a quick failure and then a reboot is quicker than dealing with a mistake. Error handling like this seems to be the opposite of intuition---------------------- But restarting is indeed a panacea for temporary errors.

This may also make you think of the DNS Service history:

DNS at the beginning of the design is based on UDP, it is clear that such a design does not meet the needs of today's society's accuracy, so the emergence of such as Dnspod HTTP-based DNS resolution service. But then why this design, the actual also very good understanding, UDP high efficiency, one back to the network only two packets of transmission, and HTTP will need three handshake three packets, and then a unpacking, it will require four packets. This is limited by the bandwidth level of the entire society at that time, and no one is grateful for the traffic that UDP has saved, and everyone is complaining about DNS pollution. So you may understand why the old APNs design is so anti-human. This is a necessary stage.

Then let's look at Apple's new HTTP/2-based APNs protocol to address these issues.

The new APNs protocol based on HTTP/2

Take a look at the new features of APNs:

1) Request and Response support JSON network protocol

2) APNs support status code and return error information

• APNs push succeeds when Response will return status code 200, remote notification is sent successfully no longer rely on guessing!

• When the APNs push fails, Response returns the ERROR message in JSON format.

3) Maximum push length increased to 4096 bytes (4Kb)

4) The "HTTP/2 PING" Heartbeat pack feature can be used to detect whether the current APNs connection is available and to maintain the current long connection.

5) Support for defining "topic" themes for different push types

6) for different push types, only one push certificate Universal push Notification Client SSL certificate is required.

：

The biggest change is based on the HTTP/2 protocol, the use of long-connection design, and provide "HTTP/2 PING" heartbeat packet detection, maintenance of the current APNs connection, to solve the old APNs can not maintain connectivity problems.

The new status Code feature also solves this problem: it is not possible to know if the message was successfully delivered from your push system to APNs. Theoretically, you can guarantee that the message is 100% delivered to APNs, because you can know exactly which message arrived at APNs and which is not. It is possible to re-send a specific failure message.

So the first of the above-mentioned spit slots is "not in place" because the SDK provider can now tell you exactly which messages are pushed to APNs and which ones are not.

By the way, the following HTTP/2 are:

HTTP/2 was the first update since the HTTP protocol was released and was approved on February 17, 2015. It adopts a series of optimization techniques to improve the transmission performance of HTTP protocol as a whole, such as asynchronous connection multiplexing, header compression and so on, which is one of the preferred schemes of network hierarchical architecture optimization in current Internet application development.

Apple's attitude towards HTTP/2 was also very positive, and shortly after the May 2015 HTTP/2 was formally published, it was announced to global developers at the WWDC 2015 conference in June that IOS 9 began to support HTTP/2.

And if we want to use HTTP/2, then we must use nsurlsession in the choice of network library.

We all know that HTTP/2 is a multiplexing TCP pipeline connection, and HTTP/2 is also known for its high multiplexing, which also makes the new APNs protocol more performant. (Off-topic: this is also reflected in the nsurlsession for each session is the reuse of multiple task connections.) ）

Universal Push Notification Client SSL Certificate

In development, there is often a piece of content that needs to be pushed to multiple terminals: iOS, TvOS, and OS X devices, and Apple Watch with iOS for push. In the past development, different pushes, need to configure different push certificate: We need to configure: Dev Certificate, prod certificate, VoIP certificate, etc. From December 17, 2015 onwards, only one certificate can be used, no longer require so many certificates, this certificate is called Universal Push Notification Client SSL certificate (hereinafter unified abbreviation: Universal Push Certificate).

Improved, but still needs to be improved. There's still a pit.

APNs does improve a lot, but there is still a need to improve on the place. There is still a pit:

In addition to the complexity of obtaining a TLS certificate is not resolved, there are some pits:

At the beginning of the article, the following is mentioned:

I regret to tell you that your spit is "in place": you will have to endure this anti-human design later.

What happened in the middle of this?

When APNs sent you 4 pushes, but your device network condition is not good, in APNs there, the offline, then APNs to your mobile phone link There are 4 tasks piled up, APNs processing method is, only keep the last message pushed to you, and then tell you the number of pushes. So what about the other three messages? will be discarded by APNs.

There are some apps that do not maintain long connections, are completely push to achieve, and typically, these apps have also taken into account the situation of such a push, the practice is that each time the push is received, and then to their own server to query the current user's unread messages. But APNs also can't guarantee that the four pushes will have at least one App to reach you. It's a pity to tell these apps that this update didn't improve on the pits you suffered.

Why is it so designed? APNs's storage-forwarding capability is too weak, and a lot of message storage and forwarding will consume Apple server resources, either for storage costs or because Apple forwarding is too weak. In short, the result is that APNs never guarantees the rate of a message's reach. And the device does not upload information to the server after it is online.

So the first of the above-mentioned spit slots is "in place" because the SDK provider is still unable to guarantee that the Apns,apns can be pushed to the App.

But Google Cloud messaging has these features. and GCM now supports iOS devices, so APNs and GCM now form a competitive relationship. Let me together look forward to APNs in June 2016 WWDC can have new improvements.

Impact on app Development

To use the new protocol, if you use a third-party push, the most obvious action here is that you must update to the SDK version that supports the new protocol. Because the new protocol requires the SDK to upload the bundle ID of your app, generate topic for each platform push. If you build your own service, you need to upload it yourself. Old protocols are not uploaded.

The new APNs supports a full version of the iOS6, such as 4096 bytes of push content, the old APNs is only 256 bytes before June 14, after which support iOS8 above 2048 bytes. Previously limited to push bytes, such as push article URL, developers choose to exceed 256 after the push ID, and even do not judge the direct push ID, receive and then request the full URL. Push content may be lost once the request is wrong. Now you can avoid it.

How to create a Universal Push Notification Client SSL Certificate

Now that you know what the Universal Push Notification Client SSL certificate is, how do I create it?

Other methods in the diagram are called non-Universal (hereinafter referred to as: non-Universal push certificate):

It is also recommended to use the Universal push certificate for push services. The detailed creation steps are as follows:

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

• Select "All" under the Certificates bar.

• Click the Plus button in the red border.

• After you select Apple Push Notification service SSL (Sandbox & Production) under the Production column, click Next.

• Select the app ID you want from the app ID drop-down menu and click Next.

• The About Creating a Certificate Signing Request (CSR) appears.

• Create the Certificate Signing request according to its instructions.

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

• Download the certificate.

• Double-click to open the certificate, and the Keychain Access tool will start when the certificate is opened.

• In the Keychain Access tool, your certificate appears in certificates, and you select the certificate in the lower-left corner and sign in at the upper-left corner.

Conclusion

For APNs, this update to IOS 9 is epoch-making, please immediately urge your company's server to upgrade or use the SDK to support the new APNs protocol for push services. If there are errors in the text, and please help correct, feedback please send to the microblog @ios program dogs Yuan.

More than 90% of IOS developers in China, the understanding of APNs is wrong