1) WebSockets プロトコルが優れているのはなぜですか?
WebSockets は、特にクライアントからサーバーへのメッセージの待ち時間が短い通信が必要な状況に適しています。サーバーからクライアントへのデータの場合、長時間保持された接続とチャンク転送を使用して、レイテンシをかなり低くすることができます。ただし、これは、クライアントからサーバーへのメッセージごとに新しい接続を確立する必要があるクライアントからサーバーへの遅延には役立ちません。
48 バイトの HTTP ハンドシェイクは、実際の HTTP ブラウザー接続では現実的ではありません。多くのヘッダーや Cookie データを含む、要求の一部として (双方向で) 数キロバイトのデータが送信されることがよくあります。Chrome を使用するためのリクエスト/レスポンスの例を次に示します。
リクエストの例 (Cookie データを含む 2800 バイト、Cookie データなしで 490 バイト):
GET / HTTP/1.1
Host: www.cnn.com
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.68 Safari/537.17
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: [[[2428 byte of cookie data]]]
応答例 (355 バイト):
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 13 Feb 2013 18:56:27 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: CG=US:TX:Arlington; path=/
Last-Modified: Wed, 13 Feb 2013 18:55:22 GMT
Vary: Accept-Encoding
Cache-Control: max-age=60, private
Expires: Wed, 13 Feb 2013 18:56:54 GMT
Content-Encoding: gzip
HTTP と WebSocket の初期接続ハンドシェイクのサイズは同じですが、WebSocket 接続では初期ハンドシェイクが 1 回実行されるため、小さなメッセージのオーバーヘッドは 6 バイト (ヘッダーに 2 バイト、マスク値に 4 バイト) しかありません。待ち時間のオーバーヘッドは、ヘッダーのサイズによるものではなく、それらのヘッダーを解析/処理/保存するロジックによるものです。さらに、TCP 接続のセットアップ レイテンシは、各リクエストのサイズや処理時間よりも大きな要因となる可能性があります。
2) HTTP プロトコルを更新する代わりに実装したのはなぜですか?
SPDY、HTTP 2.0、QUICなど、HTTP プロトコルを再設計してパフォーマンスを向上させ、待ち時間を短縮する取り組みが行われています。これにより、通常の HTTP 要求の状況が改善されますが、WebSockets および/または WebRTC DataChannel は、HTTP プロトコルよりもクライアントからサーバーへのデータ転送のレイテンシーが依然として低い可能性があります (または、WebSockets によく似たモードで使用されます)。いずれかの方法）。
更新：
以下は、Web プロトコルについて考えるためのフレームワークです。
TCP : 低レベル、双方向、全二重、順序保証トランスポート層。ブラウザはサポートされていません (プラグイン/Flash 経由を除く)。
HTTP 1.0 : TCP で階層化された要求応答トランスポート プロトコル。クライアントが 1 つの完全な要求を行い、サーバーが 1 つの完全な応答を返した後、接続が閉じられます。リクエスト メソッド (GET、POST、HEAD) には、サーバー上のリソースに対する特定のトランザクション上の意味があります。
HTTP 1.1 : HTTP 1.0 の要求応答の性質を維持しますが、複数の完全な要求/完全な応答 (要求ごとに 1 つの応答) に対して接続を開いたままにすることができます。リクエストとレスポンスにはまだ完全なヘッダーがありますが、接続は再利用され、閉じられません。HTTP 1.1 では、特定のトランザクションの意味を持ついくつかの追加の要求メソッド (OPTIONS、PUT、DELETE、TRACE、CONNECT) も追加されました。ただし、HTTP 2.0 ドラフト提案の冒頭で述べたように、HTTP 1.1 パイプラインは広く展開されていないため、ブラウザとサーバー間のレイテンシを解決する HTTP 1.1 の有用性が大幅に制限されています。
Long-poll : HTTP (1.0 または 1.1) への「ハック」のようなもので、サーバーはクライアントの要求にすぐには応答しません (またはヘッダーで部分的にしか応答しません)。サーバーの応答後、クライアントはすぐに新しい要求を送信します (HTTP 1.1 経由の場合は同じ接続を使用)。
HTTP ストリーミング: サーバーが単一のクライアント要求に対して複数の応答を送信できるようにするさまざまな手法 (マルチパート/チャンク応答)。W3C は、これをMIME タイプを使用したサーバー送信イベントとして標準化しています。text/event-streamブラウザー API (WebSocket API にかなり似ています) は、EventSource API と呼ばれます。
コメット/サーバー プッシュ: これは、ロング ポールと HTTP ストリーミングの両方を含む包括的な用語です。Comet ライブラリは通常、複数の手法をサポートして、クロスブラウザーとクロスサーバーのサポートを最大限にしようとします。
WebSockets : HTTP フレンドリなアップグレード ハンドシェイクを使用する TCP に組み込まれたトランスポート層。ストリーミング トランスポートである TCP とは異なり、WebSocket はメッセージ ベースのトランスポートです。メッセージはネットワーク上で区切られ、アプリケーションに配信される前に完全に再構築されます。WebSocket 接続は、双方向、全二重、および長寿命です。最初のハンドシェイク要求/応答の後、トランザクション セマンティクスはなく、メッセージあたりのオーバーヘッドはほとんどありません。クライアントとサーバーはいつでもメッセージを送信でき、メッセージの受信を非同期で処理する必要があります。
SPDY : Google が開始した、より効率的なワイヤ プロトコルを使用して HTTP を拡張する提案ですが、すべての HTTP セマンティクス (要求/応答、Cookie、エンコーディング) を維持します。SPDY は、新しいフレーミング形式 (長さのプレフィックス付きフレーム) を導入し、HTTP 要求/応答ペアを新しいフレーミング レイヤーに階層化する方法を指定します。ヘッダーは圧縮でき、接続が確立された後に新しいヘッダーを送信できます。ブラウザとサーバーには SPDY の実際の実装があります。
HTTP 2.0 : SPDY と同様の目標があります。HTTP セマンティクスを維持しながら、HTTP レイテンシとオーバーヘッドを削減します。現在のドラフトは SPDY から派生したもので、ハンドシェイクとフレーミングの WebSocket 標準と非常によく似たアップグレード ハンドシェイクとデータ フレーミングを定義しています。別の HTTP 2.0 ドラフト提案 (httpbis-speed-mobility) では、実際にはトランスポート層に WebSocket を使用し、SPDY 多重化と HTTP マッピングを WebSocket 拡張として追加します (WebSocket 拡張はハンドシェイク中にネゴシエートされます)。
WebRTC/CU-WebRTC : ブラウザー間のピアツーピア接続を許可する提案。これにより、基礎となるトランスポートが TCP ではなく SDP/データグラムであるため、平均および最大レイテンシ通信が可能になる場合があります。これにより、パケット/メッセージの順不同の配信が可能になり、ドロップされたパケットによって引き起こされる遅延スパイクの TCP 問題が回避され、後続のすべてのパケットの配信が遅延します (順序どおりの配信を保証するため)。
QUIC : TCP よりも Web レイテンシを短縮することを目的とした実験的なプロトコルです。表面的には、QUIC は UDP に実装された TCP+TLS+SPDY に非常に似ています。QUIC は、HTTP/2 と同等の多重化とフロー制御、TLS と同等のセキュリティ、および TCP と同等の接続セマンティクス、信頼性、および輻輳制御を提供します。TCP はオペレーティング システム カーネルとミドルボックス ファームウェアに実装されているため、TCP に大幅な変更を加えることはほとんど不可能です。ただし、QUIC は UDP の上に構築されているため、そのような制限はありません。QUIC は、HTTP/2 セマンティクス用に設計および最適化されています。
参考文献：
HTTP :
サーバー送信イベント:
WebSocket :
SPDY :
HTTP 2.0 :
WebRTC :
クイック:
