iOSプッシュ通知はどのように機能しますか？
IOSの「プッシュ」通知を特定のデバイスに配信するには、そのデバイスがサーバーをポーリングする必要はありませんか？
たとえば、Facebookで新しいメッセージを受信したとします。 FacebookはAppleに、デバイスがそのような通知を受信する必要があることを通知します。しかし、Appleはどのようにメッセージをプッシュするデバイス/ IPを知るのでしょうか？
コメントを入れるのは多すぎました。
ドキュメントから。
Appleプッシュ通知サービス（APN）は、プッシュ通知を、それらの通知を受信するためにアプリケーションが登録されているデバイスに伝達します。各デバイスは、サービスとの認定および暗号化されたIP接続を確立し、この永続的な接続を介して通知を受け取ります。プロバイダーは、クライアントアプリケーション向けの着信データを監視しながら、永続的で安全なチャネルを通じてAPNsに接続します。アプリケーションの新しいデータが到着すると、プロバイダーは通知を準備し、APNにチャネル経由で通知を送信します。APNは通知をターゲットデバイスにプッシュします。
詳細および使用方法と設定方法については、ドキュメントを読むことをお勧めします。それがすべてです。
各デバイスは、固有のデバイストークンを使用してデータで更新できます。この写真はすべてを説明します。 。
プッシュ通知のワークフローを説明するインフォグラフィックを作成しました。これが役に立てば幸いです。
デバイスは、プッシュ通知のためにサーバーをポーリングし続けません。
シンプルに保つために、iPhoneがインターネットに接続されていると考えてください。インターネットに接続すると、iPhoneはApple Push Notificationsサーバーへの接続を確立します。この接続はオープン接続であり、データがサーバーに到着した瞬間にサーバーからiPhoneにデータをスローできます。
Appleはプッシュ通知にHTTPプロトコルを使用しませんが、HTTPプロトコルを理解している場合、ほぼ同様の方法論です。
http://en.wikipedia.org/wiki/Push_technology#HTTP_server_Push
APNの概要
Appleプッシュ通知サービス（APN）は、リモート通知機能の中核です。これは、アプリ開発者がiOS（および間接的にwatchOS）、tvOS、およびmacOSデバイスに情報を伝達するための、堅牢で安全で非常に効率的なサービスです。
ユーザーのデバイスでアプリを最初に起動すると、システムはアプリとAPNsの間で認定され暗号化された永続的なIP接続を自動的に確立します。リモート接続のサポートの構成で説明されているように、この接続により、アプリはセットアップを実行して通知を受信できるようになります。
通知を送信するための接続の残りの半分（プロバイダーサーバーとAPN間の永続的で安全なチャネル）では、オンライン開発者アカウントでの構成とApple提供の暗号証明書の使用が必要です。プロバイダーとは、APNで動作するように構成および展開するサーバーです。図1-1は、リモート通知の配信パスを示しています。
図1-1リモート通知をプロバイダーからアプリに配信する
プロバイダーとアプリでプッシュ通知のセットアップが完了すると、プロバイダーはAPNに通知要求を送信できます。 APNは、対応する通知ペイロードを各ターゲットデバイスに伝達します。通知を受信すると、システムはペイロードをデバイス上の適切なアプリに配信し、ユーザーとのやり取りを管理します。
デバイスの電源がオンでアプリが実行されていない状態でアプリの通知が到着した場合、システムは引き続き通知を表示できます。 APNsが通知を送信するときにデバイスの電源がオフになっている場合、APNsは通知を保持し、後で再試行します（詳細については、サービス品質、ストアアンドフォワード、および結合通知を参照してください）。
プロバイダーの責任
プロバイダーサーバーには、APNに参加するための次の責任があります。
- ユーザーデバイス上のアプリのインスタンスから、APNを介して、グローバルに一意のアプリ固有のデバイストークンおよびその他の関連データを受信します。これにより、プロバイダーはアプリの実行中の各インスタンスについて知ることができます。
- 通知システムの設計に応じて、リモート通知を各デバイスに送信する必要があるタイミングを決定します。
- 通知リクエストを作成してAPNに送信します。各リクエストには通知ペイロードと配信情報が含まれます。その後、APNsは、ユーザーに代わって、対応する通知を目的のデバイスに配信します。
プロバイダーが送信するリモート通知要求ごとに、以下を行う必要があります。
- リモート通知ペイロードの作成の説明に従って、通知のペイロードを含むJSON辞書を作成します。
- ペイロード、グローバルに一意のデバイストークン、およびその他の配信情報をHTTP/2リクエストに追加します。デバイストークンの詳細については、「APNs-to-Device接続信頼とデバイストークン」を参照してください。 HTTP/2要求形式、およびAPNからの可能な応答とエラーについては、APNとの通信を参照してください。
- 永続的で安全なチャネルを介して、トークンまたは証明書の形式の暗号資格情報を含むHTTP/2要求をAPNに送信します。
- この安全なチャネルの確立については、セキュリティアーキテクチャで説明しています。
複数のプロバイダーの使用
図1-2は、アプリを実行するデバイスに対してAPNsが有効にする仮想ネットワークの種類を示しています。通知の負荷を処理するには、通常、複数のプロバイダーをデプロイします。各プロバイダーは、APNへの永続的で安全な接続を独自に提供します。その後、各プロバイダーは、プロバイダーが有効なデバイストークンを持っているデバイスを対象とする通知要求を送信できます。
図1-2複数のプロバイダーから複数のデバイスへのリモート通知のプッシュ
サービス品質、ストアアンドフォワード、および結合通知
Appleプッシュ通知サービスには、ストアアンドフォワード機能を実行するQuality of Service（QoS）コンポーネントが含まれています。 APNsが通知を配信しようとし、宛先デバイスがオフラインの場合、APNsは通知を限られた期間保存し、デバイスが再び利用可能になったときに配信します。このコンポーネントには、デバイスごとおよびアプリごとに最新の通知のみが保存されます。デバイスがオフラインの場合、そのデバイスを対象とする通知要求を送信すると、以前の要求は破棄されます。デバイスが長時間オフラインのままになると、APNに保存されているすべての通知が破棄されます。
同様の通知を合体させるために、通知リクエスト内に折りたたみ識別子を含めることができます。通常、デバイスがオンラインの場合、APNsに送信する各通知要求は、デバイスに配信される通知になります。ただし、apns-collapse-idキーがHTTP/2要求ヘッダーに存在する場合、APNsはそのキーの値が同じである要求を結合します。たとえば、同じ見出しを2回送信するニュースサービスでは、両方のリクエストに同じ折りたたみ識別子の値を使用できます。その後、APNは2つの要求を1つの通知にまとめて、デバイスに配信します。 apns-collapse-idキーの詳細。
セキュリティアーキテクチャ
APNsは、接続信頼とデバイストークン信頼の2つの信頼レベルを使用して、エンドツーエンドの暗号化検証と認証を実施します。
接続信頼は、プロバイダーとAPN間、およびAPNとデバイス間で機能します。
デバイストークンの信頼は、リモート通知ごとにエンドツーエンドで機能します。通知は、正しい開始点（プロバイダー）と終了点（デバイス）の間でのみルーティングされるようにします。
デバイストークンは、Appleによって特定のデバイス上の特定のアプリに割り当てられた一意の識別子を含む不透明なNSDataインスタンスです。 APNのみがデバイストークンの内容をデコードして読み取ることができます。各アプリインスタンスは、APNに登録するときに一意のデバイストークンを受け取り、リモート通知サポートの構成で説明されているように、トークンをプロバイダーに転送する必要があります。プロバイダーは、関連付けられたデバイスをターゲットとする各プッシュ通知リクエストにデバイストークンを含める必要があります。 APNsは、デバイストークンを使用して、通知が意図された一意のアプリとデバイスの組み合わせにのみ配信されるようにします。
APNはさまざまな理由で新しいデバイストークンを発行できます：
- ユーザーが新しいデバイスにアプリをインストールします
- ユーザーがバックアップからデバイスを復元する
- ユーザーがオペレーティングシステムを再インストールする
- その他のシステム定義のイベント
その結果、APNs-to-Device接続信頼とデバイストークンで説明されているように、アプリは起動時にデバイストークンを要求する必要があります。コード例については、リモート通知を受信するための登録を参照してください。
APNsとのHTTP/2ベースのTLSセッションを確立するには、各プロバイダーにGeoTrustグローバルCAルート証明書がインストールされていることを確認する必要があります。プロバイダーがmacOSを実行している場合、このルート証明書はデフォルトでキーチェーンにあります。他のシステムでは、この証明書を明示的にインストールする必要がある場合があります。この証明書は、GeoTrust Root Certificates Webサイトからダウンロードできます。ここに証明書への直接リンクがあります。
図1-3は、HTTP/2ベースのAPNsプロバイダーAPIを使用して信頼を確立し、JWTプロバイダー認証トークンを使用して通知を送信することを示しています。
図1-3トークンベースのプロバイダー接続信頼の確立と使用
図1-3に示すように、トークンベースのプロバイダーの信頼は次のように機能します。
プロバイダーは、図で「TLS開始」とラベル付けされた矢印として表されるトランスポート層セキュリティ（TLS）を使用して、APNとの安全な接続を要求します。
次に、APNsはプロバイダーにAPNs証明書を提供します。これは、図の次の矢印（「APNs証明書」というラベル）で表され、プロバイダーが検証します。
この時点で、接続の信頼が確立され、プロバイダーサーバーがトークンベースのリモートプッシュ通知要求をAPNに送信できるようになります。プロバイダーが送信する各通知要求には、図で「通知プッシュ」というラベルの付いた矢印で表されているJWT認証トークンを添付する必要があります。
APNは、各プッシュに応答します。図では、「HTTP/2応答」というラベルの付いた矢印で表されています。
このステップでプロバイダーが受信できる応答の詳細については、APNからのHTTP/2応答を参照してください。
図1-4は、Appleが発行したSSL証明書を使用して、プロバイダーとAPN間の信頼を確立する方法を示しています。図1-3とは異なり、この図はプッシュ自体の通知を示していませんが、トランスポート層セキュリティ（TLS）接続の確立時に停止します。証明書ベースの信頼スキームでは、プッシュ通知要求は認証されませんが、付随するデバイストークンを使用して検証されます。
図1-4証明書ベースのプロバイダー接続信頼の確立
図1-4に示すように、証明書ベースのプロバイダーからAPNへの信頼は次のように機能します。
プロバイダーは、図で「TLS開始」とラベル付けされた矢印として表されるトランスポート層セキュリティ（TLS）を使用して、APNとの安全な接続を要求します。
次に、APNsはプロバイダーにAPNs証明書を提供します。これは、図の次の矢印（「APNs証明書」というラベル）で表され、プロバイダーが検証します。
プロバイダーは、Appleがプロビジョニングしたプロバイダー証明書（Xcodeヘルプの「ユニバーサルAPNsクライアントSSL証明書の生成」で説明したように、オンライン開発者アカウントから以前に取得したもの）を、「Provider証明書。」
次に、APNsはプロバイダー証明書を検証し、それにより接続要求が正当なプロバイダーから発信されたことを確認し、TLS接続を確立します。
この時点で、接続の信頼が確立され、プロバイダーサーバーが証明書ベースのリモートプッシュ通知要求をAPNに送信できるようになります。
APNからデバイスへの接続の信頼とデバイストークン
このセクションで説明するように、APNと各デバイス間の信頼は、アプリの参加なしで自動的に確立されます。
各デバイスには、暗号化証明書とプライベート暗号化キーがあり、デバイスの初期アクティベーション時にオペレーティングシステムによって提供され、デバイスのキーチェーンに保存されます。アクティブ化中、APNは、図6-5に示すように、証明書とキーに基づいて、デバイスへの接続を認証および検証します。
図1-5デバイスとAPN間の接続信頼の確立
図1-5に示すように、APNからデバイスへの信頼は次のように機能します。
- 図の上部の矢印に示すように、デバイスがAPNとのTLS接続を開始すると、信頼ネゴシエーションが開始されます。
- APNsは、APNs証明書をデバイスに返します。
- オペレーティングシステムはこの証明書を検証し、「デバイス証明書」の矢印に示すように、デバイス証明書をAPNsに送信します。
- 最後に、図の下の矢印で示されているように、APNはデバイス証明書を検証し、信頼を確立します。
- APNとデバイス間にTLS接続が確立されると、デバイス上のアプリはAPNに登録して、リモート通知用のアプリ固有のデバイストークンを受信できます。詳細およびコード例については、リモート通知サポートの構成のリモート通知を受信するための登録を参照してください。
デバイストークンを受信した後、アプリはアプリの関連プロバイダーに接続し、トークンを転送する必要があります。このステップは、プロバイダーが通知トークンをAPNに送信してデバイスをターゲットにするときにデバイストークンを含める必要があるため、必要です。トークンを転送するために記述するコードは、リモート通知を受信するための登録にも示されています。
ユーザーがデバイスを初めてアクティブ化する場合でも、APNが新しいデバイストークンを発行する場合でも、プロセスは同様であり、図6-6に示されています。
図1-6デバイストークンの管理
アプリ固有のデバイストークンの取得と処理は次のように機能します。
上矢印に示すように、アプリはリモート通知のためにAPNに登録します。アプリが既に登録されていて、アプリ固有のデバイストークンが変更されていない場合、システムは既存のトークンをすばやくアプリに返し、このプロセスはステップ4にスキップします。
新しいデバイストークンが必要な場合、APNはデバイスの証明書に含まれる情報を使用してトークンを生成します。トークンキーを使用してトークンを暗号化し、中央の右向き矢印に示すようにデバイスに返します。
システムは、application：didRegisterForRemoteNotificationsWithDeviceToken：デリゲートメソッドを呼び出して、デバイストークンをアプリに戻します。
トークンを受信すると、アプリ（デリゲートメソッド内）は、バイナリまたは16進形式でプロバイダーにトークンを転送する必要があります。このトークンがないと、プロバイダーは通知をデバイスに送信できません。詳細については、リモート通知サポートの構成のリモート通知を受信するための登録を参照してください。
重要
APNsデバイストークンは可変長です。サイズをハードコーディングしないでください。
プロバイダーがプッシュ通知要求をAPNsに送信する場合、一意のアプリとデバイスの組み合わせを識別するデバイストークンが含まれます。この手順は、図6-7のプロバイダーとAPNの間の「トークン、ペイロード」矢印に示されています。 APNsはトークンを解読して、リクエストの有効性を確認し、ターゲットデバイスを決定します。 APNsは、送信者と受信者が正当であると判断した場合、識別されたデバイスに通知を送信します。
図1-7プロバイダーからデバイスへのリモート通知パス
デバイスが通知を受信した後（および図1-7に示す最後のステップの後）、システムはリモート通知をアプリに転送します。
参照： Apple Push Notification Service
ここで、技術フローを理解するためにここを見てください： iOSアプリケーションでApple Push Notification Serviceを実装する方法？
この記事 には、Push通知の素晴らしい説明があります。
IOSでは、アプリはバックグラウンドで多くのことを実行できません。アプリは限られたアクティビティのみを実行できるため、バッテリー寿命が節約されます。
しかし、何か面白いことが起こり、ユーザーが現在アプリを使用していない場合でも、ユーザーにこれを知らせたい場合はどうでしょうか？