☰

WebSocketプロトコルとHTTPの比較 質問する

tag-icon • tag-icon ajax http websocket comet
WebSocketプロトコルとHTTPの比較 質問する

WebSocket と HTTP に関するブログや議論は数多くあり、多くの開発者やサイトが WebSocket を強く推奨していますが、それでもその理由は理解できません。

たとえば (WebSocket 愛好家の議論):

HTML5 Web ソケットは、Web 通信の次の進化形であり、Web 上の単一のソケットを介して動作する全二重の双方向通信チャネルです。 -ウェブソケット

HTTP はストリーミングをサポートしています: リクエスト ボディ ストリーミング (大きなファイルをアップロードするときに使用) とレスポンス ボディ ストリーミング。

WebSocket で接続を確立する際、クライアントとサーバーはフレームごとに 2 バイトのデータを交換しますが、連続ポーリングを行う場合の HTTP ヘッダーは 8 キロバイトです。

なぜその 2 バイトには TCP と TCP プロトコルのオーバーヘッドが含まれていないのでしょうか?

GET /about.html HTTP/1.1
Host: example.org

これは約 48 バイトの HTTP ヘッダーです。

HTTP チャンクエンコーディング -チャンク転送エンコーディング:

23
This is the data in the first chunk
1A
and this is the second one
3
con
8
sequence
0
  • したがって、各チャンクあたりのオーバーヘッドは大きくありません。

また、両方のプロトコルは TCP 上で動作するため、長時間接続に関する TCP の問題はすべて依然として存在します。

質問:

  1. WebSocket プロトコルが優れているのはなぜですか?
  2. HTTP プロトコルを更新する代わりにこれを実装したのはなぜですか?

ベストアンサー1

1) WebSocket プロトコルが優れているのはなぜですか?

WebSocket は、低遅延通信を伴う状況、特にクライアントからサーバーへのメッセージの低遅延を伴う状況に適しています。サーバーからクライアントへのデータの場合、長時間接続とチャンク転送を使用して、かなり低い遅延を実現できます。ただし、これは、クライアントからサーバーへのメッセージごとに新しい接続を確立する必要があるクライアントからサーバーの遅延には役立ちません。

48 バイトの HTTP ハンドシェイクは、多くのヘッダーや Cookie データを含む数キロバイトのデータがリクエストの一部として (双方向で) 送信されることが多い実際の HTTP ブラウザ接続では現実的ではありません。以下は 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 プロトコルを更新する代わりに実装されたのはなぜですか?

パフォーマンスの向上とレイテンシの低減を実現するために、HTTPプロトコルを再設計する取り組みが行われている。スパイディ、HTTP 2.0そしてクイックこれにより、通常の HTTP リクエストの状況は改善されますが、WebSocket や WebRTC DataChannel は、クライアントからサーバーへのデータ転送のレイテンシが HTTP プロトコルよりも低くなる可能性があります (または、いずれにしても WebSocket によく似たモードで使用されることになります)。

アップデート：

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 の有用性は大幅に制限されます。

  • ロング ポーリング: HTTP (1.0 または 1.1) に対する一種の「ハック」で、サーバーはクライアントの要求に対してすぐには応答しません (またはヘッダーで部分的にのみ応答します)。サーバーが応答した後、クライアントはすぐに新しい要求を送信します (HTTP 1.1 の場合は同じ接続を使用します)。

  • HTTPストリーミング: サーバーが単一のクライアント要求に対して複数の応答を送信できるようにするさまざまな技術（マルチパート/チャンク応答）。W3Cはこれを次のように標準化しています。サーバー送信イベントMIME タイプを使用しますtext/event-stream。ブラウザ API (WebSocket API にかなり似ています) は EventSource API と呼ばれます。

  • Comet/サーバー プッシュ: これは、ロング ポーリングと HTTP ストリーミングの両方を含む包括的な用語です。Comet ライブラリは通常、クロス ブラウザーおよびクロス サーバーのサポートを最大限にするために複数の手法をサポートしています。

  • WebSocket : 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 :

サーバー送信イベント:

Webソケット:

スプディ:

HTTP 2.0 :

WebRTC :

クイック:

おすすめ記事