前言

这篇文章我们来聊一聊Node的原生模块zlib，它的主要作用是压缩和解压缩数据，我们都知道数据在压缩后可以减小体积，在网络传输时提高传输速度和节约带宽！

API用法

zlib这个模块提供了很多的API，如下：

图1

如图1中，前9个都是解压缩的构造函数，并且它们都继承了transform流，所以当他们实例化后都可以使用流实现逻辑处理！

接下来9个以create开头的方法就是将之前9个构造函数实例化，如下：

图2

图2中的两种写法等价！

最后18个分别给出了同步（sync结尾）和异步的方法，用法如下：

图3

第一个参数是输入的内容，第二个参数是选项，如果是异步操作，它的内部会使用流的方式处理，处理完成将调用第三个参数callback返回结果，如果是同步的（Sync结尾），方法将直接返回结果！

unzip方法有点特殊，gzip和defalte压缩的数据它都可以解压，效果如下：

图5

有几个比较重要的参数，需要了解一下，如下：

{
	chunkSize: 16*1024, //内部输出板缓存区
 windowBits: 15, //默认值15，值在8~15之间，越大内存使用率越高，压缩效果越好（仅压缩有效）
 memLevel: 8, //默认值8，值在1~9之间，指定为内部压缩状态分配多少内存（仅压缩有效）
 level: -1, //默认值-1，值在0~9，主要控制响应速度，越高压缩越好时间会越长，越低反之，-1是个特殊值，主要会取压缩速度和效果的平衡值，大约是6（仅压缩有效）
	strategy, //（仅压缩有效）
 //strategy 主要用于优化压缩算法，只影响压缩比，即使设置的不正确也不影响正确的压缩，值如下：
 //zlib.Z_DEFAULT_STRATEGY 用于普通数据
 //zlib.Z_FILTERED 适用于过滤后的数据，数据较小且随机分布，值介于zlib.Z_DEFAULT_STRATEGY和zlib.Z_HUFFMAN_ONLY之间
 //zlib.Z_FIXED 阻止动态Huffman coding的使用, 一些特殊程序可能会用到
 //zlib.Z_HUFFMAN_ONLY 只使用Huffman encoding
 //zlib.Z_RLE 将匹配距离限制设置为1, 和zlib.Z_HUFFMAN_ONLY几乎一样快，能更好的压缩PNG图片
 dictionary, //类型只能是Buffer、TypedArray、DataView、ArrayBuffer,默认为空，（仅压缩有效）
	info: true //如果true,返回一个buffer对象和engine，默认false，只返回buffer
}

上面提到了一些值和常量，可以在zlib的constants对象中获取到，如下：

图4

也可以在zlib上面直接获取。

压缩算法区别

首先deflate是一种压缩算法，gizp是一种数据格式，gzip用的压缩算法就是deflate，只不过加了gzip的头尾。

对于请求头包含Accept-Encoding:deflate的，服务器响应时有可能会返回deflate压缩的原始数据块（deflateRaw处理的数据不带zlib头），也有可能会返回zlib数据格式，这可能给浏览器带来解压上的麻烦，所以标识叫defalte，但是数据格式并不是deflate！

目前所有浏览器都支持gizp压缩方式，但支持gzip的不一定会支持defalte。

gzip格式 = gzip头 + deflate编码的实际内容 + gzip尾
zlib格式 = zlib头 + deflate编码的实际内容 + zlib尾

基于上面的原因，目前有声音想全面禁止defalte！

另外brotli是google推出的一种无损压缩算法，相比gzip，性能更好，压缩率更高！除了IE和Opera Mini之外，几乎所有的主流浏览器都已支持 Brotli 算法。

用法事例

我们先起一个小服务，分别尝试一下这几个算法，如下：

图5

服务比较简单，获取响应头accept-encoding就能得知浏览器支持的算法，看一下浏览器发出的请求头，如下：

图6

很好，三种格式都支持，我们每一个都试一下看看压缩效果如何！

图7

如图7所示，第一个是deflate压缩，第二个是gzip压缩，第三个是brotli压缩，对比发现brotli更好一些！

此处只是测试了html，没有测试静态资源，而且资源本身就比较小，对比不是那么强烈，如果小伙伴有兴趣可以自己测试对比一下效果！

总结

这篇文章主要介绍了一下Node原生模块zlib的一些用法，它底层的压缩算法是c编写的，有兴趣的同学可以继续深究！

喜欢我的文章就关注我吧，有问题可以发表评论，我们一起学习，共同成长！