[解決済み] TCPソケットとWebソケットの違い、もう一回 [重複].

質問

TCPソケットとWebソケットの違いをできるだけ理解しようとして、これらの質問の中にすでに多くの有用な情報を見つけました。

• ウェブソケットとピュアTCPの基本的な違い
• Web ブラウザ（クライアント側）から TCP ソケット接続を確立するには？

などなど・・・。

私の調査では、この文章をスルーして ウィキペディア :

WebsocketはTCPとは異なり、バイトのストリームではなく、メッセージのストリームを可能にします。

具体的にどういうことなのか、まったくわからないのですが。皆さんはどのように解釈していますか？

どのように解決するのですか？

通常のTCPソケットでバッファからバイトを送信すると、send関数は送信されたバッファのバイト数を返します。ノンブロッキングソケットやノンブロッキング送信の場合、送信されたバイト数はバッファのサイズより小さくなる可能性があります。ブロッキングソケットやブロッキング送信の場合、返されるバイト数はバッファのサイズと一致しますが、呼び出しはブロックされる可能性があります。WebSocketでは、sendメソッドに渡されるデータは常に全体の"message"として送信されるか、全く送信されないかのどちらかです。また、ブラウザの WebSocket 実装では、send 呼び出しがブロックされることはありません。

しかし、受信側にはもっと重要な違いがあります。受信側が recv (または read ) の場合、送信側の1回の送信 (または書き込み) に対応するバイト数が返される保証はありません。同じかもしれないし、少ない(あるいはゼロ)かもしれないし、多いかもしれない(この場合、複数の送信/書き込みのバイトが受信される)。WebSocket では、メッセージの受信者はイベント駆動型であり（一般にメッセージハンドラールーチンを登録します）、イベントのデータは常に相手側が送信したメッセージ全体となります。

TCPソケットを使用してメッセージベースの通信を行うことができますが、元のメッセージを断片から再組み立てできるように、メッセージにフレーミング/メッセージ境界データを追加する余分なレイヤー/カプセル化が必要であることに留意してください。実際、WebSocket は通常の TCP ソケットをベースに構築されており、各フレームのサイズを含むフレームヘッダを使用して、どのフレームがメッセージの一部であるかを示します。WebSocket API は、TCP データチャンクをフレームに再アセンブルし、メッセージごとに 1 回メッセージイベントハンドラーを呼び出す前に、メッセージにアセンブルされます。