问题标签 [permessagedeflate]

我有一个接收压缩数据的 node.js ws websocket。

文档中关于膨胀机制的内容非常浅薄，但通过阅读源文件，它显然是内置的，应该根据接收到的数据类型自动激活。

但是，当附加ws.on('message',function(data){})事件时，它会返回一个< Buffer >

因为我知道这些流之前已经用 Pako 进行了膨胀，所以我尝试安装它，它实际上使用以下代码工作：

据我了解，这两个模块都使用 zlib 解压缩，但 ws 模块不知何故错过了它。

有人可以给出合理的解释或至少假设为什么吗？

我正在查看 permessage-deflate rfc，但我不明白关于“共享 LZ77 滑动窗口”的部分（第 7.2.3.2 节。）

它说如果“约定参数”不包含“client_no_context_takeover”扩展参数，客户端可以通过引用LZ77滑动窗口中的历史将下一条消息的有效负载压缩成更少的字节。

服务器如何知道客户端是使用相同的滑动窗口还是使用新的滑动窗口？服务器将如何解压消息？如何使用 Zlib（或任何其他库）来压缩/解压缩这样的消息？

我的客户端和服务器正在通过 WebSocket 与 JSON 序列化数据进行通信，并且都支持每个消息放气，我想 JSON 数据已经被压缩。服务器是随时编写的，使用 gorrilla 的 WebSocket 包。我的目标是减少更多流量，所以想知道我是否将 JSON 序列化更改为 MessagePack 并继续使用每个消息的 deflate 标头是否有助于减少流量？

当服务器遇到流量增加时，会出现奇怪的内存泄漏，它将使用的内存从 600m 膨胀到 ±3gb，几分钟后又回到 600mb。这也会使 CPU 使用率飙升并使服务器无响应。

我发现这个线程https://github.com/socketio/socket.io/issues/3477说禁用 perMessageDeflate 解决了这个问题。

如何在 socket.io 中禁用 perMessageDeflate？

我已经在 python 中编写了自己的 websocket 实现，以自学它们的内部工作原理。我打算通过 websocket 发送大量重复的 JSON 对象，所以我正在尝试实现permessage-deflate. 压缩在client->server方向上起作用，但不是在 server -> client方向上

这是标头交换：

要求

回复

当我这样做时，我会按预期从客户端获取压缩数据并按预期膨胀。

当我发送未压缩的消息时，我会在客户端得到正常响应，即我发送“你好”并得到“你好”

当我尝试使用这个简单的 python 函数缩小我的消息时：

我收到一条关于字符不是 utf-8 的错误消息，当我对压缩消息进行 base64 编码时，我只得到了 base64 编码的字符串。我还尝试通过 websocket 将数据作为二进制发送，并在另一端得到一个 blob。我已经在互联网上搜索了一段时间，还没有听说过这种情况。我的猜测是我在错误的步骤压缩数据。下面是我用来发送数据的函数。到目前为止，我一直在将压缩消息输入到send()函数中，因为从我读过的内容来看，permessage 压缩发生在消息级别，并且所有其他数据保持未压缩。