メインコンテンツまでスキップ

1. はじめに

1. はじめに​

モバイルおよび組み込みデバイス上の多くのアプリケーションは, 着信やメッセージなどのリアルタイムイベントをタイムリーに配信 (または「プッシュ」) するために, 継続的なネットワーク通信へのアクセスを必要とする. これらのデバイスは通常電力に制約があるため, アプリケーション要件をより効率的に満たす方法はエコシステム全体に利益をもたらす.

電力使用の大きな要因の一つは無線 (radio) である. 無線通信はワイヤレスデバイスのエネルギー予算のかなりの部分を消費する.

複数アプリケーションによる永続接続やセッションの不調整な利用は, 独立したセッションごとにオーバーヘッドが生じうるため, デバイス無線の不要な使用につながる. 特に, ミドルボックスがセッションを早めにタイムアウトさせないようにするキープアライブトラフィックは著しい浪費となりうる. イベントは比較的稀であるため, 長期的には保守トラフィックが支配的になりやすい.

すべてのリアルタイムイベントを単一セッションに集約すると, ネットワークおよび無線リソースのより効率的な利用が保証される. 単一のサービスがすべてのイベントを集約し, 到着に応じてアプリケーションへ配分する. これによりセッションは一つで済み, 重複したオーバーヘッドを避けられる.

W3C Push API [API] は, Web アプリケーションから集約プッシュサービス (consolidated push service) を利用可能にする API を記述する. 本ドキュメントはそれを拡張し, 次に用いうるプロトコルを記述する:

  • ユーザエージェント (user agent) へのプッシュメッセージ (push message) 配信の要求,

  • 新しいプッシュメッセージ配信購読 (subscription) の作成, および

  • 新しいプッシュメッセージの監視.

イベント配信の標準化された方法は W3C Push API に特に重要である. アプリケーションサーバは複数のプッシュサービスを利用する必要があるかもしれない. 購読, 管理, 監視機能は現在プロプライエタリプロトコルで満たされているが, 標準化がもたらす利点はない.

本ドキュメントは意図的にプッシュサービスの発見方法を記述しない. 必要と判明した場合の将来の作業に委ねる. ユーザエージェントはプッシュサービスの URL で構成されることが期待される.

1.1. Conventions and Terminology (慣例と用語)​

本ドキュメント中の "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は [RFC2119] に従って解釈される.

本ドキュメントは次の用語を定義する:

application (アプリケーション): プッシュメッセージの送信者かつ最終消費者の両方. 多くのアプリケーションはユーザエージェント上とサーバ上の双方にコンポーネントを持つ.

application server (アプリケーションサーバ): 通常サーバ上で動作し, プッシュメッセージの配信を要求するアプリケーションのコンポーネント.

push message subscription (プッシュメッセージ購読): ユーザエージェントとプッシュサービス (push service) の間に確立されアプリケーションサーバと共有されるメッセージ配信コンテキスト. すべてのプッシュメッセージはプッシュメッセージ購読に関連付けられる.

push message subscription set (プッシュメッセージ購読集合): ユーザエージェントとプッシュサービスの間に確立され, 複数のプッシュメッセージ購読を集合にまとめるメッセージ配信コンテキスト.

push message (プッシュメッセージ): アプリケーションサーバからプッシュサービス経由でユーザエージェントへ送られるメッセージ.

push message receipt (プッシュメッセージ受領): プッシュサービスからアプリケーションサーバへ送られるメッセージ配信確認.

push service (プッシュサービス): ユーザエージェントへプッシュメッセージを配信するサービス.

user agent (ユーザエージェント): プッシュメッセージの受信者となるデバイスとソフトウェア.

本ドキュメントの例は HTTP/1.1 メッセージ形式 [RFC7230] を用いる. 多くのやり取りは HTTP/1.1 で完了できる:

  • プッシュメッセージの購読 (第 4 節)

  • プッシュメッセージ配信の要求 (第 5 節)

  • プッシュメッセージの置換 (第 5.4 節)

  • プッシュメッセージの確認 (第 6.2 節)

例が HTTP/2 サーバプッシュに依存する場合は [RFC7540] のより冗長なフレーム形式を用いる:

  • 購読に対するプッシュメッセージの受信 (第 6 節)

  • 購読集合に対するプッシュメッセージの受信 (第 6.1 節)

  • プッシュメッセージ受領の受信 (第 6.3 節)

すべての例は登録ポート (1001) ではなくデフォルトポート (443) 上の HTTPS を用いる. プッシュサービス展開はユーザエージェントの到達性を最大化するためにこの構成を好むかもしれない. プッシュサービスは HTTP 代替サービス (HTTP alternative services) を用いてユーザエージェントを登録ポート (1001) にリダイレクトし, 到達性を犠牲にせず標準 HTTPS ポートの利点を得ることができる (第 3 節参照). これはユーザエージェントからプッシュサービスへのリクエストに Alt-Used ヘッダフィールド [RFC7838] が含まれる場合にのみ例から明らかになる.

例にはプッシュメッセージの暗号化やアプリケーションサーバ認証の具体的手段は含まれない. プロトコルは強制システムを定義しない. Voluntary Application Server Identification [VAPID] および Message Encryption for WebPush [ENCRYPT] の例は, W3C Push API [API] が要件のために採用したアプローチを示す.

に最終更新