gzip压缩简介
什么是gzip压缩？gzip压缩基于deflate中的算法，gzip将生成自己的数据格式。对于需要压缩的文件，gzip压缩首先使用LZ77算法进行压缩，然后对得到的结果进行霍夫曼编码，然后根据实际情况判断是使用动态霍夫曼编码还是静态霍夫曼编码，最后生成相应的gz压缩文件。
00-1010您可能已经注意到，在我们的HTTP请求头中，会有一个accept-encoding字段，它实际上是告诉服务器客户端可以接受的文件压缩格式，包括gzip、deflate和br等。
那么gzip和deflate有什么区别呢？
1.GZIP似乎是一个不透明的或原子的函数。事实上，HTTP定义了一种机制，在这种机制中，网络客户端和网络服务器同意使用压缩方案来发送内容，这是通过使用接受编码和内容编码头来实现的。有两种常用的HTTP压缩：DEFLATE和GZIP。
2.DEFLATE是一种无专利的压缩算法，可以实现无损数据压缩，并且有很多开源的实现算法。大多数人使用zlib作为这个标准的实现库。zlib库提供了使用DEFLATE/充气来压缩和解压缩数据。zlib库还提供了一种数据格式，即令人困惑的名称ZLIB，它用标头和校验和包装DEFLATE压缩数据。
总之，GZIP是另一个使用DEFLATE压缩数据的压缩库。事实上，GZIP的大多数实现实际上都使用zlib库的内部来进行DEFLATE/INFLATE压缩。GZIP生产自己的数据格式，令人困惑地命名为GZIP。它用报头和校验和包装DEFLATE压缩数据。但是，由于最初的法规不一致，大多数情况下已启用了deflate压缩。
00-1010接下来，输入本文的主题之一。gzip压缩的过程是什么？
其实gzip压缩一般是针对文本文件的压缩。至于后面将要介绍的原因，首先，LZ77算法基于文本文件第一次压缩文本内容，即文件中的字符串。然后用霍夫曼编码转换成010111.和其他二进制存储系统。那么具体的算法是什么呢？
gzip和deflate的区别
LZ77算法的核心思想是重用字符串。在扫描整个文本的过程中，判断前面的字符串中是否有相似的字符串或子字符串，并以这种方式压缩文本的长度。举个简单的栗子：
案文如下：
http://www.qq.com
http://www.paipai.com
让我们附上同样的内容。
http://www.qq.com
(http://www。)排排(。com)
替换为信息对后的结果是
http://www.qq.com
(18，11)排排(22，4)
在…之中
(18，11)，18(起点到下一个起点，包括换行)是同一内容块到当前位置的距离，11是同一内容的长度。
(22，4)，22是相同内容块与当前位置之间的距离，4是相同内容的长度。
因为信息对的大小小于被替换内容的大小，所以文件被压缩。
为了具体实现该算法，您应该首先澄清几个名词概念：
1.正向缓冲器
每次读取数据时，都会将一部分数据预加载到正向缓冲区中。准备进入滑动窗口
2.推拉窗
一旦数据通过缓冲区，它将移动到滑动窗口并成为字典的一部分。
3.短语词典
从S1这个角色来看.Sn，形成n个短语。例如，字符(A、B、D)可以与诸如{(a)、(A、B)、(A、B、D)、(B)、(B、D)、(d)}等短语组合。如果这些字符在滑动窗口中，它们可以被记录为当前短语词典，因为滑动窗口一直向前滑动，所以短语。
在遍历整个文本串的过程中，算法通过判断前向缓冲区滑动窗口中是否有最长的串来实现串的“复用”，如下图所示：
目前滑动窗口中存在的字符串除了单个字符外都有AB、BD和ABD，而前向缓冲区中有AB、ABC和BC，最长的子串是AB，因此ABC可以压缩成(0，2，C)，其中0表示滑动窗口中的偏移量，2表示读取两个字符，C表示不匹配的字符。接下来，让我们看一个完整的压缩案例，你会明白：(图片引自：https://www.jb51.net/article/.)
pgc-img-caption”>
那么解压过程呢？其实解压过程是非常快速的，如下：
可以看出，LZ77算法的耗时，主要在于压缩阶段中，判断前向缓冲区和滑动窗口中的最长字符串匹配，也就是说，选择滑动窗口大小，以及前向缓冲区大小，对你的LZ77算法的时间复杂度有着关键的影响，其次，合适的滑动窗口大小、缓冲区大小能帮助你对文件进行更好的压缩，提高压缩率。
而在整个解压的过程，只需要通过简单的字符读取，根据偏移量复用子字符串，就完成了解压过程，整个过程没有复杂的算法耗时，这也正符合了我们在网络请求中的适用场景，通过在服务端对文件的一次压缩，提供给所有的用户使用，在客户端对数据进行解压，而解压基本没有什么耗时，因此能大大提高我们的页面资源加载速度。
2、huffman编码
狂野的冬瓜对文件中的文本进行压缩后，接下来其实就是文本的存储了，ASCII编码中，一个字符对应一个字节，通过8位来表示，但是我们真的不能在优化了吗？huffman编码告诉我们，我们还能再压缩！huffman的原理，本质是通过判断字符在文本中的出现频次，规定每个字符的编码，而非固定8位编码，举个简单的栗子：
字符串：AAABCB
按照以往的存储方式 需要6个字节，48bits。
但是我们可以看到，A出现了3次，B出现了2次，C仅仅出现了1次，于是我们换一种存储方式，
用0来表示A，10来表示B，11来表示C
最后的压缩结果是000101110 ，最后我们只用了9个bits来存储了这个字符串！
这就是huffman的根本原理。
可以看到我们的关键在于，为字符生成相应的编码，所以这个过程需要我们构造一个时尚的百合树，什么是哈夫曼树呢？时尚的百合树是通过一系列值，将这些值作为叶子节点，注意是叶子节点，构造成一个树，这个树要求，（ 叶子节点的权重 叶子节点的深度 ） 所有叶子节点总数n 的值达到最小。具体的构造过程如下：（图片引自 http://www.360doc.com/content… ）
其中，节点值表示字符出现的频次，叶子节点的层级变相意味着 字符编码的长度，其实这也很好理解，我们希望出现频次越多的字符，编码越短越好，频次较少的字符，编码长度较长也无所谓。这也和哈夫曼树的定义完美契合。
可以看到字符串：
abbbbccccddde
a b c d e
1 4 4 3 1
经过我们的huffman编码后，分别表示如下：
a 为 110
b 为 00
c 为 01
d 为 10
e 为 111
聪明的你可能还留意到了，通过huffman编码后的二进制字符，是没有二义性的。
可以看到我们上述的案例，动态生成了huffman编码，所以最后传输数据的时候，还需要把huffman树的信息一起传递过去，当然，这里还存在 静态huffman和动态huffman的区别 ：
静态Huffman编码就是使用gzip自己预先定义好了一套编码进行压缩，解压缩的时候也使用这套编码，这样不需要传递用来生成树的信息。
动态Huffman编码就是使用统计好的各个符号的出现次数，建立Huffman树，产生各个符号的Huffman编码，用这产生的Huffman编码进行压缩，这样需要传递生成树的信息。
Gzip 在为一块进行Huffman编码之前，会同时建立静态Huffman树，和动态Huffman树，然后根据要输出的内容和生成的Huffman树，计算使用静态Huffman树编码，生成的块的大小，以及计算使用动态Huffman树编码，生成块的大小。然后进行比较，使用生成块较小的方法进行Huffman编码。
对于静态树来说，不需要传递用来生成树的那部分信息。动态树需要传递这个信息。而当文件比较小的时候，传递生成树的信息得不偿失，反而会使压缩文件变大。也就是说对于文件比较小的时候，就可能会出现使用静态Huffman编码比使用动态Huffman编码，
生成的块小。
如何开启gzip
竟然gzip这么棒，赶紧在我们的项目中用起来吧！
express和koa默认都没有开启gzip压缩，所以需要自行引入中间件的形式开启压缩，针对text文件进行文本压缩。
const Koa = require(“koa”);
const path = require(“path”)
var compress = require(‘koa-compress’)
const app = new Koa();
const static = require(‘koa-static’)
app.use(compress({
filter: function (content_type) {
return /text/g.test(content_type)
},
threshold: 1,
flush: require(‘zlib’).Z_SYNC_FLUSH
}))
app.use(async(ctx, next) => {
//ctx 代表响应 ctx.compress = trus 代表允许压缩
// ctx.compress = true
// ctx.body = “hello”
await next()
})
app.use(static(
path.join( __dirname, ‘public’),{
gzip:true
}
))
//可以配置一个或多个
// app.use(static(__dirname + ‘/static’)))
app.listen(3000);
需要注意 koa 的中间件使用 和express是不一样的。
其次，通过filter 函数来判断是否要进行gzip压缩。
除了nginx或server层做gzip压缩。
也可以在构建的时候压缩，生成相应的gz文件。
const CompressionWebpackPlugin = require(‘compression-webpack-plugin’);
webpackConfig.plugins.push(
new CompressionWebpackPlugin({
asset: ‘[path].gz[query]’,
algorithm: ‘gzip’,
test: new RegExp(‘\\.(js|css)#39;),
threshold: 10240,
minRatio: 0.8
})
)
关于gzip的Q & A
Q：gzip是否仅限制于文本文件，对于二进制文件呢？音频？图片等资源呢？
A：gzip压缩不仅适用于文本文件，其实也可以对图片等二进制文件进行压缩，但是不推荐这么做，由于gzip的压缩过程首先基于字符串进行LZ77处理，接下里再通过huffman编码，然而，大多数的二进制文件，已经有自己的编码和压缩方式了，对二进制文件进行在压缩，可能导致文件更大，同时，会增大客户端解压缩的压力，带来不必要的CPU损耗。
一些开发者使用HTTP压缩那些已经本地已经压缩过的文件，而这些已经压缩过的文件再次被GZip压缩时，是不能提高性能的，表现在如下两个方面。
首先，HTTP压缩需要成本。Web服务器获得需要的内容，然后压缩它，最后将它发送到客户端。如果内容不能被进一步压缩，你只是在浪费CPU做无意义的任务。
其次，采用HTTP压缩已经被过压缩的东西并不能使它更小。事实上，添加标头，压缩字典，并校验响应体实际上使它变得更大，如下图所示：
Q：gzip压缩过得文件，可以再进行一次gzip压缩吗？多次呢？
A：可以进行再压缩，但是gzip首次压缩过后的文件，本身已经是二进制文件，对文件进行再压缩只会带来没必要的性能损耗，同时可能导致文件增大。
Q：需要对所有文本内容都进行GZIP压缩吗？
A：答案是否定的，可以看到我们的压缩过程中，需要执行算法，假如传输的字符串仅仅几十个字符，那么执行算法是完全没有必要的，并且，对过短的字符进行压缩，可能反而导致传输数据量增大，例如可能要传输动态构造的huffman树信息等。
Q：在哪个阶段对文件进行gzip压缩比较合适？
A：在本地构建部署的时候，通过webpack生成最终的gz压缩文件部署上服务器，是最高效的，假如通过引入中间件，在请求到来时再对文本文件进行压缩，只会让用户的等待时间更长，所以笔者认为，在webpack打包构建的时候做这件事是最合理的。