How does WebSocket compress messages?

Question

JSON.stringify is obviously not very space efficient. For example, [123456789,123456789] occupy 20+ bytes when it could need just around 5. Does websocket compress its JSONs

Answer 1

Does websocket compress its JSONs before sending to stream?

The short answer is: sometimes, but you can't depend on it.

As stated aptly by Joakim Erdfelt, Websocket connections support both Text and Binary messages.

JSON is just one way to transport data, with the advantage of versatility and ease of use (while being wasteful as far as space is concerned).

You can easily transfer binary data using the Websocket API, eliminating bandwidth overhead at the expense of other concerns (such as endieness, word length, parsing, etc').

Many browsers also support Websocket message compression as an extension to the Websocket protocol (although the server might not support the extension).

Extensions are negotiated using the Sec-WebSocket-Extensions HTTP header. The negotiations are usually implemented by the client / server without offering a public API to control them.

Right up until 2015, there were a number of approaches and implementations in the wild, but since December 2015 RFC 7692 is the only real contender for message compression and things are much clearer.

RFC 7692 compresses the whole message before wrapping (and perhaps fragmenting) it in Websocket "packets", making it easier to implement than some previous compression schemes.

The current draft offers a permessage-foo compression negotiation scheme (where foo is the requested / supported compression).

I only experienced the permessage-deflate extension myself.

Do notice that extension negotiations are optional, meaning that potential network clients are usually allowed to negotiate connections without compression, even if your server supports the extension.

Moreover, RFC 7692 supports selective compression, meaning some messages might be compressed while others aren't compressed...

... for example, [123456789,123456789] might be sent as is, since it's length indicates it isn't likely to be worth the compression effort.

Support for permessage-deflate (RFC 7692), August 8th, 2017:

This is a combination of the information in the comments, last updated August 8th, 2017.

If I missed anything, add them here and update the date.

Known Browser Support

• Chrome since 32
• Mozilla Firefox since 37
• Safari - unsupported (10.1.2 seems to use x-webkit-deflate-frame)
• Microsoft Edge - unsupported as of version 40

Known Server Support

• Crossbar.io (Autobahn)
• wspy
• Tornado
• Faye on node.js and Ruby
• SwiftWebSocket (read only?)
• WS-RS (Rust)