19

または、Server-Sent Events と WebSocket が Comet 技術に取って代わりますか?

4

4 に答える 4

20

用語と歴史の両方の観点からこの答えにアプローチします。

この別の回答で書いたように、いくつかの包括的な用語の1つを使用して、WebサーバーからWebクライアントに（およびその逆に）イベントを非同期的に送信するために使用できる一連のテクノロジーを指すことができます。「プッシュテクノロジー」という用語は15年間使用されています（プッシュテクノロジーの短い歴史については、私が何年も前に書いたこの古いホワイトペーパーを見ることができます。完全な開示：私はLightstreamerの作成者です）。現在、「Webストリーミング」という用語は、ITアナリストの間でコンセンサスを得ています（Gartner、「Cool Vendors in Application and Integration Platforms、2012」、MassimoPezziniおよびJessThompson、2012年4月11日を参照）。

重要な側面は、Webベースの通信、つまりWebプロトコルの活用について話していることです。Webベースではないメッセージングプロトコルとテクノロジが多数あり（たとえば、ほとんどのMOM）、それらをプッシュテクノロジ（またはWebストリーミング）の一部とは見なしていません。

そうは言っても、プッシュテクノロジー（またはWebストリーミング）の2つのサブカテゴリを区別できます。

  • HTTPベース
  • WebSocketベース

HTTPとWebSocketはどちらもWebプロトコルです。

HTTPベースのプッシュメカニズムを展開すると、次のことがわかります。

  • HTTPストリーミング
  • HTTPロングポーリング
  • HTTPポーリング

従来、「Comet」という用語（2006年にAlex Russellによって造られた）は、HTTPストリーミングとHTTPポーリングの両方を指していました。ただし、HTTPストリーミングの最初の実装は、Cometの用語が作成されるかなり前の2000年に遡ることを考慮してください（例としては、PushletsやLightstreamerがあります）。

現在、WebSocketを使用すると、特に「逆方向」チャネル（ブラウザーからサーバーに送信されるメッセージ）のWebストリーミングの実装が簡単になります。HTTPを介したバックワードチャネルの特殊性の詳細については、CometDailyについて書いたこの記事の最後の部分を参照してください：http：//cometdaily.com/2011/07/06/push-technology-comet-and-websockets -ライトストリーマーからの10年の歴史-展望/

Philが指摘したように、Cometはまだ必要であり、おそらく数年は必要になるでしょう。古いブラウザ（WebSocketをサポートしないIE9を含む）だけでなく、WSを話さないネットワーク仲介者も無限に存在するからです。 。たとえば、一部の国（Vodafone Italyなど）の一部の携帯電話会社はWSSをサポートしていますが、WSをブロックしています。したがって、Cometの「ハック」のない世界はまだ遠いです…そして、個人的なメモとして、Cometに適用される「ハック」という用語を愛したことは一度もないことを付け加えておきます（または、より正確な歴史的観点から、 HTTPストリーミングとHTTPロングポーリングに適用されます）。これらの技術に12年間携わってきた私たちは、それらを非常に洗練させて、それ自体が本格的な技術になっていると言えます。

ここで、WebSocketが普遍的にサポートされ、Cometが不要になった世界を想像してみましょう。あなたは正確に何を手に入れますか？まあ、双方向トランスポートだけで、それ以上は何もありません...その上に、メッセージングプロトコル（おそらくpub / subに基づく）、サーバーコードと通信するためのサーバー側インターフェイス、およびすべてを構築する必要があります。帯域幅管理、データコンフレーション、自動スロットリング、デルタ配信など、データフローを管理するための最適化手法とアルゴリズムの優れたセット。優れた点は、メッセージングプロトコルと最適化メカニズムの両方が優れたCometソリューションによってすでに実装されていることです。 。したがって、以前のCometサーバーを拡張してWebSocketをサポートすることは、すべてのベンダーが実装した自然な進化です。

つまり、一言で言えば、近い将来、WebSocketによってCometトランスポートが廃止される可能性がありますが、従来のCometサーバーですでに実装および十分にテストされているすべての上位層を取り込む必要があります。

于 2012-08-22T22:11:17.260 に答える
15

Cometは、HTTPロングポールを使用して通常実装される一連のテクノロジー原則/通信パターンです。これにより、サーバーはオンデマンド（つまり、サーバープッシュ）でブラウザーにデータを送信できます。現在のcometの実装では、クライアント側で複雑なJavascriptを使用し、サーバー側でサポートする必要があります（長時間保持されるリクエストの場合）。

Server-Sent Eventsは、この種のオンデマンドサーバープッシュを有効にするための標準（HTML5）ブラウザーAPIです。サーバー送信イベントは、複雑なJavascriptで行われたことを取得し、それをブラウザー自体にプッシュダウンするものと考えることができます。

WebSocketを使用すると、ブラウザーはWebSocketをサポートするサーバーへの永続的な全二重/双方向接続を確立できます。AJAX / long-pollのように接続を維持するために、クライアントがサーバーに対して定期的にHTTPリクエストを作成し続ける必要はありません。接続が確立されると、メッセージあたりのオーバーヘッドは、通常のHTTP / HTTPロングポールのオーバーヘッドと比較して非常に低くなります（数バイト）。WebSocketを使用してサーバーを効率的にプッシュできますが、これは1つのアプリケーションにすぎません。

AJAX / comet / WebSocketsトランスポート層に基づいて構築され、セッション管理、チャネル、ブロードキャスト、pubsubなどを提供するライブラリもあります。CometDはその一例です。もう1つの一般的な例は、Socket.IOです。どちらも、基盤となるトランスポートで使用できる場合はWebSocketをサポートしますが、WebSocketが使用できない場合は標準のAJAX/long-pollもサポートします。

于 2012-08-22T18:58:12.763 に答える
10

私は当初、WebSockets が Comet を実現していると考えていました。それらは代替手段ではありません。しかし、いくつかの議論の後、私は後で修正され、「コメット」の作成者であるアレックス・ラッセルによって、そうではないことが確信されました.

@kanaka が言うように、Comet は、クライアントとサーバー間の双方向通信をシミュレートするための一連の原則です (サーバー プッシュはソリューションの半分であり、現在は Server-Sent Events と Event Source API によって提供されています)。

ただし、Comet ソリューションは、Web ブラウザー間で一貫して動作しないため、ハックです。その理由について、アレックス・ラッセルは次のように述べています。

次に、Web ソケットはコメットの一種ですか? それとも、Comet は単なる HTTP ハッキングですか? 私は後者の定義に行きます。フレーズとハックは、おそらく一緒に夕日に向かって走り出すはずです. 私は、HTTP 以外のリアルタイム オーバーロードを歓迎します。古いブラウザーのことを忘れることができる範囲で (そして、私が自分の仕事をしていることを神は知っています: http://google.com/chromeframe )、私たちは皆、「Web ソケット」と特定の傘の必要性に乗り込むことができます。離れます。

では、それに焦点を当てましょう: どうすればユーザーをピカピカの新しいブラウザ カーに誘導できるでしょうか? WebSockets に基づくアプリが提供できる豊富なリアルタイム エクスペリエンスについて、どのような提案ができるでしょうか? 彗星は過去についてです。未来を現実にしよう。

私は今、これについてアレックスと一緒にいます。ただし、HTTP ソリューションである Comet は、次の時点まで廃止されません。

  1. ブラウザのサポートは 100% で、IE10 未満の場合はフォールバックは必要ありません。Firefox、Safari、Opera のユーザーが問題になるとは思えません。Firefox などのブラウザーの自動更新プロンプトを無視するユーザーは少数ですが、多くはありません。
  2. ウイルス対策メーカー (Avast! など) は、HTML5 Web テクノロジのサポートを開始し、自社のソフトウェアが接続を妨害するのを阻止しています。
  3. 一部のインターネット インフラストラクチャは、WebSocket のサポートを確保するために更新されています。私の経験では、ポート 443 (安全な WebSocket 接続) 経由で WSS 経由で接続することは、通常、接続がファイアウォールとプロキシを経由することを意味しますが、ポート 80 経由の WS も常にサポートされるようにしたいと考えています。
于 2012-08-22T19:18:43.650 に答える
0

WebSocket は、Web および HTTP のコンテキスト内でクライアントとサーバー間で双方向に通信する方法を最も基本的なレベルで提供しますが、これは単純な通信形式です。

Comet は、WebSocket の上にさらに多くの機能を提供します (実際、cometd は websocket もサポートしています)。

  • パブリッシュ/サブスクライブや通信チャネルなど
  • Websocket が利用できない場合、古いクライアント <-> サーバー通信技術にフォールバックします
于 2012-08-22T18:17:52.070 に答える