web-push を深掘りしてみる - ハウテレビジョンブログ

はじめに
RFC 8030
おわりに

はじめに

こんにちは、新型質問箱 mond の開発チームに所属している id:chima91 です。今回は、最近 mond にて実装した web-push（ブラウザへのプッシュ通知）について語ろうと思います。

基本的な実装方法については記事にまとめました。

https://zenn.dev/howtelevision/articles/cecdb89682fb03

今回は web-push の細かい情報を調べていきます。

RFC 8030

IETF によってインターネット技術の標準的な仕様が記された文書である RFC（Request For Comments）を見ます。

web-push は RFC 8030 としてまとめられています。

RFC 8030: Generic Event Delivery Using HTTP Push

タイトルは単純に「web-push」とかではなく「Generic Event Delivery Using HTTP Push」となっているようです。

使用している技術

まず、どのような技術を使って実装されているのでしょうか。

This document describes a simple protocol for the delivery of real-time events to user agents. This scheme uses HTTP/2 server push.

web-push は HTTP/2 Server Push という仕組みを用いて実現されているとのことで、

これは、クライアントからの HTTP リクエストを待たずにサーバーが HTTP レスポンスを返す（送る）機能です。

しかし現在では、HTTP/2 Server Push の実装は Chromium から削除され、代替手段として 103 Early Hints が提唱されています。

Chrome から HTTP/2 サーバープッシュを削除する | Blog | Chrome for Developers

RFC 8030 は 2016年12月に公開されていて情報がだいぶ古いです。

RFC は一度公開されるとその特定の文書自体は更新されることはなく、内容を修正する必要が生じた場合は、元のRFCをそのまま編集するのではなく、別の新しいRFCが発行される形で対応するようです。

新しい RFC は見つけられませんでした:(

プッシュ通知購読から送信まで

次に、ユーザーがプッシュ通知を購読し、実際に通知が送信されるまでの流れがアスキーアートを用いて描かれていました。

+-------+           +--------------+       +-------------+
|  UA   |           | Push Service |       | Application |
+-------+           +--------------+       |   Server    |
    |                      |               +-------------+
    |      Subscribe       |                      |
    |--------------------->|                      |
    |       Monitor        |                      |
    |<====================>|                      |
    |                      |                      |
    |          Distribute Push Resource           |
    |-------------------------------------------->|
    |                      |                      |
    :                      :                      :
    |                      |     Push Message     |
    |    Push Message      |<---------------------|
    |<---------------------|                      |
    |                      |                      |

自分が Zenn に書いたシーケンスダイアグラムよりも簡潔に表現されています。

W3C による Push API のドキュメントには、より詳細なシーケンスダイアグラムが掲載されていました。

Push Message Urgency

最後に、プッシュ通知受信によるデバイスのバッテリー消費について見ていきます。

To avoid consuming resources to receive trivial messages, it is helpful if an application server can communicate the urgency of a message and if the user agent can request that the push server only forwards messages of a specific urgency.

些細な通知を受信することでリソースを消費することを避けるため、アプリケーションサーバーがメッセージの緊急度を伝えることができ、ユーザーエージェントが特定の緊急度のメッセージのみをプッシュサーバーに転送するように要求できれば便利である。

上記の通り、プッシュ通知の緊急度を指定することで受信する端末のバッテリー消費を抑えることができるようで、下記の4つの値が定義されています。

 +----------+-----------------------------+--------------------------+
 | Urgency  | Device State                | Example Application      |
 |          |                             | Scenario                 |
 +----------+-----------------------------+--------------------------+
 | very-low | On power and Wi-Fi          | Advertisements           |
 | low      | On either power or Wi-Fi    | Topic updates            |
 | normal   | On neither power nor Wi-Fi  | Chat or Calendar Message |
 | high     | Low battery                 | Incoming phone call or   |
 |          |                             | time-sensitive alert     |
 +----------+-----------------------------+--------------------------+

この指定により、どれだけバッテリー節約効果があるのかは分かりませんが、ここまで考えて web-push を実装する必要があるとなると、なかなか奥深いなと感じました。