のように...私の調査で
は、私が012にこの文を通り抜けました：それはメッセージの流れの代わりに、私はそれが正確に何を意味するのかについては全くわからないんだけど、バイト
の流れを可能にするに
のWebSocketはTCPとは異なります。あなたの解釈は何ですか？
通常のTCPソケットを使用してバッファからバイトを送信すると、send関数は送信されたバッファのバイト数を返します。非ブロックソケットまたは非ブロック送信の場合、送信されるバイト数はバッファのサイズより小さくなることがあります。ブロッキングソケットまたはブロッキング送信の場合、返される数値はバッファのサイズと一致しますが、呼び出しがブロックされる可能性があります。 WebSocketでは、sendメソッドに渡されるデータは、常に「メッセージ」として送信されるか、まったく送信されません。また、ブラウザのWebSocket実装は送信呼び出しをブロックしません。
しかし、受信側にはより重要な違いがあります。受信側がTCPソケット上でrecv（またはread）を行うと、返されたバイト数が送信側の単一の送信（または書き込み）に対応するという保証はありません。それは同じかもしれません、より少なく（またはゼロ）かもしれませんし、より多くの場合もあります（複数の送信/書き込みからのバイトが受信されます）。 WebSocketでは、メッセージの受信はイベントドリブン（通常はメッセージハンドラルーチンを登録します）であり、イベントのデータは常に相手側が送信したメッセージ全体です。
TCPソケットを使用してメッセージベースの通信を行うことができますが、フレーム/メッセージ境界データをメッセージに追加する追加のレイヤー/カプセル化が必要であるため、元のメッセージを断片から再構築できます。実際、WebSocketsは通常のTCPソケット上に構築され、各フレームのサイズを含むフレームヘッダーを使用し、メッセージの一部であるフレームを示します。 WebSocket APIは、データのTCPチャンクをメッセージに組み立てられたフレームに再組み立てしてから、メッセージごとにメッセージイベントハンドラを1回呼び出します。
WebSocketは基本的にはメッセージ転送型のアプリケーションプロトコルです（はトランスポート層としてTCPを使用しています）。
WebSocketプロトコルの背後にあるアイデアは、確立されたTCP接続をクライアントとサーバーの間で再利用することから成っています。 HTTPハンドシェークの後、クライアントとサーバーは、WebSocketエンベロープを交換することによってWebSocketプロトコルの使用を開始します。 HTTPハンドシェイクは、いくつかのサービスを提供するクライアントとサーバとの間の障壁（例えば、ファイアウォール）を克服するために使用される（通常、ポート80はどこからでも誰でもアクセス可能である）。クライアントとサーバーは、同じTCP接続（決して解放されない）を利用して、任意の瞬間に話すHTTPを切り替えることができます。
バックグラウンドWebSocketは、一貫した封筒/メッセージでTCPフレームを再構築します。サーバーは全二重チャネルを使用して、の更新を非同期でクライアントに向けてプッシュします。チャネルは開いており、クライアントは非同期のWebSocket受信メッセージを管理する任意の先物/コールバック/約束を呼び出すことができます。
簡単に言えば、WebSocketは、JSクライアント（以前のCometとのコラボレーション）を使って効果的なリアルタイムアプリケーションを構築することを可能にするTCP（信頼性の高いトランスポートレイヤー）サーバーからアップデートを取得するには、長いポーリング手法をで使用しました。
私はWikipediaのあなたの文章は少し誤解を招くと思います。私があなたのリンクから読んだところから、WebSocketはHTTP以外のトラフィックに使用されるHTTP TCP接続であるようです。 IEでは、あなたは、VPN接続のトラフィックなどのソケットを使用するために、そのポート80へのTCP接続でサーバと交渉します。だから、WebSocketはhttp以外のhttpソケットにすぎませんか？ Spitballing ... Wikipediaの抜粋のバイトの代わりに、 "メッセージ"が何を意味するのかはっきりしない。 – 0xhughes