多くの分野をカバーする他の人からのいくつかの素晴らしい回答。ここで少し補足です。
Java アプレット、Flash、Silverlight などのプラグインに対する WebSocket の唯一の利点は、WebSocket がブラウザーにネイティブに組み込まれており、プラグインに依存しないことです。
これが、Java アプレット、Flash、または Silverlight を使用してソケット接続を確立できるという意味であれば、可能です。ただし、制限があるため、現実の世界に展開されることはあまりありません。
たとえば、仲介者はそのトラフィックをシャットダウンすることができ、実際にシャットダウンします。WebSocket 標準は、既存の HTTP インフラストラクチャと互換性があるように設計されているため、ファイアウォールやプロキシなどの仲介者による干渉を受ける可能性がはるかに低くなります。
さらに、WebSocket は専用ポートを必要とせずにポート 80 と 443 を使用できます。これも、プロトコル設計が既存の HTTP インフラストラクチャと可能な限り互換性を持つようになっているためです。
これらの代替ソケット (Java、Flash、および Silverlight) は、クロスオリジン アーキテクチャで安全に使用することは困難です。したがって、クロスオリジンでそれらを使用しようとすることが多い人々は、それを安全に行う努力をするのではなく、不安を許容します.
また、追加の「非標準」ポートを開く必要がある場合 (管理者がやりたがらないこと) や、管理が必要なポリシー ファイルが必要になる場合もあります。
要するに、ソケット接続に Java、Flash、または Silverlight を使用することには十分な問題があるため、深刻なアーキテクチャに展開されることはあまりありません。Flash と Java には、おそらく少なくとも 10 年間はこの機能がありましたが、まだ普及していません。
WebSocket 標準は、これらの制限を念頭に置き、できればそこからいくつかの教訓を学び、新鮮なアプローチから始めることができました。
一部の WebSocket 実装では、WebSocket 接続を確立できない場合 (古いブラウザーで実行している場合や仲介者が干渉している場合など) に、フォールバックとして Flash (またはおそらく Silverlight や Java) を使用します。
これらの状況に対するある種のフォールバック戦略は賢明であり、必要でさえありますが、Flash などを使用するほとんどの人は上記の欠点に悩まされます。そうである必要はありません -- Flash、Silverlight などを使用してセキュアなクロスオリジン対応の接続を実現するための回避策があります -- しかし、ほとんどの実装ではそれが簡単ではないため行われません。
たとえば、クロスオリジン接続のために WebSocket に依存している場合、それは正常に機能します。しかし、その後、古いブラウザーで実行したり、ファイアウォール/プロキシが干渉したり、フォールバックとして Flash に依存したりすると、同じクロスオリジン接続を行うのが難しくなります。もちろん、セキュリティを気にしない限り。
つまり、かなりの作業を行うか、それをうまく行ったフレームワークを使用する準備ができていない限り、ネイティブ接続と非ネイティブ接続で機能する単一の統合アーキテクチャを持つことは困難です。理想的なアーキテクチャでは、接続がネイティブかどうかに気付かないでしょう。セキュリティ設定はどちらの場合でも機能します。クラスタリング設定は引き続き機能します。容量計画は引き続き有効です。等々。
HTTP ストリーミングに対する WebSocket の唯一の利点は、受信したデータを「理解」して解析する努力をする必要がないことです。
HTTP ストリームを開いて、数分、数時間、またはそれ以上データが流れるのをじっと待っているだけという単純なものではありません。クライアントが異なれば動作も異なり、それを管理する必要があります。たとえば、一部のクライアントはデータをバッファリングし、しきい値に達するまでアプリケーションに解放しません。さらに悪いことに、接続が閉じられるまでデータをアプリケーションに渡さないものもあります。
そのため、複数のメッセージをクライアントに送信している場合、たとえば 50 メッセージ分のデータが受信されるまで、クライアント アプリケーションがデータを受信しない可能性があります。それはあまりにもリアルタイムではありません。
HTTP ストリーミングは、WebSocket が利用できない場合の実行可能な代替手段になる可能性がありますが、万能薬ではありません。現実世界の条件で、Web の荒れ地で堅牢な方法で作業するには、十分な理解が必要です。
私が見逃している他の重要な違いはありますか?
まだ誰も言及していないことがもう1つありますので、それを取り上げます。
WebSocket プロトコルは、上位レベルのプロトコルのトランスポート層として設計されました。WebSocket 接続を介して直接 JSON メッセージなどを送信できますが、標準またはカスタム プロトコルを伝送することもできます。
たとえば、人々がすでに行っているように、WebSocket を介して AMQP または XMPP を実行できます。したがって、クライアントは、あたかもブローカー自体に直接接続されているかのように (場合によってはそうです)、AMQP ブローカーからメッセージを受信できます。
または、何らかのカスタム プロトコルを備えた既存のサーバーがある場合は、それを WebSocket 経由で転送して、そのバックエンド サーバーを Web に拡張できます。多くの場合、企業内でロックされている既存のアプリケーションは、バックエンド インフラストラクチャを変更することなく、WebSocket を使用して範囲を広げることができます。
(当然のことながら、これらすべてを安全に実行できるようにしたいので、ベンダーまたは WebSocket プロバイダーに確認してください。)
一部の人々は、WebSocket を Web 用の TCP と呼んでいます。TCP が高レベルのプロトコルを転送するのと同じように、WebSocket も転送しますが、Web インフラストラクチャと互換性のある方法で転送します。
そのため、WebSocket を介して直接 JSON (またはその他の) メッセージを送信することは常に可能ですが、既存のプロトコルも考慮する必要があります。やりたいことがたくさんあるので、それを実行するためにすでに考えられているプロトコルがおそらくあるからです。
すでに SO にある多くの質問を 1 つの質問に再質問したり、組み合わせたりする場合は申し訳ありませんが、これらの概念に関して SO と Web にあるすべての情報から完全に理解したいと思います。
これは素晴らしい質問でした。回答はすべて非常に有益でした。
