WebSocketはメッセージをどのように圧縮しますか？

Question

JSON.stringifyは明らかにスペース効率がよくありません。たとえば、[123456789,123456789]は、約5バイトが必要な場合に20バイト以上を占有します。websocketは、ストリームに送信する前にJSONを圧縮しますか？

Joakim Erdfelt · Accepted Answer

WebSocketは、本来、TEXTまたはBINARYデータのフレーミングのセットにすぎません。

それ自体は圧縮を行いません。

ただし、WebSocket仕様では拡張機能が許可されており、さまざまな圧縮拡張機能が一般に出回っています（これらの1つに対する正式な仕様が完成しました）。

本日（2018年8月）現在、受け入れられている圧縮仕様はpermessage-deflate。

実際に見られる拡張機能の一部：

permessage-deflate -WebSocketフレームの数に関係なく、deflateを使用してメッセージ全体を圧縮するための正式な仕様の名前。
x-webkit-deflate-frame-初期の提案された圧縮で、各生のWebSocketデータフレームを圧縮します。 ChromeおよびSafariで使用されているように見えます（ChromeおよびSafariで非推奨））
perframe-deflate -上記の圧縮の名前を変更したバージョン。さまざまなWebSocketサーバーの実装で使用されていること、およびさまざまなWebKitベースのクライアントに簡単に表示されていること。（最近のブラウザーでは完全に非推奨ですが、さまざまなWebSocketクライアントライブラリには引き続き表示されます）

注目すべきは、permessage-deflate拡張機能は、PMCE（メッセージごとの圧縮拡張機能）の最初の行であり、最終的には他の圧縮スキームが含まれます（説明されているものはpermessage-bzip2、permessage-lz4、permessage-snappy）

Myst · Answer

Websocketはストリームに送信する前にJSONを圧縮しますか？

短い答えは次のとおりです：時々、しかしそれに依存することはできません。

Joakim Erdfeltが適切に述べたように、Websocket接続はテキストメッセージとバイナリメッセージの両方をサポートします。

JSONはデータを転送するための1つの方法にすぎず、汎用性と使いやすさの利点があります（スペースに関しては無駄です）。

Websocket APIを使用してバイナリデータを簡単に転送でき、帯域幅のオーバーヘッドを排除して、他の懸念事項（エンディネス、ワード長、解析など）を犠牲にします。

多くのブラウザーは、Websocketプロトコルの拡張機能としてWebsocketメッセージ圧縮もサポートしています（ただし、サーバーは拡張機能をサポートしていない場合があります）。

拡張機能は、Sec-WebSocket-Extensions HTTPヘッダーを使用してネゴシエートされます。交渉は通常、クライアント/サーバーによって実装され、それらを制御するパブリックAPIは提供されません。

2015年までは、多くのアプローチと実装が実際に行われていましたが、 2015年12月以降 RFC 7692がメッセージ圧縮の唯一の真の候補であり、状況ははるかに明確です。

RFC 7692は、メッセージ全体を圧縮してからWebsocketの「パケット」にラップ（およびおそらくフラグメント化）するため、以前の圧縮方式よりも実装が簡単になります。

現在のドラフトはpermessage-foo圧縮ネゴシエーションスキームを提供しています（ここでfooは要求された/サポートされている圧縮です）。

私はpermessage-deflate拡張を自分で経験しただけです。

拡張ネゴシエーションはオプションです。つまり、サーバーが拡張をサポートしている場合でも、潜在的なネットワーククライアントは通常、圧縮せずに接続をネゴシエートできます。

さらに、RFC 7692は選択的な圧縮をサポートしています。つまり、一部のメッセージは圧縮されているが、他のメッセージは圧縮されていない場合があります...

...たとえば、[123456789,123456789]は、圧縮する価値がない可能性があることを示す長さであるため、そのまま送信される可能性があります。

これはコメントの情報の組み合わせであり、最終更新日は2017年8月8日です。

見逃した場合は、ここに追加して日付を更新してください。