iOS 必知必会 - APNs篇

导语：

在鹿城等地区，都构建了全面的区域性战略布局，加强发展的系统性、市场前瞻性、产品创新能力，以专注、极致的服务理念，为客户提供成都网站建设、网站建设 网站设计制作按需求定制开发,公司网站建设,企业网站建设,品牌网站设计,全网营销推广,外贸营销网站建设,鹿城网站建设费用合理。

由于移动设备内存、CPU、电量的局限性，iOS 不允许 APP 的进程常驻后台（事实上可以申请后台运行一段时间，最长约 10 分钟），这样当用户主动杀掉 APP，或者 APP 进入后台超过约定时长时，就意味着该 APP 进程的结束。这在很大程度上保障了前台 APP 的流畅性，也延长了手机的使用时长，获得了较好的用户体验。但是这也意味着，服务器无法主动和用户交互（如推送实时消息等）。为了解决这个限制，苹果推出了 APNs，允许设备和服务器分别与苹果的推送通知服务器保持长连接状态。

iOS 的通知分为本地通知和远程通知。本地通知是由本地应用触发的，一般是基于时间的一种通知形式，如闹钟、待办事件等的提醒。远程通知是由开发商通过自己的服务器推送的一种通知形式，而 APNs 就是远程通知功能的核心。

关于远程推送，记住以下两点就够了：

这里就很清楚了，其实 APNs 的本质就是 服务器和客户端之间的中介 。当服务器需要给客户端推送消息时，先将消息发送给苹果服务器，再由苹果服务器找到对应设备推送下去。

那为什么还要走中介，不直接发送呢？因为这样做一个设备（即所有 APP ）只需要和苹果的服务器建立一条长连接，而不需要每个 APP 都和服务器建立一条长连接。

可能有些人还是不太明白 APNs 的意义，觉得也只是将多个长连接变成了统一的一个长连接而已，有必要那么做吗？

很有必要！

我们来看下 Android 的推送现状就明白了。

Android 事实上也有类似于 APNs 的一套用于推送的服务，简称 GCM，即 Google Cloud Messaging。但由于 GCM 需要谷歌服务器的支持，在国内由于「墙」的原因基本不能使用。这下就热闹了，国内出现了一大堆第三方推送服务商，如华为推送、小米推送、极光推送等。APP 通过集成这些推送服务来实现推送功能，而这些推送服务为了保持自己的长连接不被杀死，采用了各种保活、唤醒手段，这也是 Android 手机使用不流畅的真凶。之前也有看到「 工信部要求国内安卓统一消息推送标准 」的新闻，工信部都这么重视，可见统一推送的意义非凡。

想要了解具体区别，可以参考这篇文章 「 国内 90%以上的 iOS 开发者，对 APNs 的认识都是错的 」。

不言而喻，当然是尽早升级 HTTP/2 协议了。

参考:

（完）

APNs Development iOS、Apple Push Services、iOS Distribution、iOS Development区别

APNs Development iOS ：开发环境下的推送证书。APP接入个推、极光实现推送功能时，需要这两个环境下的证书，不过证书要在keychain中生成p12文件才可被个推、极光识别。

Apple Push Services :生产环境下的推送证书。APP接入个推、极光实现推送功能时，需要这两个环境下的证书，不过证书要在keychain中生成p12文件才可被个推、极光识别。

iOS Distribution :生产证书。把app的ipa包上传到AppStoreConnect审核会用到发布证书

iOS Development :开发证书。真机调试、发包测试会用到开发证书

iOS的APNs

Communicating with APNs

The APNs provider API lets you send remote notifications to your app on iOS, tvOS, and macOS devices, and to Apple Watch via iOS. The API is based on the HTTP/2 network protocol. Each interaction starts with a POST request, containing a JSON payload, that you send from your provider server to APNs. APNs then forwards the notification to your app on a specific user device.

Provider Authentication Tokens

To securely connect to APNs, you can use provider authentication tokens or provider certificates. This section describes connections using tokens.

The provider API supports the JSON Web Token (JWT) specification, letting you pass statements and metadata, called claims, to APNs, along with each push notification. For details, refer to the specification at . For additional information about JWT, along with a list of available libraries for generating signed JWTs, see

A provider authentication token is a JSON object that you construct, whose header must include:

*The encryption algorithm (alg) you use to encrypt the token

*A 10-character key identifier (kid) key, obtained from your developer account

The claims payload of the token must include:

The issuer (iss) registered claim key, whose value is your 10-character Team ID, obtained from your developer account

The issued at (iat) registered claim key, whose value indicates the time at which the token was generated, in terms of the number of seconds since Epoch, in UTC

After you create the token, you must sign it with a private key. You must then encrypt the token using the Elliptic Curve Digital Signature Algorithm (ECDSA) with the P-256 curve and the SHA-256 hash algorithm. Specify the value ES256 in the algorithm header key (alg). For information on how to configure your token, search Xcode help for the phrase “Configure push notifications.”

A decoded JWT provider authentication token for APNs has the following format:

{    

"alg": "ES256",   

"kid": "ABC123DEFG"

}

{   

"iss": "DEF123GHIJ",    

"iat": 1437179036 

}

NOTE

APNs supports only provider authentication tokens that are signed with the ES256 algorithm. Unsecured JWTs, or JWTs signed with other algorithms, are rejected, and your provider server receives the InvalidProviderToken (403) response.

To ensure security, APNs requires new tokens to be generated periodically. A new token has an updated issued at claim key, whose value indicates the time the token was generated. If the timestamp for token issue is not within the last hour, APNs rejects subsequent push messages, returning an ExpiredProviderToken (403) error.

If you suspect your provider token signing key is compromised, you can revoke it from your developer account. You can issue a new key pair and can then generate new tokens with the new private key. For maximum security, close all your connections to APNs that had been using tokens signed with the now-revoked key, and reconnect before using tokens signed with the new key.

APNs Provider Certificates

Your APNs provider certificate, which you obtain as explained in "Configure push notifications” in Xcode help, enables connection to both the APNs Production and Development environments.

You can use your APNs certificate to send notifications to your primary app, as identified by its bundle ID, as well as to any Apple Watch complications or backgrounded VoIP services associated with that app. Use the ( 1.2.840.113635.100.6.3.6 ) extension in the certificate to identify the topics for your push notifications. For example, if you provide an app with the bundle ID com.yourcompany.yourexampleapp, you can specify the following topics in the certificate:

Extension ( 1.2.840.113635.100.6.3.6 )

Critical NO

Data com.yourcompany.yourexampleapp

Data app

Data com.yourcompany.yourexampleapp.voip

Data voip

Data com.yourcompany.yourexampleapp.complication

Data complication

APNs Connections

The first step in sending a remote notification is to establish a connection with the appropriate APNs server:

Development server: api.development.push.apple.com:443

Production server: api.push.apple.com:443

NOTE

You can alternatively use port 2197 when communicating with APNs. You might do this, for example, to allow APNs traffic through your firewall but to block other HTTPS traffic.

Your provider server must support TLS 1.2 or higher when connecting to APNs. You can use the provider client certificate which you obtain from your developer account, as described in Creating a Universal Push Notification Client SSL Certificate.

To connect without an APNs provider certificate, you must instead create a provider authentication token, signed with the key provisioned through your developer account (see “Configure push notifications” in Xcode help). After you have this token, you can start to send push messages. You must then periodically update the token; each APNs provider authentication token has validity interval of one hour.

APNs allows multiple concurrent streams for each connection. The exact number of streams differs based on your use of a provider certificate or an authentication token, and also differs based on server load. Do not assume a specific number of streams.

When establishing a connection to APNs using a token rather than a certificate, only one stream is allowed on the connection until you send a push message with valid provider authentication token. APNs ignores HTTP/2 PRIORITY frames, so do not send them on your streams.

Best Practices for Managing Connections

Keep your connections with APNs open across multiple notifications; do not repeatedly open and close connections. APNs treats rapid connection and disconnection as a denial-of-service attack. You should leave a connection open unless you know it will be idle for an extended period of time—for example, if you only send notifications to your users once a day, it is acceptable practice to use a new connection each day.

Do not generate a new provider authentication token for each push request that you send. After you obtain a token, continue to use it for all your push requests during the token’s period of validity, which is one full hour.

You can establish multiple connections to APNs servers to improve performance. When you send a large number of remote notifications, distribute them across connections to several server endpoints. This improves performance, compared to using a single connection, by letting you send remote notifications faster and by letting APNs deliver them faster.

If your provider certificate is revoked, or if the key you are using to sign provider tokens is revoked, close all existing connections to APNs and then open new connections.

You can check the health of your connection using an HTTP/2 PING frame.

Terminating an APNs Connection

If APNs decides to terminate an established HTTP/2 connection, it sends a GOAWAY frame. The GOAWAY frame includes JSON data in its payload with a reason key, whose value indicates the reason for the connection termination. For a list of possible values for the reason key, see Table 8-6.

Normal request failures do not result in termination of a connection.

APNs Notification APIThe APNs Provider API consists of a request and a response that you configure and send using an HTTP/2 POST command. You use the request to send a push notification to the APNs server and use the response to determine the results of that request.

HTTP/2 Request to APNs

Use a request to send a notification to a specific user device.

Table 8-1HTTP/2 request fields

Name     |Value

:method |POST

:path      |/3/device/device-token

For thedevice-token parameter, specify the hexadecimal bytes of the device token for the target device.

APNs requires the use of HPACK (header compression for HTTP/2), which prevents repeated header keys and values. APNs maintains a small dynamic table for HPACK. To help avoid filling up the APNs HPACK table and necessitating the discarding of table data, encode headers in the following way—especially when sending a large number of streams:

The :path value should be encoded as a literal header field without indexing

The authorization request header, if present, should be encoded as a literal header field without indexing

The appropriate encoding to employ for the apns-id, apns-expiration, and apns-collapse-id request headers differs depending on whether it is part of the initial or a subsequent POST operation, as follows:

The first time you send these headers, encode them with incremental indexing to allow the header names to be added to the dynamic table

Subsequent times you send these headers, encode them as literal header fields without indexing

Encode all other headers as literal header fields with incremental indexing. For specifics on header encoding, see tools.ietf.org/html/rfc7541#section-6.2.1 and tools.ietf.org/html/rfc7541#section-6.2.2.

APNs ignores request headers other than the ones listed in Table 8-2.

Table 8-2APNs request headers

Header          |Description

authorization |The provider token that authorizes APNs to send push notifications for the specified topics. The token is in Base64URL-encoded JWT format, specified as bearerprovider token.

                   |When the provider certificate is used to establish a connection, this request header is ignored.

apns-id         |A canonical UUID that identifies the notification. If there is an error sending the notification, APNs uses this value to identify the notification to your server.

                   |The canonical form is 32 lowercase hexadecimal digits, displayed in five groups separated by hyphens in the form 8-4-4-4-12. An example UUID is as follows:

                   |123e4567-e89b-12d3-a456-42665544000

                   |If you omit this header, a new UUID is created by APNs and returned in the response.

apns-expiration  | A UNIX epoch date expressed in seconds (UTC). This header identifies the date when the notification is no longer valid and can be discarded.If this value is nonzero, APNs stores the notification and tries to deliver it at least once, repeating the attempt as needed if it is unable to deliver the notification the first time. If the value is 0, APNs treats the notification as if it expires immediately and does not store the notification or attempt to redeliver it.

apns-priority  | The priority of the notification. Specify one of the following values:10–Send the push message immediately. Notifications with this priority must trigger an alert, sound, or badge on the target device. It is an error to use this priority for a push notification that contains only the content-available key.5—Send the push message at a time that takes into account power considerations for the device. Notifications with this priority might be grouped and delivered in bursts. They are throttled, and in some cases are not delivered.

                   | If you omit this header, the APNs server sets the priority to 10.

apns-topic    |The topic of the remote notification, which is typically the bundle ID for your app. The certificate you create in your developer account must include the capability for this topic.If your certificate includes multiple topics, you must specify a value for this header.If you omit this request header and your APNs certificate does not specify multiple topics, the APNs server uses the certificate’s Subject as the default topic.If you are using a provider token instead of a certificate, you must specify a value for this request header. The topic you provide should be provisioned for the your team named in your developer account.

apns-collapse-id  | Multiple notifications with the same collapse identifier are displayed to the user as a single notification. The value of this key must not exceed 64 bytes. For more information, see Quality of Service, Store-and-Forward, and Coalesced Notifications.

The body content of your message is the JSON dictionary object for your notification’s payload. The body data must not be compressed and its maximum size is 4KB (4096 bytes). For a Voice over Internet Protocol (VoIP) notification, the body data maximum size is 5KB (5120 bytes). For information about the keys and values to include in the body content, see Payload Key Reference.

HTTP/2 Response from APNs

The response to a request has the format listed in Table 8-3.

Table 8-3APNs response headers

Header name Value

apns-id  | The apns-id value from the request. If no value was included in the request, the server creates a new UUID and returns it in this header.

:status  | The HTTP status code. For a list of possible status codes, see Table 8-4.

Table 8-4 lists the possible status codes for a request. These values are included in the :status header of the response.

Table 8-4Status codes for an APNs responseStatus codeDescription200Success400Bad request403There was an error with the certificate or with the provider authentication token405The request used a bad :method value. Only POST requests are supported.410The device token is no longer active for the topic.413The notification payload was too large.429The server received too many requests for the same device token.500Internal server error503The server is shutting down and unavailable.

For a successful request, the body of the response is empty. On failure, the response body contains a JSON dictionary with the keys listed in Table 8-5. This JSON data might also be included in the GOAWAY frame when a connection is terminated.Table 8-5APNs JSON data keysKeyDescriptionreasonThe error indicating the reason for the failure. The error code is specified as a string.

For a list of possible values, see Table 8-6.timestampIf the value in the :status header is 410, the value of this key is the last time at which APNs confirmed that the device token was no longer valid for the topic.Stop pushing notifications until the device registers a token with a later timestamp with your provider.Table 8-6 lists the possible error codes included in the reason key of a response’s JSON payload.Table 8-6Values for the APNs JSON reason keyStatus codeError stringDescription400BadCollapseIdThe collapse identifier exceeds the maximum allowed size400BadDeviceTokenThe specified device token was bad. Verify that the request contains a valid token and that the token matches the environment.400BadExpirationDateThe apns-expiration value is bad.400BadMessageIdThe apns-id value is bad.400BadPriorityThe apns-priority value is bad.400BadTopicThe apns-topic was invalid.400DeviceTokenNotForTopicThe device token does not match the specified topic.400DuplicateHeadersOne or more headers were repeated.400IdleTimeoutIdle time out.400MissingDeviceTokenThe device token is not specified in the request :path. Verify that the :path header contains the device token.400MissingTopicThe apns-topic header of the request was not specified and was required. The apns-topic header is mandatory when the client is connected using a certificate that supports multiple topics.400PayloadEmptyThe message payload was empty.400TopicDisallowedPushing to this topic is not allowed.403BadCertificateThe certificate was bad.403BadCertificateEnvironmentThe client certificate was for the wrong environment.403ExpiredProviderTokenThe provider token is stale and a new token should be generated.403ForbiddenThe specified action is not allowed.403InvalidProviderTokenThe provider token is not valid or the token signature could not be verified.403MissingProviderTokenNo provider certificate was used to connect to APNs and Authorization header was missing or no provider token was specified.404BadPathThe request contained a bad :path value.405MethodNotAllowedThe specified :method was not POST.410UnregisteredThe device token is inactive for the specified topic.Expected HTTP/2 status code is 410; see Table 8-4.413PayloadTooLargeThe message payload was too large. See Creating the Remote Notification Payload for details on maximum payload size.429TooManyProviderTokenUpdatesThe provider token is being updated too often.429TooManyRequestsToo many requests were made consecutively to the same device token.500InternalServerErrorAn internal server error occurred.503ServiceUnavailableThe service is unavailable.503ShutdownThe server is shutting down.

HTTP/2 Request/Response Examples for APNs

Listing 8-1 shows a sample request constructed for a provider certificate.Listing 8-1Sample request for a certificate with a single topicHEADERS  - END_STREAM  + END_HEADERS  :method = POST  :scheme = https  :path = /3/device/00fc13adff785122b4ad28809a3420982341241421348097878e577c991de8f0  host = api.development.push.apple.com  apns-id = eabeae54-14a8-11e5-b60b-1697f925ec7b  apns-expiration = 0  apns-priority = 10DATA  + END_STREAM    { "aps" : { "alert" : "Hello" } }

Listing 8-2 shows a sample request constructed for a provider authentication token.Listing 8-2Sample request for a provider authentication tokenHEADERS  - END_STREAM  + END_HEADERS  :method = POST  :scheme = https  :path = /3/device/00fc13adff785122b4ad28809a3420982341241421348097878e577c991de8f0  host = api.development.push.apple.com  authorization = bearer eyAia2lkIjogIjhZTDNHM1JSWDciIH0.eyAiaXNzIjogIkM4Nk5WOUpYM0QiLCAiaWF0I jogIjE0NTkxNDM1ODA2NTAiIH0.MEYCIQDzqyahmH1rz1s-LFNkylXEa2lZ_aOCX4daxxTZkVEGzwIhALvkClnx5m5eAT6 Lxw7LZtEQcH6JENhJTMArwLf3sXwi  apns-id = eabeae54-14a8-11e5-b60b-1697f925ec7b  apns-expiration = 0  apns-priority = 10  apns-topic =DATA  + END_STREAM    { "aps" : { "alert" : "Hello" } }Listing 8-3 shows a sample request constructed for a certificate that contains multiple topics.

Listing 8-3Sample request for a certificate with multiple topicsHEADERS  - END_STREAM  + END_HEADERS  :method = POST  :scheme = https  :path = /3/device/00fc13adff785122b4ad28809a3420982341241421348097878e577c991de8f0  host = api.development.push.apple.com  apns-id = eabeae54-14a8-11e5-b60b-1697f925ec7b  apns-expiration = 0  apns-priority = 10  apns-topic =DATA  + END_STREAM    { "aps" : { "alert" : "Hello" } }

Listing 8-4 shows a sample response for a successful push request.Listing 8-4Sample response for a successful requestHEADERS  + END_STREAM  + END_HEADERS  apns-id = eabeae54-14a8-11e5-b60b-1697f925ec7b  :status = 200

Listing 8-5 shows a sample response when an error occurs.Listing 8-5Sample response for a request that encountered an errorHEADERS  - END_STREAM  + END_HEADERS  :status = 400  content-type = application/json    apns-id:DATA

+ END_STREAM

{ "reason" : "BadDeviceToken" }