web-dev-qa-db-ja.com

WebSocketを介したBOSHとロングポーリングを必要とする特定のユースケースは何ですか？

[〜＃〜] bosh [〜＃〜] は...

複数の同期HTTP要求/応答のペアを効率的に使用することにより、2つのエンティティ（クライアントとサーバーなど）間の長寿命の双方向TCP接続）のセマンティクスをエミュレートするトランスポートプロトコル。頻繁なポーリングまたはチャンクされた応答の使用。

これは WebSockets およびHTTPロングポーリングのように聞こえますが、1つではなく2つのオープンHTTP接続を使用し、HTTPプロトコルを拡張しない点が異なります。

2つのプロトコルの違いは何ですか？また、どのユースケースがBOSHよりもWebSocketを好むでしょうか？

httpcometwebsocket
40
a paid nerd

まず、WebSocketの準備について説明します：

Hixie-76 プロトコルのWebSocket実装が出荷され、Chrome、Safari、iOS（iPhoneおよびiPad）でデフォルトで有効になっています。 Hixie-76プロトコルも同梱されていますが、Firefox 4およびOpera 11ではデフォルトで無効になっています。 web-socket-js プロジェクトは、WebSocket（Hixie-76）を追加するFlash shim/polyfillですFlashを備えた任意のブラウザへのサポート。

言い換えると、WebSocketは、ほとんどすべてのブラウザで使用できます。

OperaとMozillaがデフォルトでプロトコルを無効にすることを選択した理由は、プロトコルのHixieバージョンを使用して攻撃/汚染される可能性があるいくつかの壊れたHTTPプロキシ/中間体が存在する可能性があるという理論的な懸念によるものです。同じ懸念がFlashにも当てはまりますが、MozillaとOperaは、出荷するコードに対してより高い責任を負っていると感じました。プロトコルのHyBiバージョン（プロトコルはIETF HyBiワーキンググループに移動されました）は、セキュリティの問題に対処します。

Mozilla、Opera、Google、およびMicrosoftはすべてHyBiプロトコルの実装に取り​​組んでいます（ただし、Microsoftは現在のところ、それらを 個別のダウンロード として維持しています）。 HyBi-07をサポートする web-socket-jsのブランチ があります。

更新：2013年2月現在、最新の HyBi/IETF RFC 6455仕様 がChrome 14でサポートされていますFirefox 7、IE10、Opera 12.1、Safari 6.0、および web-socket-js Flash shim/polyfill。モバイルデバイスでは、IETF6455はiOS 6.0のSafari、Opera Mobile 12.1、Chrome 14 for Android、Firefox 7 for Android、Blackberry 7でサポートされています。元のデフォルトのAndroidブラウザーにはWebSocketサポート。

WebSocketサーバーは簡単に実装できます。多くのスタンドアロンおよびプラグイン実装があり、そのほとんどがHixie-76およびHyBiプロトコルバージョンの両方をサポートしています。

BOSHとWebSockets：

  • latency：BOSHドラフトドキュメントは非常に低いレイテンシを主張していますが、BOSHがWebSocketと競合することは困難です。 HTTP/1.1がすべての中間手段およびターゲットサーバーによって完全にサポートされるという理想的な条件がない限り、BOSHクライアントと接続マネージャーは、すべてのパケットとすべてのリクエストタイムアウトの後で接続を再確立する必要があります。これにより、レイテンシとレイテンシジッタが大幅に増加します。多くの場合、リアルタイムアプリケーションでは平均ジッターよりも低ジッターの方が重要です。 WebSocket接続は、レイテンシとジッターがraw TCP接続と非常に似ています。また、理想的な条件下でも、BOSH通信のクライアントからサーバーへのレイテンシ（したがって往復）は常にWebSocketsよりも長くなります。BOSHは、依然としてHTTP要求応答セマンティクスに従う必要があります。 HTTPストリーミングでは、（「単一」の応答を複数の部分に分割することにより）要求ごとに複数の応答が可能ですが、その逆はできません（各クライアントメッセージは新しい要求です）。
  • 小さなパケットのオーバーヘッド：WebSocketでは、小さなメッセージに対して2バイトのフレーミングオーバーヘッドがあります。 BOSHでは、すべてのメッセージにHTTPリクエストヘッダーとレスポンスヘッダーがあります（各ラウンドトリップで180バイト以上）。さらに、各メッセージはXMLでラップされています（オプションと思われますが、仕様ではその方法が定義されていません）。いくつかのセッション関連の属性が含まれています。
  • complexity：BOSHはブラウザーの既存のメカニズムを使用しますが、BOSHセマンティクスを実装するには、適度に複雑なJavaScriptライブラリが必要です。これをJavascriptで管理すると、ネイティブ/ブラウザー（またはFlash）の実装と比較して、レイテンシとジッターも増加します。
  • トラクション：BOSHは、XMPPをより効率的にする方法として人生を始めました。それはXMPPコミュニティから育ちました、そして私が言うことができることから、そのコミュニティの外で非常にほとんど引き付けられませんでした。 BOSHとXMPPのドラフト文書は分けられていますが、XMPPなしでBOSHを実際に使用することはほとんどないようです。

更新：

Ian Fetteが BOSHに似たChannel APIを超えるWebSocketの利点 について説明しているビデオを見つけたところ（44:00）

103
kanaka