背景
HTTPプロトコルが設計されて以来、大量の水が流れ、Javascriptが背景の雪片の落下にのみ使用されていた時代が過ぎました。 すぐにサーバーとの追加のデータ交換が必要になりました。そのため、AJAXを考え出しました（最初にiframeタグとscriptタグを使用し、次にXMLHttpRequestを考え出しました）。 ただし、これらのメソッドはすべて、クライアントがデータ転送を開始する必要があることを意味します。 もちろん、誰もが無限にダウンロード可能なフレームでチャットすることを知っていますが、これらは単なる松葉杖であり、開発で使用されたツールの不完全さにより、サーバーに大きな負荷をかけました。 各ユーザーは、サーバー上のプロセスを自分で食べました。
ブラウザ開発者のセキュリティ対策が強制されているため、iframeとXMLHttpRequestでは、現在のドキュメントのドメイン以外のドメインとのデータ交換を許可していません。 履歴を使用してドキュメント間でデータストリームを形成するハックタイプXhrIframeProxyがあります。 しかし、これはすべて白い糸で縫われています。
かなり良いオプションは、ロングポーリングです。これは、ブラウザがシーケンシャルリクエストを送信し、各リクエストがデータパケットを受信するまでハングする方法です。 ただし、印象的な欠点は、トラフィックと接続数のオーバーヘッドが大きいことです。
これらの方法の主な欠点は、最終的な開発の複雑さと俊敏性です。これは、有用なロジックと低レベルの麺の混乱です。 したがって、複雑な知識がなければ、サーバーによって開始されたデータ転送を実装することはできません。
だった？
そして、2009年が到着した4月23日です。 「Web Sockets API」と呼ばれる文書の下書きが登場し、すべての病気の終わりの始まりを示しました。 Javascriptからアクセス可能なオブジェクトについて説明しました。このオブジェクトには次の機能があります。
-オリジンベースのクロスドメインポリシー（Orginベースのセキュリティポリシー）-つまり、任意のページから任意のサーバーに接続でき、彼はOrgin（ドキュメントアドレス）に基づいてこの幸福が必要かどうかを決定します。
-トラフィックのオーバーヘッドが少ない。
-1つの接続を使用して両方向にデータを転送する機能
-現時点では、ネイティブにサポートされているのはGoogle Chrome 4+安定版とSafari 5、Mozilla Firefox 3.7およびIE 9でのみです。
すべてのブラウザをサポートするための代替手段はありますか？
オプション：
1. Flashエミュレーター（http://github.com/gimite/web-socket-js）
短所：UGコード、誰もがフラッシュを持っているわけではなく、フラッシュブロックプラグインを持っているものもあります。
2. iframe（iframeの無限のロード）とロングポーリング（wait-re-request、....）を使用します。
短所：アプリケーションレベルで3つの異なるトランスポートを実装し、プロセス間通信を確立することは非常に重要なタスクです。
チップとデールは救助に急ぎます
状況について考えた後、次の要件を満たすフレームワークが必要であると判断しました。
-サーバーとクライアントの両方の異なるトランスポート（ネイティブWebソケット、フラッシュWebソケット、コメット、ロングポーリング）からのAPIの抽象化。
-非同期：サーバー上の1つのプロセスが複数のクライアント接続を同時にサポートする必要があります。
-Javascriptクライアントは、ブラウザ、Flashの存在、ユーザー接続のタイプ（直接、プロキシなど）に自動的に適応する必要があります。
それは夕方でした、何もすることはありませんでした。
何が起こったのかの例はhttp://loopback.su/websocket/です （あなたが私を責めない場合、彼女は家のテーブルの下に立っています）。
サーバーアプリケーションはこちらです。
IE 6までのすべてのブラウザーで動作します。サーバー実装-phpDaemonのモジュール。 すべて一緒にgithubでプルできます。
このアプローチの主な利点は、クライアントサーバーアプリケーションを記述するときに、ブラウザがどのようなクライアントであるかを考える必要がなく、誰もがネイティブのWebSocketを持っているかのように書くことです。
必要に応じて、サーバー部分を他のプログラミング言語に書き換えることもできます。