问题
How do iOS "push" notifications get delivered to a particular device without that device needing to poll a server?
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?
回答1:
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..
I suggest reading the documentation for more information and how to use and configure. It's all there.
Push Notifications
回答2:
Each device can be updated with data using their own unique device tokens. This picture explains everything . .
回答3:
I created an infographic to explain the workflow of push notifications. Hope this is helpful.
回答4:
APNs Overview
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.
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.
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.
Figure 1-1 Delivering a remote notification from a provider to an app
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.
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).
Provider Responsibilities
Your provider servers have the following responsibilities for participating with APNs:
- 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.
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.
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.
Figure 1-2 Pushing remote notifications from multiple providers to multiple devices
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.
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.
Security Architecture
APNs enforces end-to-end, cryptographic validation and authentication using two levels of trust: connection trust and device token trust.
Connection trust works between providers and APNs, and between APNs and devices.
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.
APNs can issue a new device token for a variety of reasons:
- 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.
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.
Figure 1-3 illustrates using the HTTP/2-based APNs provider API to establish trust, and using JWT provider authentication tokens for sending notifications.
Figure 1-3 Establishing and using token-based provider connection trust
As shown in Figure 1-3, token-based provider trust works as follows:
Your provider asks for a secure connection with APNs using transport layer security (TLS), represented as the arrow labeled “TLS initiation” in the figure.
APNs then gives your provider an APNs certificate, represented by the next arrow in the figure (labeled “APNs certificate”), which your provider then validates.
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.”
APNs replies to each push, represented in the figure as the arrow labeled “HTTP/2 response.”
For specifics on the responses your provider can receive for this step, see HTTP/2 Response from APNs.
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.
Figure 1-4 Establishing certificate-based provider connection trust
As shown in Figure 1-4, certificate-based provider-to-APNs trust works as follows:
Your provider asks for a secure connection with APNs using transport layer security (TLS), represented as the arrow labeled “TLS initiation” in the figure.
APNs then gives your provider an APNs certificate, represented by the next arrow in the figure (labeled “APNs certificate”), which your provider then validates.
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.”
APNs then validates your provider certificate, thereby confirming that the connection request originated from a legitimate provider, and establishes your TLS connection.
At this point, connection trust is established and your provider server is enabled to send certificate-based remote push notification requests to APNs.
APNs-to-Device Connection Trust and Device Tokens
Trust between APNs and each device is established automatically, without participation by your app, as described in this section.
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.
Figure 1-5 Establishing connection trust between a device and APNs
As shown in Figure 1-5, APNs-to-device trust works as follows:
- 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.
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.
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.
Figure 1-6 Managing the device token
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.
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.
The system delivers the device token back to your app by calling your application:didRegisterForRemoteNotificationsWithDeviceToken: delegate method.
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.
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.
Figure 1-7 Remote notification path from provider to device
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.
Ref: Apple Push Notification Service
Now, look at here to understand technical flow: How to implement Apple Push Notification Service on iOS Application?
回答5:
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.
Apple does not use HTTP protocol for Push notifications but if you understand HTTP Protocol its almost a similar methodology.
http://en.wikipedia.org/wiki/Push_technology#HTTP_server_push
回答6:
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?
来源：https://stackoverflow.com/questions/17262511/how-do-ios-push-notifications-work