Loading article…
プッシュ技術（サーバープッシュとも呼ばれる）は、通信がクライアントではなくサーバーによって開始される通信方式です。この方式は、通信がクライアントによって開始される「プル」方式とは異なります。 [ 1 ]
プッシュ型テクノロジーでは、クライアントは特定の種類の情報やデータに対する好みを表明できます。これは通常、パブリッシュ/サブスクライブモデルと呼ばれるプロセスを通じて行われます。このモデルでは、クライアントはサーバーがホストする特定の情報チャネルを「購読」します。これらのチャネルで新しいコンテンツが利用可能になると、サーバーは自動的にその情報を購読しているクライアントに送信、つまり「プッシュ」します。
受信HTTPリクエストをブロックする厳格なセキュリティポリシーなど、特定の条件下では、プッシュ技術はポーリングと呼ばれる手法を用いてシミュレートされることがあります。このような場合、クライアントは自動更新を受信するのではなく、定期的にサーバーに問い合わせて新しい情報が利用可能かどうかを確認します。
同期型会議やインスタントメッセージングは、プッシュサービスの例です。チャットメッセージや場合によってはファイルは、メッセージングサービスが受信するとすぐにユーザーにプッシュされます。分散型ピアツーピアプログラム（ WASTEなど）と集中型プログラム（ IRCやXMPPなど）の両方でファイルのプッシュが可能であり、これは受信者ではなく送信者がデータ転送を開始することを意味します。
電子メールもプッシュシステムになり得ます。SMTPはプッシュプロトコルです（プッシュ電子メールを参照）。ただし、最後のステップ、つまりメールサーバーからデスクトップコンピュータへの送信は、通常、POP3やIMAPのようなプルプロトコルを使用します。最新の電子メールクライアントは、メールサーバーを繰り返しポーリングし、新しいメールがないか頻繁に確認することで、このステップを瞬時に処理しているように見せます。IMAPプロトコルにはIDLEコマンドが含まれており、サーバーは新しいメッセージが届いたときにクライアントに通知することができます。初代BlackBerryは、ワイヤレス環境におけるプッシュ電子メールの最初の普及例でした。
もう一つの例は、1990年代に広く報道されたPointCast Networkです。これは、ニュースや株式市場データをスクリーンセーバーとして配信するものでした。NetscapeとMicrosoftは、ブラウザ戦争の最盛期に、Channel Definition Format （CDF）を介したプッシュ技術を自社ソフトウェアに統合しましたが、あまり普及しませんでした。CDFは次第に姿を消し、当時のブラウザから削除され、2000年代にはRSS（プルシステム）に取って代わられました。
プッシュ通知機能を備えたウェブアプリケーションのその他の用途としては、ソフトウェアアップデートの配信（「プッシュアップデート」）、市場データの配信（株価ティッカー）、オンラインチャット／メッセージングシステム（ウェブチャット）、オークション、オンライン賭博およびゲーム、スポーツ結果、監視コンソール、センサーネットワークの監視などが挙げられる。
インターネット技術タスクフォースのWebプッシュ提案は、 HTTPバージョン2を使用して着信通話やメッセージなどのリアルタイムイベントをタイムリーに配信（または「プッシュ」）するシンプルなプロトコルです。このプロトコルは、すべてのリアルタイムイベントを単一のセッションに統合することで、ネットワークおよび無線リソースのより効率的な使用を保証します。単一のサービスがすべてのイベントを統合し、イベントが到着するたびにアプリケーションに配信します。これには1つのセッションのみが必要で、重複したオーバーヘッドコストを回避できます。[ 2 ]
ウェブ通知はW3C標準の一部であり、エンドユーザーへの通知のためのAPIを定義しています。通知により、ウェブページのコンテキスト外で、電子メールの配信などのイベントをユーザーに通知できます。 [ 3 ]この標準の一部として、Push APIは2023年2月時点でChrome、Firefox、Edgeに完全に実装されており、Safariには部分的に実装されています。 [ 4 ] [ 5 ]
HTTPサーバープッシュ（HTTPストリーミングとも呼ばれる）は、 WebサーバーからWebブラウザへ非同期データを送信する仕組みです。HTTPサーバープッシュは、いくつかの異なる方法で実現できます。
HTML5の一部であるWebSocket APIは、 Webサーバーとクライアントが全二重TCP接続を介して通信することを可能にします。
一般的に、Web サーバーはクライアントに応答データを提供した後も接続を終了しません。Web サーバーは接続を開いたままにして、イベントが発生した場合 (たとえば、1 つまたは複数のクライアントに報告する必要がある内部データの変更) にすぐに送信できるようにします。そうでない場合、イベントはクライアントの次のリクエストが受信されるまでキューに入れなければなりません。ほとんどの Web サーバーは、CGI (たとえば、 Apache HTTP サーバーの Non-Parsed Headers スクリプト) を介してこの機能を提供します。[ 6 ] [ 7 ]このアプローチの基盤となるメカニズムは、チャンク転送エンコーディングです。
もう1つのメカニズムは、 Netscapeが1995年に導入した特殊なMIMEタイプであるに関連しています。Webブラウザはこれを、サーバーがクライアントに新しいバージョンをプッシュするたびに変更されるドキュメントとして解釈します。 [ 8 ]これは現在でもFirefox、Opera、Safariでサポートされていますが、 Internet Explorerでは無視され[ 9 ] 、 Chromeでは部分的にしかサポートされていません。[ 10 ]これはHTMLドキュメントに適用でき、Webカメラアプリケーションのストリーミング画像にも適用できます。multipart/x-mixed-replace
WHATWG Web Applications 1.0 提案[ 11 ]には、クライアントにコンテンツをプッシュするメカニズムが含まれています。2006 年 9 月 1 日、Opera Web ブラウザは、「Server-Sent Events」と呼ばれる機能でこの新しい実験的なシステムを実装しました。[ 12 ] [ 13 ]これは現在HTML5標準の一部となっています。[ 14 ]
この手法では、サーバーは永続的な HTTP 接続を利用し、応答を常に「開いたまま」（つまり、サーバーが応答を終了しない）にしておくことで、最初のページ読み込みが完了したとみなせる後もブラウザを「読み込み中」モードのままにしておくように仕向けます。その後、サーバーは定期的にJavaScriptのスニペットを送信してページの内容を更新し、プッシュ機能を実現します。この手法を使用すると、クライアントはサーバーへの接続を開いたままにするためにJava アプレットやその他のプラグインを必要としません。クライアントはサーバーからプッシュされた新しいイベントについて自動的に通知されます。[ 15 ] [ 16 ]ただし、この方法の重大な欠点の 1 つは、サーバーがブラウザのタイムアウトを制御できないことです。ブラウザ側でタイムアウトが発生した場合は、常にページの更新が必要になります。
ロングポーリング自体は真のプッシュではありません。ロングポーリングは従来のポーリング技術のバリエーションですが、受信HTTPリクエストの拒否を必要とするセキュリティポリシーを持つサイトなど、実際のプッシュが不可能な状況でプッシュメカニズムをエミュレートできます。[ 17 ] [ 18 ]
ロングポーリングでは、クライアントは通常のポーリングとまったく同じようにサーバーからより多くの情報を取得するよう要求しますが、サーバーがすぐに応答しない可能性があることを前提としています。ポーリングを受信した時点でサーバーがクライアントに対して新しい情報を持っていない場合でも、空の応答を送信する代わりに、サーバーは要求を開いたままにして応答情報が利用可能になるまで待ちます。新しい情報が利用可能になると、サーバーはすぐにクライアントにHTTP応答を送信し、開いているHTTP要求を完了します。サーバーからの応答を受信すると、クライアントは多くの場合、すぐに別のサーバー要求を発行します。このようにして、ポーリングクライアントで通常発生する応答遅延（情報が最初に利用可能になってから次のクライアント要求までの時間）が解消されます。[ 19 ]
例えば、BOSHは、継続的なTCP接続を直接使用することが困難または不可能な場合（例えば、Webブラウザ内）に、継続的なTCP接続の代替としてロングポーリングで使用される、人気のある長寿命のHTTP技術です。[ 20 ]また、AppleがiCloudプッシュサポートに使用しているXMPPの基盤技術でもあります。
チャットアプリケーションで使用されるこの手法は、単一ピクセルのAdobe Flashムービー内のXMLソケットオブジェクトを利用します。JavaScriptの制御下で、クライアントはサーバー上の単方向リレーへのTCP接続を確立します。リレーサーバーはこのソケットから何も読み取らず、代わりに一意の識別子をクライアントに即座に送信します。次に、クライアントはこの識別子を含めてWebサーバーにHTTPリクエストを送信します。Webアプリケーションは、クライアント宛てのメッセージをリレーサーバーのローカルインターフェースにプッシュし、リレーサーバーはそれをFlashソケット経由で中継します。このアプローチの利点は、チャットを含む多くのWebアプリケーションに典型的な自然な読み書き非対称性を活用し、結果として高い効率性を実現することです。リレーサーバーは送信ソケットでデータを受け取らないため、送信TCP接続をポーリングする必要がなく、数万の同時接続を維持することが可能です。このモデルでは、拡張性の限界は基盤となるサーバーオペレーティングシステムのTCPスタックです。
クラウドコンピューティングなどのサービスでは、データの信頼性と可用性を高めるために、通常は複数のマシンにデータがプッシュ（複製）されます。たとえば、Hadoop 分散ファイルシステム (HDFS) は、保存されているオブジェクトの 2 つの追加コピーを作成します。RGDD は、ネットワーク上の任意のリンクを介してオブジェクトのコピーを最小限 (最良の場合は 1 つだけ) 送信することで帯域幅を節約しながら、オブジェクトを 1 つの場所から複数の場所に効率的にキャストすることに重点を置いています。たとえば、Datacast [ 21 ]は、規則的で構造化されたトポロジーに依存するデータセンター内の多数のノードへの配信スキームであり、DCCast [ 22 ]は、データセンター間での配信に対する同様のアプローチです。
プッシュ通知とは、バックエンドサーバーまたはアプリケーションからユーザーインターフェイス（モバイルアプリケーション[ 23 ]やデスクトップアプリケーションなど）に「プッシュ」されるメッセージのことです。Appleは2009年にiPhone向けにプッシュ通知を導入し[ 24 ] 、 2010年にはGoogleが「Google Cloud to Device Messaging」をリリースしました（後にGoogle Cloud Messaging、さらにFirebase Cloud Messagingに置き換えられました）。[ 25 ] 2015年11月、MicrosoftはWindows Notification ServiceをUniversal Windows Platformアーキテクチャを利用するように拡張し、ユニバーサルAPI呼び出しとPOSTリクエストを使用してWindows 10、Windows 10 Mobile、Xbox、およびその他のサポートされているプラットフォームにプッシュデータを送信できるようにすると発表しました。[ 26 ]
プッシュ通知は主にローカル通知とリモート通知の2つのアプローチに分けられます。[ 27 ]ローカル通知の場合、アプリケーションはローカルデバイスのOSで通知をスケジュールします。アプリケーションは、バックグラウンドで継続的に実行できる場合に限り、アプリケーション自体にタイマーを設定します。イベントのスケジュールされた時間に達するか、イベントのプログラムされた条件が満たされると、メッセージがアプリケーションのユーザーインターフェイスに表示されます。
リモート通知はリモートサーバーによって処理されます。このシナリオでは、クライアントアプリケーションは、一意のキー（UUIDや Appleデバイス トークンなど）を使用してサーバーに登録する必要があります。サーバーは、一意のキーに対してメッセージを送信し、HTTPやXMPPなどの合意されたクライアント/サーバー プロトコルを介してクライアントに配信します。プッシュ通知がクライアントに到着すると、短い通知やメッセージを表示したり、アプリケーション アイコンにバッジを設定したり、通知 LED を点滅または常時点灯させたり、アラート音を再生したりして、ユーザーの注意を引くことができます。[ 28 ]プッシュ通知は通常、アプリケーションがユーザーに情報を伝えるために使用されます。メッセージの内容は、次の例のカテゴリに分類できます。
リアルタイムのプッシュ通知は、ソーシャルネットワークの匿名ユーザーの仮想IDをスマートフォン所有者の実在のIDに結び付けるために使用できるため、プライバシーの問題を引き起こす可能性があります。[ 30 ]宣伝目的での不要なプッシュ通知の使用は、注意の窃盗の例として批判されています。[ 31 ]