7. 運用上の考慮

7.1. Load Management (負荷管理)

プッシュサービスは非常に多数のオープン TCP 接続を維持する必要がある可能性が高い. これらの接続の効果的な管理は, 接続をサーバインスタンス間で移動できる能力に依存しうる.

ユーザエージェントは 307 (Temporary Redirect) ステータスコード [RFC7231] をサポートしなければならない (MUST). プッシュサービスは新しい購読が要求された時点で負荷を再分配するためにこれを用いうる.

負荷を再分配したいサーバは HTTP 代替サービス [RFC7838] を用いうる. HTTP 代替サービスは各種リソースの URI を同じままにしながら負荷の再分配を可能にする. ユーザエージェントは代替接続を確立した後に GOAWAY フレームを用いることで円滑な移行を確保できる.

7.2. Push Message Expiration (プッシュメッセージの期限切れ)

TTL ヘッダフィールドに基づくプッシュメッセージの保存はプッシュサービスにとってかなりのストレージとなりうる. プッシュサービスはメッセージを無期限に保存する義務はない. プッシュサービスは TTL ヘッダフィールド (第 5.2 節) を用いてアプリケーションサーバにメッセージを保持する意図の期間を示せる.

プッシュメッセージを積極的に監視しないユーザエージェントは, その間に期限切れになったメッセージを受信しない.

保存されユーザエージェントにまだ配信されていないプッシュメッセージは, ユーザエージェントが監視を再開したときに配信される. 保存されたプッシュメッセージは Last-Modified ヘッダフィールド ([RFC7232] 第 2.2 節) を含めるべきである (SHOULD). アプリケーションサーバが配信を要求した時刻を示す.

期限切れメッセージのみを含むプッシュメッセージ購読リソースへの GET リクエストは, プッシュメッセージが一度も送られなかったかのようなレスポンスとなる.

プッシュサービスは過負荷を避けるために保存するプッシュメッセージのサイズと数を制限する必要があるかもしれない. メッセージサイズを制限するため, プッシュサービスは大きすぎるエンティティボディを含むリクエストに対して 413 (Payload Too Large) ステータスコード [RFC7231] を返してもよい (MAY). プッシュサービスは 4096 バイト以下のエンティティボディへのレスポンスで 413 ステータスコードを返してはならない (MUST NOT).

保存するプッシュメッセージの数を制限するため, プッシュサービスはプッシュメッセージ配信のリクエスト (第 5.2 節) でアプリケーションサーバが提案したものより短い Time-To-Live で応答してもよい (MAY). メッセージが一度受理された後, プッシュサービスは告知された Time-To-Live より前にメッセージを期限切れにしてもよい (MAY). アプリケーションサーバが配信受領を要求していた場合, プッシュサービスは失敗レスポンス (第 6.2 節) を返さなければならない (MUST).

7.3. Subscription Expiration (購読の期限切れ)

購読を終了して更新する必要がある場合がある. これはプッシュメッセージ購読と受領購読の両方に当てはまる.

プッシュサービスはいつでも購読を期限切れにしてもよい (MAY). 期限切れのプッシュメッセージ購読リソース (第 6 節) に対するユーザエージェントからの未処理リクエスト, または期限切れの受領購読リソース (第 6.3 節) に対するアプリケーションサーバからの未処理リクエストがある場合, 404 (Not Found) ステータスコードを返すことでこれを通知しなければならない (MUST).

アプリケーションサーバが期限切れのプッシュメッセージ購読へプッシュメッセージを送ろうとした場合, プッシュサービスは 404 (Not Found) ステータスコードを返さなければならない (MUST).

ユーザエージェントは対応する URI へ DELETE リクエストを送ることでプッシュメッセージ購読を削除できる. アプリケーションサーバは対応する URI へ DELETE リクエストを送ることで受領購読を削除できる.

7.3.1. Subscription Set Expiration (購読集合の期限切れ)

プッシュサービスはいつでも購読集合を期限切れにしてもよく (MAY), 集合内のすべてのプッシュメッセージ購読も期限切れにしなければならない (MUST). ユーザエージェントがプッシュ購読集合 (第 6.1 節) への未処理リクエストを持つ場合, 404 (Not Found) ステータスコードを返すことでこれを通知しなければならない (MUST).

ユーザエージェントは購読集合 URI へ DELETE リクエストを送ることで購読集合の削除を要求できる. これは集合内のすべてのプッシュメッセージ購読も削除しなければならない (MUST).

購読集合のメンバーである特定のプッシュメッセージ購読が期限切れまたは削除された場合, その購読集合からも削除されなければならない (MUST).

7.4. Implications for Application Reliability (アプリケーション信頼性への影響)

プッシュサービスが断続的ネットワーク接続やデバイス上の故障アプリケーションにわたる信頼できる配信をサポートしない場合, デバイスは受領をアプリケーションサーバに直接確認させられ, 個々のアプリケーションサーバへの (通常は安全な) 接続の確立と維持のために追加の電力消費を招く.

メッセージがアプリケーションの状態にとって重要な情報を含む場合, プッシュメッセージの信頼性は重要になりうる. 状態の修復は高価であり, 特に通信能力が限られたデバイスではそうである. プッシュメッセージが正しく受信されたことを知ることで再送, ポーリング, 状態の再同期を避けられる.

プッシュメッセージ配信受領の利用可能性により, 開発者はプッシュサービスが重要なメッセージの配信に失敗した場合に代替のメッセージ配信手段を作りたくなることを避けられる. これらの欠点を補うためにポーリング機構やバックアップメッセージチャネルを設置することは, プッシュサービスが提供する利点のほぼすべてを打ち消す.

しかし, 一時的なメッセージ (例: 着信) やすぐに置き換わるメッセージ (例: 未読メール数) には信頼性が不要な場合もある.

7.5. Subscription Sets and Concurrent HTTP/2 Streams (購読集合と HTTP/2 同時ストリーム)

プッシュサービスがユーザエージェントにプッシュメッセージ購読集合の使用を要求する場合, HTTP/2 SETTINGS フレーム [RFC7540] 内の SETTINGS_MAX_CONCURRENT_STREAMS パラメータで同時にアクティブなストリーム数を制限してもよい (MAY). ユーザエージェントはプッシュメッセージ購読の管理に 1 本の同時ストリームと, プッシュサービスが返した各購読集合ごとに 1 本の同時ストリームに制限されうる (MAY). これによりユーザエージェントはプッシュサービスへの購読リクエストを直列化せざるを得ないかもしれない.