JSON.stringify显然不是很节省空间。例如，[123456789,123456789]占用20多个字节，只需要大约5个。在发送到流之前，websocket会压缩其JSON吗？
答案 0 :(得分：32)
WebSocket的核心是TEXT或BINARY数据的一组框架。
它本身不执行压缩。
但是，WebSocket规范允许Extensions，并且已经有了各种各样的压缩扩展（其中一个的形式化规范已经完成）。
截至今天（2018年8月），接受的压缩规范为permessage-deflate。
在野外看到的一些扩展：
permessage-deflate - 使用deflate压缩整个邮件的形式化规范的名称，无论websocket框架的数量如何。x-webkit-deflate-frame - 早期提出的压缩，压缩每个原始websocket数据框。由Chrome和Safari使用。 （现已在Chrome和Safari中弃用）perframe-deflate - 上述压缩的重命名版本。由各种websocket服务器实现使用，以及briefly showed up in various WebKit based clients。 （在现代浏览器中完全弃用，但仍然出现在各种WebSocket客户端库中）值得注意的是，permessage-deflate扩展是PMCE（按消息压缩扩展）行中的第一个，最终将包含其他压缩方案（ones being discussed为permessage-bzip2，{{ 1}}和permessage-lz4）
答案 1 :(得分：13)
websocket会在发送到流之前压缩其JSON吗？
简短的回答是：有时，但你不能依赖它。
正如Joakim Erdfelt所说，Websocket连接支持Text和Binary消息。
JSON只是传输数据的一种方式，具有多功能性和易用性的优势（就空间而言是浪费）。
您可以使用Websocket API轻松传输二进制数据，从而消除带宽开销，但会牺牲其他问题（例如，端环，字长，解析等）。
许多浏览器也支持Websocket消息压缩作为Websocket协议的扩展（尽管服务器可能不支持扩展）。
使用Sec-WebSocket-Extensions HTTP标头协商扩展。协商通常由客户端/服务器实现，而不提供用于控制它们的公共API。
直到2015年，有许多方法和实现在野外，但since December 2015 RFC 7692是消息压缩的唯一真正竞争者，事情更加清晰。
RFC 7692在Websocket＆＃34;数据包＆＃34;中包装（并可能将其分段）之前压缩整个消息，使其比以前的压缩方案更容易实现。
当前草案提供了permessage-foo压缩协商方案（其中foo是请求/支持的压缩）。
我自己只体验过permessage-deflate扩展程序。
请注意，扩展协商是可选，这意味着即使您的服务器支持扩展，通常也允许潜在的网络客户端在没有压缩的情况下协商连接。
此外，RFC 7692支持选择性压缩，这意味着某些消息可能会被压缩，而其他消息则不会被压缩...
...例如，[123456789,123456789]可能会按原样发送，因为它的长度表示它不值得进行压缩工作。
permessage-deflate（RFC 7692）的支持：这是评论中的信息组合，最后更新时间为2017年8月8日。
如果我遗漏了任何内容，请在此处添加并更新日期。
x-webkit-deflate-frame）答案 2 :(得分：1)
您可以使用 Unishox 压缩技术来压缩通过 Websocket 发送的文本。然而，这并未与规范集成，实现者负责一方面压缩，另一方面解压缩。
Unishox 通过根据流行符号的已知频率（熵编码）为给定字符集中的每个字母分配固定的无前缀代码来实现压缩。它还单独编码重复字母集（字典编码）。对于 Unicode 字符，使用增量编码。更多信息可用in this article。
到目前为止，它已在 C 和 Javascript 中实现。
免责声明：我是 Unisox 的开发者。
答案 3 :(得分：-5)
Websockets发送原始字节 他们不知道或不关心那些字节代表什么。
如果你想压缩数据，你需要自己压缩数据，然后再将其发送到网上。
请注意，Chrome支持gzip进行websocket连接。 （假设你的服务器也这样做）