[解決済み] HTTPポーリング、ロングポーリング、HTTPストリーミング、WebSocketについての理解

質問

質問タイトルにあるキーワードについて、SOやWeb上で多くの投稿を読み、そこから多くを学びました。私が読んだ質問の中には、特定の実装上の課題に関連するものもあれば、一般的な概念に焦点を当てたものもあります。私はただ、すべてのコンセプトと、なぜ技術Xが技術Yよりも発明されたのか、などの理由を理解したことを確認したいのです。それでは、どうぞ。

Http ポーリング。 基本的にはAJAXで、XmlHttpRequestを使用します。

Http Long Pollingです。 AJAXですが、サーバーが更新しない限りレスポンスを保持し、サーバーが更新するとすぐにそれを送信し、クライアントは別のリクエストを送信することができます。欠点は、追加のヘッダーデータを前後に送信する必要があり、追加のオーバーヘッドを引き起こすことです。

Http ストリーミング。 ロングポーリングと似ていますが、サーバーは "Transfer Encoding: chunked" のヘッダーで応答するので、サーバーがデータを送るたびに新しいリクエストを開始する必要はありません（したがって、追加のヘッダーオーバーヘッドを節約することができます）。ここでの欠点は、サーバーによって送信された複数のチャンクを区別するために、データの構造を理解する必要があることです。

Java アプレット、Flash、Silverlight。 これらはtcp/ip上でソケットサーバに接続する機能を提供しますが、プラグインであるため、開発者はそれらに依存したくはないでしょう。

ウェブソケット。 は、上記の方法の欠点に以下の方法で対処しようとする新しいAPIです。

• Java アプレット、Flash、または Silverlight のようなプラグインに対する WebSockets の唯一の利点は、WebSockets がブラウザにネイティブに組み込まれており、プラグインに依存しないことです。
• http ストリーミングに対する WebSockets の唯一の利点は、受信したデータを理解し解析するための努力をする必要がないことです。
• Long Polling に対する WebSockets の唯一の利点は、余分なヘッダー サイズとランプ、リクエストのためのソケット接続の開始と終了が不要になることです。

私が見逃している他の重要な相違点はありますか。私が再質問しているか、SO ですでにある多くの質問を 1 つの質問に組み合わせているのであれば申し訳ありませんが、私はちょうどこれらの概念に関して SO と Web にあるすべての情報から完全に意味をなすようにしたいと思っています。

ありがとうございます！

どのように解決するのですか？

ご指摘いただいた以外にも違いがあります。

デュプレックス/ディレクショナル。

• 単方向：HTTPポーリング、ロングポーリング、ストリーミング。
• 双方向性。WebSocket、プラグインネットワーキング

レイテンシーの大きい順に並べると（概算）。

• ウェブソケット
• プラグイン・ネットワーキング
• HTTP ストリーミング
• HTTP ロングポーリング
• HTTP ポーリング

CORS (クロスオリジンサポート)。

• ウェブソケット: はい
• プラグイン・ネットワーキング。ポリシー リクエストによる Flash (その他は不明)
• HTTP * (最近のいくつかのサポート)

ネイティブのバイナリデータ(型付き配列、ブロブ)。

• ウェブソケット: はい
• プラグイン・ネットワーキング: Flash では不可 (ExternalInterface を介した URL エンコードが必要)
• HTTP *: バイナリ型のサポートを有効にするための最近の提案

効率が低下する帯域幅

• プラグインのネットワーキング。フラッシュソケットは、最初のポリシー要求を除いて raw です。
• WebSocket: 接続設定のハンドシェイクとフレームごとの数バイト
• HTTP ストリーミング (サーバー接続の再利用)
• HTTP ロングポーリング: メッセージごとに接続
• HTTP ポーリング: すべてのメッセージに接続 + データメッセージなし

モバイルデバイスのサポート。

• WebSocket: iOS 4.2 以降。一部の Android では、Flash エミュレーションを使用するか Android 版 Firefox または Android 向け Google Chrome で、いずれもネイティブの WebSocket サポートを提供しています。
• プラグインネットワーキング：一部のAndroid。iOS では未対応
• HTTP *: ほとんどが有効

Javascript の使用の複雑さ (最も単純なものから最も複雑なものまで)。確かに、複雑さの測定はやや主観的です。

• ウェブソケット
• HTTP ポーリング
• プラグインネットワーキング
• HTTP ロングポーリング、ストリーミング

また、HTTP ストリーミングを標準化するための W3C の提案として、以下のものがあることに注意してください。 サーバー送信イベント . これは現在、進化のかなり初期段階にあり、WebSocket に匹敵するシンプルさを備えた標準的な Javascript API を提供するよう設計されています。