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