第6話: HTTPウェブプッシュの雑多なメモ〜 REAL WORLD HTTP第7章より〜

HTTPウェブプッシュ

HTTPウェブプッシュは、ウェブサイトにスマホアプリのような通知機能を提供する仕組みです。 HTTPウェブプッシュはその機能の特性上、ブラウザが起動していなかったり、オフラインでも、ユーザに通知を送れる必要があります。

実装方法や困ったことも記載していて面白そうな記事になっているのでオススメしておきます。 - https://developers.cyberagent.co.jp/blog/archives/9662/

また、ディレクターがHTTPウェブプッシュを導入することで考えていたことも別記事になっていて面白そうです。 - https://developers.cyberagent.co.jp/blog/archives/9772/

ブラウザがないのになぜ通信できるのか。その秘密は、オフラインのアプリを実現・サポートするために作られた Service Workerという機能にあります。

Service Workerは、ブラウザがWebページのスクリプトとは別のプロセスでスクリプトをバックグラウンドで実行できる機能のことです。現在登録されているイベントは以下の通りとなっています。

どのような仕組みで行われるのか、その概要を一枚の図にしました。ちょっとごちゃごちゃ説明文を図に書いていますが登場人物は3人、

ざっとした流れは、

クライアントからプッシュサーバの登録情報(endopoint, registrationID)をアプリサーバに通知。 (Push Serviceにアプリサーバがリクエストを送ることができるようになる)
アプリサーバが、プッシュ通知をHTTP PUTのリクエストボディに付けてプッシュサーバに送信。
プッシュサーバは、プッシュ通知をチャネルで区別し、送信クライアントを選定。
プッシュサーバは、HTTP/2のサーバプッシュやFCM(Firebase Cloud Messaging)など利用してクライアントにプッシュ通知をSSEで送信。
クライアントは、プッシュサーバからプッシュ通知を受けると、Service Worker上でPushイベントが発生。
プッシュされたデータはキャッシュ更新なり、クライアント上でいかようにでも処理することができる。

といった流れになります。

上記1に入る前に、ブラウザを起動するときに、プッシュ通知の利用許諾を取る必要があります。 - プッシュ通知はオプトイン(承諾が必要ってこと) - 承諾されればプッシュサービスを利用登録する - サービスのIDと、送信用の鍵(プッシュサービスがブラウザを特定するためのもの)を取得

承諾されて有効になるとService Workerで登録したpushイベントで通知が受け取れるようになります。

補足:
現状ウェブプッシュはプッシュサービスと連携することで実現しています。プッシュサービスはChromeの場合はGoogle社の通知サービス、 Firefoxの場合はMozilla社の通知サービスを利用します。

Urgencyヘッダーをリクエスト時に付与すると、不必要なメッセージをフィルタリングできます。メッセージ送信、および送信のときに付与します。以下のように設定可能な値を示します。省略時はnormalになります。