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