/
560.txt
134 lines (109 loc) · 4.72 KB
/
560.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
[17]
[DFN[Web Push protocol]]
は、[[プッシュメッセージ]]の配送に関する[[利用者エージェント]]、
[[プッシュサービス]]、
[[アプリケーションサーバー]]3者間の[[プロトコル]]です。
[[HTTP]] を下位層とする[[プロトコル]]です。
* 仕様書
[REFS[
- [1] [CITE@en[RFC 8030 - Generic Event Delivery Using HTTP Push]], [TIME[2020-03-09 00:13:33 +09:00]] <https://tools.ietf.org/html/rfc8030>
]REFS]
* 呼称
[10] [[RFC 8030]] の題名は[[プロトコル]]名ではなく、
本文中も[[プロトコル]]名称を明確に述べていないので、
正式名称はよくわかりません。
[12] [[RFC 8030]] 各ページヘッダーには
[DFN[HTTP Web Push]]
とあります。 [SRC[>>1]]
[[ポート番号]] [N[1001]]
の
[[IANA登録簿]]雛形の説明にも
[[HTTP Web Push]]
と記入されています。
[SRC[>>1 9.3.]]
[13] [[ポート番号]] [N[1001]]
の
[[IANA登録簿]]雛形のサービス名は、
[DFN[webpush]]
とされています。
[SRC[>>1 9.3.]]
[14]
[[URN]] は
[DFN[[CODE[urn:ietf:params:push]]]]
と省略形の [DFN[push]]
になっています。
その
[[IANA登録簿]]は
[CITE[Web Push Identifiers]]
なる名称で、すると [DFN[Web Push]]
が[[プロトコル]]名に当たる部分です。
[SRC[>>1 9.2.]]
[15] 開発した [[IETF]] の [[WG]] は「WEBPUSH WG」
ですが、これは[[プロトコル]]名とは即断できません。
[16]
[[RFC 8291]] や [[RFC 8292]] は、題名に 「Web Push」と入っています。
[[RFC 8030]] の[[プロトコル]]を
[DFN[The Web Push protocol]]
と呼ぶ他、文中に何度か「Web Push」
と出てきます。
構文内で [DFN[[CODE[WebPush]]]] や
[CODE[application/webpush-options+json]]
と使われる部分もあります。
[18]
[CITE[[[Push API]]]]
は
[DFN[web push protocol]]
と呼んでいます。
* 用途
[3]
[[モバイル端末]]・[[埋め込み機器]]の[[応用]]で[[実時間]]イベントを[[ネットワーク]]から受け取りたい
(「[[プッシュ]]」されたい) 要求がある一方で、
[[電力]]制約があって通信を抑制したいです。
[[応用]]ごとに別個に通信するのではなく、
1つのサービスに集約するのが良いと考えられます。
そのような前提の元、
[[Push API]]
では従来[[独占的]]プロトコルが用いられてきましたが、
本手法は[[標準化]]された[[プロトコル]]として開発されたものです。
[SRC[>>1 1.]]
[5]
と[[仕様書]]では説明されていますが、電力の制約を持ち出すまでもなく、
無数の [[Webアプリケーション]]を常時稼働させておくのは現実的とはいえません。
[[Webブラウザー]]で当該 [[Webアプリケーション]]を開いていないときでも[[プッシュメッセージ]]を受け取れるために
(そうでなければとても実用的とはいえません)、
[[ワーカー]]を常時動作させておくとか、
最低でも1つ[[HTTP接続]]を維持させておかなければならないとしたら、
[[計算機資源]]を無駄に消費し続けることになります。
賢い[[アーキテクチャー]]とはいえないでしょう。
[[Webプラットフォーム]]という[[分散システム]]な全体設計と矛盾するようですが、
特定少数個に集約した[[プロトコル]]になるのは必然といえます。
[4]
理論上 [[Push API]]
と併用せず独自の方法と組み合わせることも可能ですが、
実例があるかは不明です。
* プロトコル
[6] 次の[[用語]]が定義されています。
この[[用語]]は他の関連仕様でも使われています。
[FIG(middle list)[ [7] [[Web Push Protocol]] の用語
- [[アプリケーション][アプリケーション (プッシュ)]]
- [[アプリケーションサーバー][アプリケーションサーバー (プッシュ)]]
- [[プッシュメッセージ購読]]
- [[プッシュメッセージ購読集合]]
- [[プッシュメッセージ]]
- [[プッシュメッセージ受領証]]
- [[プッシュサービス]]
- [[利用者エージェント][利用者エージェント (プッシュ)]]
]FIG]
[11] [[プッシュメッセージ]]の送受信など多くの操作は、
[[プッシュメッセージ購読]]を使って行います。
* API
[SEE[ [[Push API]] ]]
* 歴史
[2]
[TIME[2016年12月][2016-12]]に
[[IETF]]
の[[提案標準]]
[DFN[RFC 8030]]
として出版されました。
[SRC[>>1]]
[9] [CITE[Web Push Parameters]], [TIME[2017-12-27 01:57:03 +09:00]] <https://www.iana.org/assignments/webpush-parameters/webpush-parameters.xhtml>