node.js ws permessagedeflate zlib 解压和pako的区别？答案

【问题标题】：The difference between node.js ws permessagedeflate zlib decompression and that of pako?node.js ws permessagedeflate zlib 解压和pako的区别？
【发布时间】：2017-11-04 11:04:00
【问题描述】：

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

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

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

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

pako.inflate(data, { to: 'string' })

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

谁能给出一个合理的解释或至少一个假设为什么？

【问题讨论】：

发件人是否显式压缩？换句话说，是使用pako.deflate(...)（或类似的东西）吗？
不幸的是我不知道，但很有可能。

标签： node.js websocket zlib pako permessagedeflate

【解决方案1】：

ws 支持的是一个名为 “permessage-deflate”的特定 WebSocket 扩展。

此扩展在RFC 7692 中记录，因为它是协议的扩展，所以底层 WS 协议实现（服务器和客户端）需要支持（其中涉及客户端和服务器的握手过程尝试判断对方是否支持，发送方设置特定的帧标志，通知接收方该帧已压缩）。

一旦激活，它就相对透明，并且帧（解）压缩由协议驱动程序自动处理。

在您的情况下，听起来好像在 WebSocket 之上添加了一个显式压缩/解压缩阶段，其中发送方显式压缩数据（而不是 WS 帧本身）而接收方需要显式解压缩它，这基本上是什么你已经发现了：接收到的消息是一个（压缩的）缓冲区，需要显式解压。

所以并不是ws 遗漏了什么，只是（去）压缩发生在原始 WS 帧（如果 "permessage-deflate"扩展将处于活动状态，可能导致数据被压缩和解压缩两次：一次由用户代码，一次由协议代码。

【讨论】：