ios开发APNs,iOS开发app的个人中心

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 协议了。

参考:

（完）

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" }

iOS APNS远程推送 测试全方案汇总

最近弄了下推送，在测试时遇到了些问题，在此整理汇总了些推送测试相关的方案，并添加了一些补充信息。下方链接是相关文章，感谢各位作者的分享。

debug包和build切换为release直接在手机上跑生成的device token都是开发token。release打包后注册生成的token是生产的。

向证书制作者要推送证书的 p12文件。 双击输入密码。在钥匙串中找到如下。

证书有下方密钥，没有的话证书不可用。

将p12上传的三方平台并填写密码即可。测试推送在这些推送平台填写 设备token等信息即可。

给中台p12文件和密码，协商好消息格式、提供对应环境的token，由中台触发即可。

注意证书分为三种。测试（sanbox）、生产、 测试和生产合并。

如果发送成功，核对 token、证书、中台链接苹果服务器息的地址。是否为统一环境。（苹果的推送服务器也是区分测试和生产的，域名不同，下方脚本中可以看到）

在Xcode11.4之后，模拟器也支持推送测试

具体格式根据你们的产品要求，接入极光或者个推的可以在控制台发一条推送打印出具体格式内容查看,将文件保存后缀为apns，待会要用到

a、查看已启动模拟器

会看到类似下面信息，如果没有请先启动模拟器

b、运行项目在模拟器上后执行相应命令simctl push device [bundle identifier] (json file | -)

示例如下

将第一步创建的json文件内容稍加修改,具体就是添加了"Simulator Target Bundle": "com.app.test"你项目的包名

然后直接拖动文件到模拟器上，出现绿色➕后松手，这样也可以进行推送测试

参考苹果官方文档

Sending Push Notifications Using Command-Line Tools

u;/u

1、在终端新建 shell 文件，这里命名为 push-remote-notification

2、编辑 shell 脚本，这里需要 der 和 pem 证书，如果已经有了 p12 证书，可以通过 openssl 进行转换

运行 shell 脚本

真实脚本事例：

a、p12转der需要先转为pem格式，再从pem转到der格式

openssl pkcs12 -in disPush.p12 -out disPush.pem -nodes

b、pem转der

openssl x509 -outform der -in certificate.pem -out certificate.der

Smart push

git地址：

如果报错

SSL端点域名不能被设置 -25300

Keychain中不能找到证书 -25300

说明钥匙串中没有密钥，要新的p12文件并双击

不推荐，所以不例举，网站风险无法判断。

u;/u 证书转换

u;/u 证书转换

u;/u 证书转换

u;/u

u;/u

u;/u 脚本

u;/u

u;/u 脚本

u;/u 模拟器