コメット（プログラミング）

Comet は、長年使われてきたHTTPSリクエストによって、ブラウザが明示的にリクエストしなくても、ウェブサーバーがブラウザにデータをプッシュできるウェブアプリケーションモデルです。 ^{[1] [2]} Cometは包括的な用語で、このやり取りを実現するための複数の手法を網羅しています。これらの方法はすべて、非デフォルトのプラグインではなく、ブラウザにデフォルトで含まれている機能(JavaScriptなど) に依存しています。Comet のアプローチは、ブラウザが一度に完全なウェブページを要求するウェブの元のモデルとは異なります。^[3]

ウェブ開発におけるコメット技術の使用は、コメットという単語が技術全体の 新語として使われる以前からありました。コメットは、 Ajax Push、^{[4] [5]} リバースAjax、^[6] 双方向ウェブ、^[7] HTTPストリーミング、^[7] HTTPサーバープッシュ^[8]など 、他 のいくつかの名前で知られています。^[9]コメットという用語は頭字語ではなく、アレックスラッセルが2006年のブログ投稿で作った造語です。^{[10] [要出典]}

近年、WebSocketおよびサーバー送信イベントの標準化と広範なサポートにより、Comet モデルは時代遅れになりました。

Javaアプレットをブラウザに埋め込む機能（ 1996年3月のNetscape Navigator 2.0から^[11] ）により、生のTCPソケット^[12]を使用してブラウザとサーバー間の通信を行い、双方向の持続的な通信が可能になりました。このソケットは、ブラウザがアプレットをホストしているドキュメントにアクセスしている限り開いたままになります。イベント通知は、テキストまたはバイナリの任意の形式で送信でき、アプレットによってデコードされます。

ブラウザ間通信を使用した最初のアプリケーションはTango Interactiveで、^{[13] [検証失敗]、 1996年から1998年にかけて}DARPAの資金援助を受けてシラキュース大学のNortheast Parallel Architectures Center (NPAC)で実装されました。TANGOアーキテクチャはシラキュース大学によって特許を取得しています。 ^[14] TANGOフレームワークは遠隔教育ツールとして広く使用されています。^[15]このフレームワークはCollabWorxによって商品化され、米国国防総省の10数個の指揮統制および訓練アプリケーションで使用されています^[要出典]。

最初の Comet 実装は 2000 年に遡り、^{[16] [信頼できない情報源? ]} Pushlets、Lightstreamer、KnowNow プロジェクトで始まりました。Just van den Broecke が作成したフレームワークであるPushlets は、最初の^[17]オープンソース実装の 1 つでした。Pushlets は、サーバー側の Java サーブレットとクライアント側の JavaScript ライブラリに基づいていました。Netscapeの共同設立者であるMarc Andreessenが支援するシリコンバレーの新興企業である Bang Networks は 、多額の資金を投じて、Web 全体を対象としたリアルタイム プッシュ標準の作成に取り組みました。^[18]

2001 年 4 月、チップ・モーニングスターは、自身が設計したカスタム HTTP サーバーとダグラス・クロックフォードが設計したクライアントとの間で 2 つの通信チャネルを開いたままにするために 2 つの HTTP ソケットを使用する Java ベース (J2SE) の Web サーバーの開発を開始しました。2001 年 6 月の時点では、機能するデモ システムが存在していました。 ^[要出典]サーバーとクライアントは、クロックフォードの提案に従って、State Software, Inc. の創設者がJSONと名付けることに同意したメッセージング フォーマットを使用しました。システム全体、クライアント ライブラリ、JSON として知られるメッセージング フォーマット、およびサーバーは、State Application Framework となり、その一部は Sun Microsystems、Amazon.com、EDS、および Volkswagen によって販売され、使用されました。^[要出典]

2006年3月、ソフトウェアエンジニアのアレックス・ラッセルは、自身のブログの投稿で「コメット」という造語を生み出した。^[19]この新しい用語は、Ajax（Ajaxとコメットはどちらも米国で一般的な家庭用洗剤）をもじったものだった。^{[20] [21] [22]}

2006 年には、いくつかのアプリケーションがこれらの技術をより広いユーザーに公開しました。Meeboのマルチプロトコル Web ベース チャット アプリケーションにより、ユーザーはブラウザーを介して AOL、Yahoo、Microsoft のチャット プラットフォームに接続できるようになりました。GoogleはGmailにWebベースチャットを追加しました。その後 Google に買収されたスタートアップのJotSpot は、Comet ベースのリアルタイム共同ドキュメント編集を構築しました。^{[23] Java ベースの}ICEfaces JSFフレームワーク (ただし、彼らは「 Ajax Push」という用語を好みます^[5] )など、新しい Comet の派生が作成されました。以前は Java アプレット ベースのトランスポートを使用していた他のアプリケーションは、純粋な JavaScript 実装に切り替えました。^[24]

Comet アプリケーションは、サーバーとクライアント間の永続的または長時間持続する HTTP 接続を使用して、双方向の持続的なインタラクションを提供することで、ページごとの Web モデルと従来のポーリングの制限を排除しようとします。ブラウザーとプロキシはサーバー イベントを考慮して設計されていないため、これを実現するためのいくつかの手法が開発されてきましたが、それぞれに利点と欠点があります。最大のハードルはHTTP 1.1 仕様で、「この仕様では、クライアントが複数の接続を開くときに慎重になることを推奨しています」と記載されています。^[25]そのため、リアルタイム イベント用に 1 つの接続を開いたままにしておくと、ブラウザーの使いやすさに悪影響があります。ブラウザーは、一連の画像などの前の要求の結果を待っている間、新しい要求を送信できなくなる可能性があります。この問題を回避するには、リアルタイム情報用に別のホスト名を作成します。このホスト名は、同じ物理サーバーの別名です。この戦略は、ドメイン シャーディングの応用です。

Comet を実装する具体的な方法は、ストリーミングとロング ポーリングという 2 つの主要なカテゴリに分類されます。

ストリーミング Comet を使用するアプリケーションは、すべての Cometイベントに対してクライアント ブラウザーからサーバーへの単一の永続的な接続を開きます。これらのイベントは、サーバーが新しいイベントを送信するたびにクライアント側で段階的に処理および解釈され、どちらの側も接続を閉じることはありません。^[3]

ストリーミング Comet を実現するための具体的な手法は次のとおりです。

動的 Web アプリケーションの基本技術は、非表示のiframe HTML 要素 (インライン フレーム、Web サイトが 1 つの HTML ドキュメントを別の HTML ドキュメント内に埋め込むことを可能にする) を使用することです。この非表示の iframe はチャンクブロックとして送信され、暗黙的に無限長であると宣言されます (「永久フレーム」と呼ばれることもあります)。イベントが発生すると、iframe はscriptブラウザーで実行される JavaScript を含むタグで徐々に埋められます。ブラウザーは HTML ページを段階的にレンダリングするため、各scriptタグは受信時に実行されます。一部のブラウザーでは、解析と実行を開始する前に特定の最小ドキュメント サイズが必要です。これは、最初に 1～2 KB のパディング スペースを送信することで取得できます。^[26]

iframes方式の利点の1つは、一般的なブラウザすべてで動作することです。この手法の2つの欠点は、信頼性の高いエラー処理方法がないことと、リクエスト呼び出しプロセスの状態を追跡できないことです。^[26]

XMLHttpRequest ( XHR ) オブジェクトは、Ajax アプリケーションがブラウザーとサーバーの通信に使用するツールですが、XHR 応答のカスタム データ形式を生成し、ブラウザー側の JavaScript を使用して各イベントを解析することで、サーバーとブラウザー間の Comet メッセージングにも使用できます。onreadystatechange新しいデータを受信するたびにブラウザーがコールバックを実行するだけになります。

上記のストリーミング トランスポートはどれも、副作用なしにすべての最新ブラウザーで動作するわけではありません。そのため、Comet 開発者は、ブラウザーに応じて切り替えながら、複数の複雑なストリーミング トランスポートを実装する必要があります。その結果、多くの Comet アプリケーションはロング ポーリングを使用します。ロング ポーリングはブラウザー側で実装しやすく、少なくとも XHR をサポートするすべてのブラウザーで動作します。名前が示すように、ロング ポーリングでは、クライアントがサーバーをポーリングしてイベント (またはイベント セット) を検出する必要があります。ブラウザーはサーバーに Ajax スタイルの要求を送信します。サーバーは、ブラウザーに送信する新しいデータがあるまで開いたままになり、そのデータは完全な応答としてブラウザーに送信されます。ブラウザーは、後続のイベントを取得するために、新しいロング ポーリング要求を開始します。IETF RFC 6202「双方向 HTTP でのロング ポーリングとストリーミングの使用に関する既知の問題とベスト プラクティス」では、ロング ポーリングと HTTP ストリーミングを比較しています。ロング ポーリングを実現するための具体的なテクノロジには、次のものがあります。

ほとんどの場合、XMLHttpRequestロング ポーリングは、XHR の標準的な使用法と同様に機能します。ブラウザーはサーバーに非同期要求を行い、サーバーは応答する前にデータが利用可能になるまで待機する場合があります。応答には、クライアントによって実行されるエンコードされたデータ (通常はXMLまたはJSON ) または Javascript を含めることができます。応答の処理の最後に、ブラウザーは別の XHR を作成して送信し、次のイベントを待機します。したがって、ブラウザーは常にサーバーに要求を未処理のままにしておき、イベントが発生するたびに応答するようにします。

どの Comet トランスポートもサブドメイン間で動作するようにできますが、クロスサイト スクリプティング攻撃を防ぐように設計されたブラウザー セキュリティ ポリシーのため、上記のトランスポートはいずれも異なる第 2 レベル ドメイン(SLD) 間では使用できません。 ^[27]つまり、メインの Web ページが 1 つの SLD から提供され、Comet サーバーが別の SLD (クロスオリジン リソース共有が有効になっていない) にある場合、それらのトランスポートを使用して、Comet イベントを使用してメイン ページの HTML と DOM を変更することはできません。この問題は、一方または両方のソースの前にプロキシ サーバーを作成し、それらが同じドメインから発信されたように見せることで回避できます。ただし、複雑さやパフォーマンス上の理由から、これは多くの場合望ましくありません。

iframe や XMLHttpRequest オブジェクトとは異なり、タグは任意のURIscriptを指すことができ、応答内の JavaScript コードは現在の HTML ドキュメントで実行されます。これにより、関係する両方のサーバーに潜在的なセキュリティ リスクが生じますが、データ プロバイダー (この場合は Comet サーバー) に対するリスクはJSONP を使用することで回避できます。

ロングポーリングの Comet トランスポートは、動的にscript要素を作成し、そのソースを Comet サーバーの場所に設定することで作成できます。その後、Comet サーバーは、イベントをペイロードとして JavaScript (または JSONP) を返します。スクリプト要求が完了するたびに、ブラウザは XHR ロングポーリングの場合と同様に新しいスクリプト要求を開きます。この方法の利点は、クロスブラウザでありながら、クロスドメイン実装も可能であることです。^[27]

ブラウザネイティブ テクノロジーは、Comet という用語に内在しています。非ポーリング HTTP 通信を改善するための試みは、さまざまな側面から行われてきました。

• Webハイパーテキストアプリケーション技術ワーキンググループ（WHATWG）が作成したHTML 5のドラフト仕様では、いわゆるサーバー送信イベント[28]が指定されており、新しいJavaScriptインターフェイス^と新しいMIMEタイプが定義されています。Microsoft Internet Explorerを除くすべての主要ブラウザにはこの技術が組み込まれています。EventSourcetext/event-stream
• HTML 5 WebSocket APIワーキングドラフトでは、サーバーとの永続的な接続を作成し、コールバックを介してメッセージを受信する方法が指定されていますonmessage。^[29]
• Dojo Foundationによる Bayeux プロトコル。ブラウザ固有のトランスポートはそのままにして、ブラウザとサーバー間の通信のための高レベルプロトコルを定義します。クライアント側の JavaScriptコードを複数の Comet サーバーで再利用し、同じ Comet サーバーが複数のクライアント側の JavaScript 実装と通信できるようにします。Bayeux はパブリッシュ/サブスクライブ モデルに基づいているため、Bayeux をサポートするサーバーにはパブリッシュ/サブスクライブが組み込まれています。^[30]
• XMPP 標準財団による BOSHプロトコル。2 つの同期 HTTP 接続を使用して、ブラウザーとサーバー間の双方向ストリームをエミュレートします。
• Douglas Crockfordによって提案されたJSONRequestオブジェクトは、XHRオブジェクトの代替となるだろう。^[31]
• JavaアプレットやAdobe Flash（ FlashアプリケーションへのデータストリーミングにRTMPプロトコルを使用）などのプラグインの使用。これらのプラグインには、適切なプラグインがインストールされているすべてのブラウザで同じように動作し、HTTP接続に依存する必要がないという利点がありますが、プラグインをインストールする必要があるという欠点があります。
• GoogleはGoogle App Engine用の新しいChannel API ^[32]を発表し、^[33]ブラウザ上のクライアントJavaScriptライブラリの助けを借りてCometのようなAPIを実装しました。このAPIは非推奨となりました。^[34]

• プッシュテクノロジー
• プルテクノロジー

• 「Comet Daily」。2008 年 1 月 4 日にオリジナルからアーカイブ。2007 年 11 月 29 日に取得。Comet Daily は、Comet の技術に関する情報を提供します。*