javascript - WebSocket 是如何压缩消息的？

Question

JSON.stringify 显然不是很节省空间。例如，[123456789,123456789] 占用 20+ 个字节，而它可能只需要大约 5 个字节。websocket 在发送到流之前会压缩它的 JSON 吗？

score 47 · Accepted Answer

WebSocket 的核心只是一组 TEXT 或 BINARY 数据的框架。

它自己不执行压缩。

然而，WebSocket 规范允许扩展，并且已经有各种各样的压缩扩展（其中一个的正式规范已经最终确定）。

截至今天（2018 年 8 月），公认的压缩规范为permessage-deflate.

在野外看到的一些扩展：

permessage-deflate- 使用 deflate 压缩整个消息的正式规范的名称，无论 websocket 帧的数量如何。
x-webkit-deflate-frame- 压缩每个原始 websocket 数据帧的早期提议的压缩。已被 Chrome 和 Safari 使用。（现已在 Chrome 和 Safari 中弃用）
perframe-deflate- 上述压缩的重命名版本。被各种 websocket 服务器实现所使用，也曾短暂地出现在各种基于 WebKit 的客户端中。（在现代浏览器中完全弃用，但仍然出现在各种 WebSocket 客户端库中）

值得注意的是，该permessage-deflate扩展是 PMCE（每消息压缩扩展）系列中的第一个，最终将包括其他压缩方案（正在讨论的是permessage-bzip2、permessage-lz4和permessage-snappy）

score 22 · Accepted Answer

websocket 在发送到流之前会压缩它的 JSON 吗？

简短的回答是：有时，但你不能依赖它。

正如 Joakim Erdfelt 所说，Websocket 连接同时支持文本和二进制消息。

JSON 只是传输数据的一种方式，具有多功能性和易用性的优势（但就空间而言是一种浪费）。

您可以使用 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 日。

如果我错过了什么，请在此处添加并更新日期。

score 2 · Accepted Answer

您可以使用Unishox压缩技术来压缩通过 Websockets 发送的文本。然而，这并没有与规范集成，实现者负责压缩一侧并解压缩另一侧。

Unishox 通过基于流行符号的已知频率（熵编码）为给定字符集中的每个字母分配固定的无前缀代码来实现压缩。它还分别对重复的字母集进行编码（字典编码）。对于 Unicode 字符，使用增量编码。本文提供了更多信息。

到目前为止，它已在C和Javascript中实现。

免责声明：我是 Unishox 的开发者。

score -5 · Accepted Answer

Websockets 发送原始字节。
他们不知道也不关心这些字节代表什么。

如果你想压缩数据，你需要自己压缩它，然后再把它发送到网络上。

请注意，Chrome 支持使用 gzip 进行 websocket 连接。（假设您的服务器也这样做）

4 回答 4