iOS 推送通知如何工作？

How do iOS Push Notifications work?

提问by Andy Hin

How do iOS "push" notifications get delivered to a particular device without that device needing to poll a server?

iOS“推送”通知如何发送到特定设备而该设备不需要轮询服务器？

For example, let's say I have received a new message on Facebook. Facebook notifies Apple that my device should receive a notification as such. But how does Apple know which device/IP to push the message to?

例如，假设我在 Facebook 上收到了一条新消息。Facebook 通知 Apple 我的设备应该收到这样的通知。但是 Apple 如何知道将消息推送到哪个设备/IP？

采纳答案by Panama Hyman

It was too much for me to put in a comment so.

对我来说，发表评论太多了。

From the documentation.

从文档中。

Apple Push Notification service (APNs) propagates push notifications to devices having applications registered to receive those notifications. Each device establishes an accredited and encrypted IP connection with the service and receives notifications over this persistent connection. Providers connect with APNs through a persistent and secure channel while monitoring incoming data intended for their client applications. When new data for an application arrives, the provider prepares and sends a notification through the channel to APNs, which pushes the notification to the target device..

Apple 推送通知服务 (APN) 将推送通知传播到已注册应用程序以接收这些通知的设备。每个设备都与服务建立经过认证和加密的 IP 连接，并通过此持久连接接收通知。提供商通过持久且安全的通道与 APN 连接，同时监控用于其客户端应用程序的传入数据。当应用程序的新数据到达时，提供者准备并通过通道向 APNs 发送通知，APNs 将通知推送到目标设备。

I suggest reading the documentation for more information and how to use and configure. It's all there.

我建议阅读文档以获取更多信息以及如何使用和配置。这一切都在那里。

Push Notifications

推送通知

回答by Karan Alangat

Each device can be updated with data using their own unique device tokens. This picture explains everything . .

每个设备都可以使用自己唯一的设备令牌更新数据。这张图说明了一切。.

回答by Udit Agarwal

I created an infographic to explain the workflow of push notifications. Hope this is helpful.

我创建了一个信息图来解释推送通知的工作流程。希望这是有帮助的。

回答by Krunal

APNs Overview

APN 概述

Apple Push Notification service (APNs) is the centerpiece of the remote notifications feature. It is a robust, secure, and highly efficient service for app developers to propagate information to iOS (and, indirectly, watchOS), tvOS, and macOS devices.

Apple 推送通知服务 (APNs) 是远程通知功能的核心。它是一种强大、安全且高效的服务，可供应用程序开发人员将信息传播到 iOS（以及间接的 watchOS）、tvOS 和 macOS 设备。

On initial launch of your app on a user's device, the system automatically establishes an accredited, encrypted, and persistent IP connection between your app and APNs. This connection allows your app to perform setup to enable it to receive notifications, as explained in Configuring Remote Notification Support.

在用户设备上首次启动您的应用程序时，系统会自动在您的应用程序和 APN 之间建立经过认证、加密且持久的 IP 连接。此连接允许您的应用程序执行设置以使其能够接收通知，如配置远程通知支持中所述。

The other half of the connection for sending notifications—the persistent, secure channel between a provider server and APNs—requires configuration in your online developer account and the use of Apple-supplied cryptographic certificates. A provider is a server, that you deploy and manage, that you configure to work with APNs. Figure 1-1 shows the path of delivery for a remote notification.

用于发送通知的另一半连接——提供者服务器和 APNs 之间持久、安全的通道——需要在你的在线开发者帐户中进行配置并使用 Apple 提供的加密证书。提供程序是您部署和管理的服务器，您可以将其配置为与 APN 配合使用。图 1-1 显示了远程通知的传递路径。

Figure 1-1Delivering a remote notification from a provider to an app

图 1-1从提供者向应用程序发送远程通知

With push notification setup complete on your providers and in your app, your providers can then send notification requests to APNs. APNs conveys corresponding notification payloads to each targeted device. On receipt of a notification, the system delivers the payload to the appropriate app on the device, and manages interactions with the user.

在您的提供商和您的应用程序中完成推送通知设置后，您的提供商就可以向 APNs 发送通知请求。APNs 将相应的通知有效载荷传送到每个目标设备。收到通知后，系统会将有效负载传送到设备上的相应应用程序，并管理与用户的交互。

If a notification for your app arrives with the device powered on but with the app not running, the system can still display the notification. If the device is powered off when APNs sends a notification, APNs holds on to the notification and tries again later (for details, see Quality of Service, Store-and-Forward, and Coalesced Notifications).

如果您的应用程序的通知在设备开机但应用程序未运行的情况下到达，系统仍然可以显示通知。如果设备在 APNs 发送通知时关机，APNs 会保留通知并稍后重试（有关详细信息，请参阅服务质量、存储转发和合并通知）。

Provider Responsibilities

提供者的责任

Your provider servers have the following responsibilities for participating with APNs:

您的提供商服务器对参与 APN 负有以下责任：

• Receiving, via APNs, globally-unique, app-specific device tokens and other relevant data from instances of your app on user devices. This allows a provider to know about each running instance of your app.
• Determining, according to the design of your notification system, when remote notifications need to be sent to each device.
• Building and sending notification requests to APNs, each request containing a notification payload and delivery information; APNs then delivers corresponding notifications to the intended devices on your behalf.

• 通过 APNs 从用户设备上的应用实例接收全球唯一的、特定于应用的设备令牌和其他相关数据。这允许提供者了解您的应用程序的每个正在运行的实例。
• 根据通知系统的设计确定何时需要向每个设备发送远程通知。
• 构建通知请求并将其发送到 APNs，每个请求都包含一个通知负载和传递信息；然后，APN 会代表您向目标设备发送相应的通知。

For each remote notification request a provider sends, it must:

对于提供者发送的每个远程通知请求，它必须：

• Construct a JSON dictionary containing the notification's payload, as described in Creating the Remote Notification Payload.
• Add the payload, a globally-unique device token, and other delivery information to an HTTP/2 request. For information about device tokens, see APNs-to-Device Connection Trust and Device Tokens. For information about the HTTP/2 request format, and the possible responses and errors from APNs, see Communicating with APNs.
• Send the HTTP/2 request to APNs, including cryptographic credentials in the form of a token or a certificate, over a persistent, secure channel.
• Establishing this secure channel is described in Security Architecture.

• 构造一个包含通知负载的 JSON 字典，如创建远程通知负载中所述。
• 向 HTTP/2 请求添加有效负载、全球唯一的设备令牌和其他交付信息。有关设备令牌的信息，请参阅 APNs 到设备连接信任和设备令牌。有关 HTTP/2 请求格式以及来自 APN 的可能响应和错误的信息，请参阅与 APN 通信。
• 通过持久、安全的通道将 HTTP/2 请求发送到 APN，包括令牌或证书形式的加密凭据。
• 安全架构中描述了建立此安全通道。

Using Multiple Providers

使用多个提供者

Figure 1-2 depicts the sort of virtual network that APNs enables for the devices running your apps. To handle the notification load, you would typically deploy multiple providers, each one with its own persistent and secure connection to APNs. Each provider can then send notification requests targeting any device for which the provider has a valid device token.

图 1-2 描述了 APNs 为运行您的应用程序的设备启用的虚拟网络类型。为了处理通知负载，您通常会部署多个提供程序，每个提供程序都有自己与 APN 的持久且安全的连接。然后，每个提供商可以发送针对提供商具有有效设备令牌的任何设备的通知请求。

Figure 1-2Pushing remote notifications from multiple providers to multiple devices

图1-2 将远程通知从多个提供者推送到多个设备

Quality of Service, Store-and-Forward, and Coalesced Notifications

服务质量、存储转发和合并通知

Apple Push Notification service includes a Quality of Service (QoS) component that performs a store-and-forward function. If APNs attempts to deliver a notification and the destination device is offline, APNs stores the notification for a limited period of time and delivers it when the device becomes available again. This component stores only the most recent notification per device and per app. If a device is offline, sending a notification request targeting that device causes the previous request to be discarded. If a device remains offline for a long time, all its stored notifications in APNs are discarded.

Apple 推送通知服务包括一个执行存储和转发功能的服务质量 (QoS) 组件。如果 APNs 尝试传递通知并且目标设备处于离线状态，APNs 会将通知存储一段有限的时间，并在设备再次可用时传递它。此组件仅存储每个设备和每个应用程序的最新通知。如果设备处于离线状态，发送针对该设备的通知请求会导致之前的请求被丢弃。如果设备长时间处于离线状态，则其在 APN 中存储的所有通知都将被丢弃。

To allow the coalescing of similar notifications, you can include a collapse identifier within a notification request. Normally, when a device is online, each notification request that you send to APNs results in a notification delivered to the device. However, when the apns-collapse-id key is present in your HTTP/2 request header, APNs coalesces requests whose value for that key is the same. For example, a news service that sends the same headline twice could use the same collapse identifier value for both requests. APNs would then coalesce the two requests into a single notification for delivery to the device. For details on the apns-collapse-id key.

要允许合并类似的通知，您可以在通知请求中包含折叠标识符。通常，当设备在线时，您发送到 APNs 的每个通知请求都会导致向设备发送通知。但是，当 apns-collapse-id 键出现在您的 HTTP/2 请求标头中时，APNs 会合并该键值相同的请求。例如，两次发送相同标题的新闻服务可以对两个请求使用相同的折叠标识符值。然后，APN 会将这两个请求合并为一个通知，以便传送到设备。有关 apns-collapse-id 键的详细信息。

Security Architecture

安全架构

APNs enforces end-to-end, cryptographic validation and authentication using two levels of trust: connection trust and device token trust.

APNs 使用两个信任级别来强制执行端到端的加密验证和身份验证：连接信任和设备令牌信任。

Connection trust works between providers and APNs, and between APNs and devices.

连接信任在提供者和 APN 之间以及 APN 和设备之间起作用。

Device token trust works end-to-end for each remote notification. It ensures that notifications are routed only between the correct start (provider) and end (device) points.

设备令牌信任对每个远程通知都是端到端的。它确保通知仅在正确的开始（提供者）和结束（设备）点之间路由。

A device token is an opaque NSData instance that contains a unique identifier assigned by Apple to a specific app on a specific device. Only APNs can decode and read the contents of a device token. Each app instance receives its unique device token when it registers with APNs, and must then forward the token to its provider, as described in Configuring Remote Notification Support. The provider must include the device token in each push notification request that targets the associated device; APNs uses the device token to ensure the notification is delivered only to the unique app-device combination for which it is intended.

设备令牌是一个不透明的 NSData 实例，其中包含 Apple 分配给特定设备上的特定应用程序的唯一标识符。只有 APN 可以解码和读取设备令牌的内容。每个应用实例在向 APN 注册时都会收到其唯一的设备令牌，然后必须将令牌转发给其提供者，如配置远程通知支持中所述。提供者必须在针对关联设备的每个推送通知请求中包含设备令牌；APNs 使用设备令牌来确保通知仅传递给它预期的唯一应用程序-设备组合。

APNs can issue a new device token for a variety of reasons:

APN 可以出于多种原因发布新的设备令牌：

• User installs your app on a new device
• User restores device from a backup
• User reinstalls the operating system
• Other system-defined events

• 用户在新设备上安装您的应用
• 用户从备份中恢复设备
• 用户重新安装操作系统
• 其他系统定义的事件

As a result, apps must request the device token at launch time, as described in APNs-to-Device Connection Trust and Device Tokens. For code examples, see Registering to Receive Remote Notifications.

因此，应用程序必须在启动时请求设备令牌，如 APNs 到设备连接信任和设备令牌中所述。有关代码示例，请参阅注册以接收远程通知。

To establish HTTP/2-based TLS sessions with APNs, you must ensure that a GeoTrust Global CA root certificate is installed on each of your providers. If a provider is running macOS, this root certificate is in the keychain by default. On other systems, this certificate might require explicit installation. You can download this certificate from the GeoTrust Root Certificates website. Here is a direct link to the certificate.

要使用 APN 建立基于 HTTP/2 的 TLS 会话，您必须确保在每个提供程序上安装 GeoTrust Global CA 根证书。如果提供程序运行 macOS，则默认情况下此根证书位于钥匙串中。在其他系统上，此证书可能需要显式安装。您可以从 GeoTrust 根证书网站下载此证书。这是证书的直接链接。

Figure 1-3 illustrates using the HTTP/2-based APNs provider API to establish trust, and using JWT provider authentication tokens for sending notifications.

图 1-3 说明了使用基于 HTTP/2 的 APNs 提供者 API 来建立信任，以及使用 JWT 提供者身份验证令牌发送通知。

Figure 1-3Establishing and using token-based provider connection trust

图1-3建立和使用基于令牌的提供者连接信任

As shown in Figure 1-3, token-based provider trust works as follows:

如图 1-3 所示，基于令牌的提供者信任的工作原理如下：

Your provider asks for a secure connection with APNs using transport layer security (TLS), represented as the arrow labeled “TLS initiation” in the figure.

您的提供商要求使用传输层安全性 (TLS) 与 APN 建立安全连接，如图中标有“TLS 启动”的箭头所示。

APNs then gives your provider an APNs certificate, represented by the next arrow in the figure (labeled “APNs certificate”), which your provider then validates.

然后，APNs 为您的提供商提供一个 APNs 证书，由图中的下一个箭头表示（标记为“APNs 证书”），然后您的提供商对其进行验证。

At this point, connection trust is established and your provider server is enabled to send token-based remote push notification requests to APNs. Each notification request that your provider sends must be accompanied by a JWT authentication token, represented in the figure as the arrow labeled “Notification push.”

此时，连接信任已建立，您的提供者服务器已启用向 APN 发送基于令牌的远程推送通知请求。您的提供者发送的每个通知请求都必须附带一个 JWT 身份验证令牌，如图中标记为“通知推送”的箭头所示。

APNs replies to each push, represented in the figure as the arrow labeled “HTTP/2 response.”

APNs 回复每个推送，在图中用标有“HTTP/2 响应”的箭头表示。

For specifics on the responses your provider can receive for this step, see HTTP/2 Response from APNs.

有关您的提供商在此步骤中可以收到的响应的详细信息，请参阅来自 APNs 的 HTTP/2 响应。

Figure 1-4 illustrates the use of an Apple-issued SSL certificate to establish trust between a provider and APNs. Unlike Figure 1-3, this figure does not show a notification push itself, but stops at the establishment of a Transport Layer Security (TLS) connection. In the certificate-based trust scheme, push notification requests are not authenticated but they are validated using the accompanying device token.

图 1-4 说明了使用 Apple 颁发的 SSL 证书在提供商和 APN 之间建立信任。与图 1-3 不同，该图并未显示通知推送本身，而是在传输层安全 (TLS) 连接建立时停止。在基于证书的信任方案中，推送通知请求未经身份验证，但使用随附的设备令牌进行验证。

Figure 1-4Establishing certificate-based provider connection trust

图1-4建立基于证书的提供者连接信任

As shown in Figure 1-4, certificate-based provider-to-APNs trust works as follows:

如图 1-4 所示，基于证书的 provider-to-APNs 信任的工作原理如下：

Your provider asks for a secure connection with APNs using transport layer security (TLS), represented as the arrow labeled “TLS initiation” in the figure.

您的提供商要求使用传输层安全性 (TLS) 与 APN 建立安全连接，如图中标有“TLS 启动”的箭头所示。

APNs then gives your provider an APNs certificate, represented by the next arrow in the figure (labeled “APNs certificate”), which your provider then validates.

然后，APNs 为您的提供商提供一个 APNs 证书，由图中的下一个箭头表示（标记为“APNs 证书”），然后您的提供商对其进行验证。

Your provider must then send its Apple-provisioned provider certificate (which you have previously obtained from your online developer account, as explained in “Generate a universal APNs client SSL certificate” in Xcode Help) back to APNs, represented as the arrow labeled “Provider certificate.”

然后，您的提供商必须将其 Apple 提供的提供商证书（您之前从在线开发者帐户中获得，如 Xcode 帮助中的“生成通用 APNs 客户端 SSL 证书”中所述）发送回 APN，如标有“提供商”的箭头所示证书。”

APNs then validates your provider certificate, thereby confirming that the connection request originated from a legitimate provider, and establishes your TLS connection.

APNs 然后验证您的提供商证书，从而确认连接请求来自合法提供商，并建立您的 TLS 连接。

At this point, connection trust is established and your provider server is enabled to send certificate-based remote push notification requests to APNs.

此时，连接信任已建立，您的提供者服务器已启用向 APN 发送基于证书的远程推送通知请求。

APNs-to-Device Connection Trust and Device Tokens

APNs 到设备连接信任和设备令牌

Trust between APNs and each device is established automatically, without participation by your app, as described in this section.

APNs 和每个设备之间的信任是自动建立的，无需您的应用程序参与，如本节所述。

Each device has a cryptographic certificate and a private cryptographic key, provided by the operating system at initial device activation and stored in the device's keychain. During activation, APNs authenticates and validates the connection to the device, based on the certificate and key, as shown in Figure 6-5.

每个设备都有一个加密证书和一个私有加密密钥，由操作系统在初始设备激活时提供并存储在设备的钥匙串中。在激活过程中，APNs 根据证书和密钥对与设备的连接进行身份验证和验证，如图 6-5 所示。

Figure 1-5Establishing connection trust between a device and APNs

图1-5建立设备与APN的连接信任

As shown in Figure 1-5, APNs-to-device trust works as follows:

如图1-5所示，APNs-to-device信任的工作原理如下：

• Trust negotiation begins when the device initiates a TLS connection with APNs, as shown in the top arrow in the figure.
• APNs returns an APNs certificate to the device.
• The operating system validates this certificate and then, as shown in the “Device certificate” arrow, sends the device certificate to APNs.
• Finally, as indicated by the bottom arrow in the figure, APNs validates the device certificate, establishing trust.
• With a TLS connection established between APNs and the device, apps on the device can register with APNs to receive their app-specific device tokens for remote notifications. For details and code examples, see Registering to Receive Remote Notifications in Configuring Remote Notification Support.

• 当设备发起与 APNs 的 TLS 连接时，信任协商开始，如图中顶部箭头所示。
• APNs 向设备返回一个 APNs 证书。
• 操作系统验证此证书，然后如“设备证书”箭头所示，将设备证书发送到 APNs。
• 最后，如图中底部箭头所示，APNs 验证设备证书，建立信任。
• 通过在 APNs 和设备之间建立 TLS 连接，设备上的应用程序可以向 APNs 注册以接收其特定于应用程序的设备令牌以进行远程通知。有关详细信息和代码示例，请参阅配置远程通知支持中的注册接收远程通知。

After receiving the device token, an app must connect to the app's associated provider and forward the token to it. This step is necessary because a provider must include the device token later when it sends a notification request, to APNs, targeting the device. The code you write for forwarding the token is also shown in Registering to Receive Remote Notifications.

收到设备令牌后，应用程序必须连接到应用程序的关联提供程序并将令牌转发给它。此步骤是必要的，因为提供程序稍后在向 APN 发送通知请求时必须包含设备令牌，以设备为目标。您编写的用于转发令牌的代码也显示在注册接收远程通知中。

Whether a user is activating a device for the first time, or whether APNs has issued a new device token, the process is similar and is shown in Figure 6-6.

无论是用户第一次激活设备，还是APNs发布了新的设备令牌，过程都类似，如图6-6所示。

Figure 1-6Managing the device token

图1-6管理设备令牌

Obtaining and handling an app-specific device token works as follows:

获取和处理特定于应用程序的设备令牌的工作方式如下：

Your app registers with APNs for remote notifications, as shown in the top arrow. If the app is already registered and the app-specific device token has not changed, the system quickly returns the existing token to the app and this process skips to step 4.

您的应用向 APN 注册以获取远程通知，如顶部箭头所示。如果应用程序已经注册并且应用程序特定的设备令牌没有改变，系统会快速将现有令牌返回给应用程序，此过程跳到步骤4。

When a new device token is needed, APNs generates one using information contained in the device's certificate. It encrypts the token using a token key and returns it to the device, as shown in the middle, right-pointing arrow.

当需要新的设备令牌时，APN 会使用设备证书中包含的信息生成一个。它使用令牌密钥加密令牌并将其返回给设备，如中间的向右箭头所示。

The system delivers the device token back to your app by calling your application:didRegisterForRemoteNotificationsWithDeviceToken: delegate method.

系统通过调用您的应用程序：didRegisterForRemoteNotificationsWithDeviceToken: 委托方法将设备令牌传递回您的应用程序。

Upon receiving the token, your app (within the delegate method) must forward it to your provider in either binary or hexadecimal format. Your provider cannot send notifications to the device without this token. For details, see Registering to Receive Remote Notifications in Configuring Remote Notification Support.

收到令牌后，您的应用程序（在委托方法中）必须以二进制或十六进制格式将其转发给您的提供者。如果没有此令牌，您的提供商无法向设备发送通知。有关详细信息，请参阅配置远程通知支持中的注册接收远程通知。

IMPORTANT

重要的

APNs device tokens are of variable length. Do not hard-code their size.

APNs 设备令牌的长度可变。不要硬编码它们的大小。

When your provider sends a push notification request to APNs, it includes a device token that identifies a unique app-device combination. This step is shown in the “Token, Payload” arrow between the provider and APNs in Figure 6-7. APNs decrypts the token to ensure the validity of the request and to determine the target device. If APNs determines that the sender and recipient are legitimate, it then sends the notification to the identified device.

当您的提供者向 APNs 发送推送通知请求时，它包含一个设备令牌，用于标识唯一的应用程序-设备组合。这一步如图 6-7 中提供者和 APNs 之间的“Token, Payload”箭头所示。APNs 解密令牌以确保请求的有效性并确定目标设备。如果 APNs 确定发件人和收件人是合法的，则它会将通知发送到已识别的设备。

Figure 1-7Remote notification path from provider to device

图1-7提供者到设备的远程通知路径

After the device receives the notification (and after the final step shown in Figure 1-7), the system forwards the remote notification to your app.

设备收到通知后（以及图 1-7 所示的最后一步之后），系统会将远程通知转发给您的应用。

Ref: Apple Push Notification Service

参考：Apple 推送通知服务

Now, look at here to understand technical flow: How to implement Apple Push Notification Service on iOS Application?

现在，看这里了解技术流程：如何在 iOS 应用程序上实现 Apple 推送通知服务？

回答by user4248688

Device does not keep polling the server for the push notifications.

设备不会不断轮询服务器以获取推送通知。

To keep it simple, consider an iPhone is connected to internet. On connecting to internet iPhone establishes connection to Apple Push Notifications server this connection is open connection which means data can be thrown to iPhone from server the moment data arrives to server.

为简单起见，假设 iPhone 已连接到互联网。在连接到互联网时，iPhone 会建立与 Apple 推送通知服务器的连接，此连接是开放式连接，这意味着数据可以在数据到达服务器的那一刻从服务器抛出到 iPhone。

Apple does not use HTTP protocol for Push notifications but if you understand HTTP Protocol its almost a similar methodology.

Apple 不使用 HTTP 协议进行推送通知，但如果您了解 HTTP 协议，它几乎是一种类似的方法。

http://en.wikipedia.org/wiki/Push_technology#HTTP_server_push

http://en.wikipedia.org/wiki/Push_technology#HTTP_server_push

回答by Tarek

There is a really nice exaplanation of push notifications in this article.

在这篇文章中有一个非常好的推送通知解释。

In iOS, apps can't do a lot in the background. Apps are only allowed to do limited set of activities so battery life is conserved.

But what if something interesting happens and you wish to let the user know about this, even if they're not currently using your app?

在 iOS 中，应用程序不能在后台做很多事情。应用程序只能执行有限的一组活动，以节省电池寿命。

但是，如果发生了一些有趣的事情并且您希望让用户知道这一点，即使他们当前没有使用您的应用程序，该怎么办？