コンテンツにスキップ

Push技術

出典: フリー百科事典『ウィキペディア（Wikipedia）』
（プッシュ技術から転送）

Push技術あるいはserver pushはインターネット上での通信方法の一つであり、ある通信リクエストが送り手側（中央サーバ）により開始されるものを指す。これはPull技術と対比され、こちらは通信のリクエストはクライアントにより開始される。

Pushサービスはクライアントが事前に登録した情報に基づいて行われることが多い。これは出版-購読型モデルと呼ばれる。サーバー側が提供する様々な情報の「チャンネル」にクライアントが「登録」しておき、これらのチャンネルの内の一つに新しい情報が入れば常にサーバはその情報をクライアントにプッシュ通知する。

ポーリング技術を用いて擬似的なプッシュを実現する場合もある。特に、本当のプッシュが不可能な状況下（たとえば入ってくるHTTP/Sリクエストを拒否すること要求するセキュリティポリシーをもつサイトなど）ではそうせざるをえない。

一般における利用

[編集]

通知

[編集]

同期通信やインスタントメッセージがプッシュサービスの典型例である。チャットのメッセージや、場合によってはファイルをメッセージング・サービスが受け取ると直ちにユーザにプッシュされる。分散的なPeer to Peerなプログラム（WASTEなど）でも、中央集権的なプログラムIRCやXMPPなど)でも、いずれもファイルのプッシュは可能である。つまり受け手側ではなく送り手側がデータの転送を開始することが出来る。

電子メールもプッシュ型システムと言えるかもしれない：SMTPプロトコルはプッシュ型プロトコルである（プッシュ型電子メールを参照）。しかしながら、メールサーバーからデスクトップのコンピュータへ伝送する最後の段階では、POP3やIMAPのようなプル型プロトコルが使われるのが典型的である。現代の電子メールクライアントは、この段階において繰り返しメールサーバーにポーリングして、頻繁に新しいメールがないかチェックすることで、あたかも即時的に伝送されているかのようにみえるようにしている。IMAPプロトコルにはIDLE命令というものがあり、これは新着メッセージがあるときクライアントにサーバが通知することを許可する。

別の例としてはPointCast（英語版）ネットワークというものがある。これは1990年代に広く受け入れられたもので、ニュースや株式データをスクリーンセーバーとして配信するものだ。ブラウザ戦争でネットスケープとマイクロソフトが激しく争っていた当時、両者ともChannel Definition Format（英語版） (CDF) を通じたプッシュ技術を組み込んだが、広く普及することはなかった。CDFは次第に消え去り、2000年代にはプル型システムであるRSSに取って代わられた。

その他の例としては、プッシュ可能なウェブアプリケーションの利用である。例えば市場データ配信（株式相場表示機)、オンラインのチャットやメッセージング・システム、オークション、オンラインゲーム、スポーツ結果配信、コンソール監視、センサー網監視などで利用されている。

読み込み高速化

[編集]

従来のウェブサイトはHTTPリクエストによってhtmlファイルを読み込んだ後、htmlに書かれた内容を元にCSSファイルのリクエスト、さらにCSSファイルを元に画像ファイルをリクエストといった具合に、サイトが表示される前に何度かサーバー-クライアント間を往復する必要があった。

だがプッシュ技術を用いれば相手のリクエストを待たずに必要そうなファイルを送りつけることで往復回数(ラウンドトリップ回数)を減らすことが出来、サイトの読み込みが高速化される。[1]

だがキャッシュがある場合既に持っているファイルを送りつけることになってしまい無駄に帯域を使い通信量がかさむ結果になってしまうこともある。どのリソースをプッシュすべきかの判断はとても難しい。[2]

実現方法

[編集]

HTTP server push

[編集]

HTTP server push (HTTP streaming) は非同期データをウェブサーバからブラウザへデータを転送する方法である。HTTP server pushは幾つかの仕組みで実現することができる。

HTML5の一部であるWebSocket API はウェブサーバとクライアントが全二重のTCP接続で通信することを可能にしている。

一般的に言えば、HTTP server pushでは、ウェブサーバはレスポンスデータをクライアントに返した後も接続を切断しない。ウェブサーバは、イベント（たとえば一つまたは複数のクライアントに通知する必要がある内部データに変更が生じた場合など）が起こった場合に直ちにそれを送出できるように、接続を開いたままにしておく。もし接続を閉じてしまってたら、そのイベントの通知はクライアントから次にリクエストを受信するまで待機しておかねばならなくなる。多くのウェブサーバはCGIを介してこの機能を提供している（例えば、Apache上のNon-Parsed Headersスクリプトなど）。この手法の基盤にある仕組みはHTTP/1.1のchunked transfer encodingである。

別の仕組みとしては、1995年にネットスケープが導入したmultipart/x-mixed-replaceという特殊なMIMEタイプに関係するものである。ウェブブラウザはこのMIMEタイプを、サーバ側がクライアントに新しいバージョンを伝えたい場合にはいつでも変わりうる文書であると解釈する[3]。これは今日でもなおFirefox、Opera、Safariがサポートしているが、Internet Explorerはこれを無視している[4]。これはHTMLドキュメントに適用できるほか、ストリーミング画像やウェブカメラアプリケーションにも適用できる。

WHATWGの Web Applications 1.0提案[5]には、コンテンツをクライアントにプッシュする仕組みが含まれている。2006年9月1日、この新しい実験的なシステムをOperaがServer-sent events（英語版）と呼ばれる機能の中で実装した[6][7]。これは今ではHTML5の一部として標準化されている[8]。

Java pushlet

[編集]

pushletはもともとJavaプラットフォームウェブアプリケーションのために開発されたものであるが、これは他のウェブフレームワークにも適用可能である。

この技術では、サーバが持続的HTTP接続の利点を用いて、レスポンスを永続的に開けた状態のままにしておく（つまり、サーバはそのレスポンスを決して終わらせない）。これは実際的には、最初のページのロードが完了したとみなせる状態になった後も、ブラウザ側を引き続き「ロード中」の状態のままでいさせるために、ブラウザをだましているのである。それからサーバは定期的にJavaScriptの小さなコードを送って、ページの内容を更新し続け、これによりプッシュ機能が実現される。この技術を使うと、クライアントはサーバ側との接続を開き続けておくためにJavaアプレットやその他のプラグインを必要とせず、サーバからプッシュされた新しいイベントの通知を自動的に受けられる[9][10] 。しかしながら、この手法には一つ深刻な欠点がある。それはサーバ側でブラウザ側のタイムアウトを制御する手段がないことである。ブラウザ側でタイムアウトが発生した場合はページの再読み込みが常に必要となる。

Long polling

[編集]

Long pollingそれ自体は本当のプッシュではない。Long pollingは従来のポーリング技術の一種であるが、本当のプッシュが不可能な状況下（たとえば入ってくるHTTP/Sリクエストを拒否すること要求するセキュリティポリシーをもつサイトなど）で擬似的なプッシュ機構を作ることを可能にする。

Long pollingでは、通常のポーリングと全く同様に、クライアント側からサーバへ情報をリクエストするが、ここではサーバ側がすぐにはレスポンスを返さないかもしれないことを期待している。クライアントからの問い合わせを受信したときに、サーバ側には当該クライアントに送るべき新着情報がなかった場合、サーバ側は空のレスポンスを返すのではなく、そのリクエストを開いたままにしておき、レスポンスとして返すべき情報が来るまで待つ。サーバに新着情報が来たら、サーバは直ちにクライアントにHTTP/Sレスポンスを返し、開いていたHTTP/Sリクエストを完了させる。サーバ側からのレスポンスを受け取ったら、クライアント側は直ちにサーバへの新しいリクエストを発出することが多い。このようにして、通常のポーリングにおいて生ずるレスポンス遅延（新着情報がサーバにきてから、その次にクライアントがリクエストするまでの時間）をなくすことができる[11]。

例えばBOSHは、持続的TCP接続を（たとえばブラウザ内で）直接利用することが困難または不可能な場合に使える、Long-polling版の代替技術として人気のある長寿命HTTP技術であり[12]、AppleのiCloudのプッシュサポートに使われているXMPPの基盤技術もBOSHである。

Flash XMLSocket リレー

[編集]

Cboxやその他のチャットで使われているFlash XMLSocket リレー技術は、1ピクセルのAdobe Flashムービー内のXMLSocketオブジェクトを活用するものだ。JavaScriptの制御の下、クライアントはサーバ上の単方向性リレーサーバにTCP接続を確立する。このリレーサーバはこのソケットからは何も読まず、直ちに一意な識別符号をクライアントに送り返す。次に、クライアントはこの識別符号を入れたHTTPリクエストをウェブサーバに送る。するとウェブアプリケーションはそのクライアント宛てのメッセージを、そのリレーサーバのローカルインターフェイスに向けてプッシュできる。メッセージを受け取ったリレーサーバが、それらをFlashソケットへ中継する。

この手法の利点は、チャットを含む多くのウェブアプリケーションにおいて典型的かつ自然な、読み出し/書き込みの非対称性を正しく反映している点である。その結果として高い効率性が得られている。サーバ側からみて外向きに出ていくだけの単方向性ソケットでは、リレーサーバはサーバからデータが来るのを待っているだけでよいので、サーバに対して全く問い合わせをしない。これにより、数万件の同時接続でも開けっ放しで保持することができる。このモデルにおいて考慮すべき限界は、下層にあるサーバのOSのTCPスタックである。

その他の手法

[編集]

Cometという表現がAjaxウェブアプリケーションに使用されるプッシュ技術を指すときに用いられる。HTTP server pushやlong pollingなどの技術を包括した表現である。

XMPPはPubSub 拡張によりプッシュアプリケーションに使用されることが多い。

この他近年ではWebSocketやSPDYなど、プッシュ技術に対応した新たなプロトコルも複数提案されている。

IETFが提案している RFC 8030 Web pushプロトコルはHTTP/2を用いてリアルタイムなイベント（電話やメッセージの着信など）を即時的に配達（プッシュ）するための単純なプロトコルである。このプロトコルは全てのリアルタイムなイベントを一つのセッションの中に整理統合することで、ネットワークおよび無線資源をより効率よく利用することを保証する。一つのサービスが全てのイベントを集約して、各種アプリに配送する。これにはセッションが一つだけあればよいので、オーバーヘッドのコストが重複することを避けられる。また、これに対応するPush APIをW3Cが開発している。

出典

[編集]
  1. ^ “HTTP/2 Server Pushとは？(CDN サーバープッシュでWeb高速化）”. REDBOX Labo (2019年11月10日). 2021年10月29日閲覧。
  2. ^ “Server push - HTTP/3 explained”. 2021年10月29日閲覧。
  3. ^ CGI Programming on the World Wide Web Netscapeのサーバープッシュの使用法を説明したO'Reilly 本
  4. ^ Server-Push Documents (HTML & XHTML: The Definitive Guide) サーバープッシュを解説したオライリー本
  5. ^ “Web Applications 1.0 specification”. 2007年2月24日閲覧。
  6. ^ “Event Streaming to Web Browsers” (2006年9月1日). 2007年3月23日閲覧。
  7. ^ “Opera takes the lead with AJAX support among browsers: More efficient streaming” (2006年9月1日). 2007年3月23日閲覧。
  8. ^ Server-Sent Events
  9. ^ Pushlets introduction
  10. ^ pushletsに関するJavaWorldの記事
  11. ^ “RFC6202 - Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP”. 2016年5月14日閲覧。
  12. ^ “XEP-0124: Bidirectional-streams Over Synchronous HTTP (BOSH)”. 2012年6月26日閲覧。

関連項目

[編集]

外部リンク

[編集]
スタブアイコン

この項目は、コンピュータに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています（PJ:コンピュータ/P:コンピュータ）。

「https://ja.wikipedia.org/w/index.php?title=Push技術&oldid=97836963」から取得