HTTP請求之gzip壓縮知多少

gzip壓縮簡介

什麼是gzip壓縮，gzip壓縮是基於deflate中的算法進行壓縮的，gzip會產生本身的數據格式，gzip壓縮對於所須要壓縮的文件，首先使用LZ77算法進行壓縮，再對獲得的結果進行huffman編碼，根據實際狀況判斷是要用動態huffman編碼仍是靜態huffman編碼，最後生成相應的gz壓縮文件。

gzip和deflate的區別

你們可能注意到了，在咱們的HTTP請求頭中，會存在accept-encoding字段，其實就是在告訴服務器，客戶端所能接受的文件的壓縮格式，其中包括gzip、deflate和br等。
那麼常見的gzip和deflate有什麼區別呢？
一、GZIP，好像是一個不透明的或原子的功能。事實上，HTTP定義了一種機制，一個Web客戶機和Web服務器贊成一壓縮方案能夠用來發送內容，這由使用Accept-Encoding和Content-Encoding標頭完成。有兩種經常使用的HTTP壓縮：DEFLATE和GZIP。
二、DEFLATE是一個無專利的壓縮算法，它能夠實現無損數據壓縮，有衆多開源的實現算法。該標準的實施庫大多數人用的是zlib的。zlib庫提供用於壓縮和解壓縮使用DEFLATE/INFLATE的數據。zlib庫還提供了一種數據格式，混淆的命名ZLIB，它包裝DEFLATE壓縮數據，具備報頭和校驗和。
總而言之，GZIP是使用DEFLATE進行壓縮數據的另外一個壓縮庫。事實上，GZIP的大多數實現實際使用zlib庫的內部進行DEFLATE/ INFLATE壓縮操做。GZIP產生其本身的數據格式，混淆的命名GZIP，它包裝DEFLATE壓縮數據，具備報頭和校驗和。而因爲最初的規定不統一問題，大多數狀況下已經啓用deflate壓縮。

gzip壓縮原理

接下來進入本文的正題之一，gzip壓縮的流程是怎麼樣的？
其實gzip壓縮通常都是針對文本文件進行壓縮，至於緣由後面會介紹到，首先LZ77算法基於文本文件對文本內容，即文件中的字符串進行首次壓縮，接下來，利用哈夫曼編碼，轉換爲010111..等2進制進行存儲。那麼具體的算法是怎樣的呢？

一、LZ77算法

LZ77算法的核心思想，是對字符串的重複利用，在掃描整個文本的過程當中，判斷以前的字符串中，有沒有出現過相似的字符串或子字符串，經過這樣的方式來壓縮你的文本長度，舉個簡單的栗子：
文本內容以下：
http://www.qq.com
http://www.paipai.com
咱們把相同的內容括起來
http://www.qq.com
(http://www.)paipai(.com)
用信息對替換以後的結果是
http://www.qq.com
(18,11)paipai(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/...）

那麼解壓過程呢？其實解壓過程是很是快速的，以下：

能夠看出，LZ77算法的耗時，主要在於壓縮階段中，判斷前向緩衝區和滑動窗口中的最長字符串匹配，也就是說，選擇滑動窗口大小，以及前向緩衝區大小，對你的LZ77算法的時間複雜度有着關鍵的影響，其次，合適的滑動窗口大小、緩衝區大小能幫助你對文件進行更好的壓縮，提升壓縮率。
而在整個解壓的過程，只須要經過簡單的字符讀取，根據偏移量複用子字符串，就完成了解壓過程，整個過程沒有複雜的算法耗時，這也正符合了咱們在網絡請求中的適用場景，經過在服務端對文件的一次壓縮，提供給全部的用戶使用，在客戶端對數據進行解壓，而解壓基本沒有什麼耗時，所以能大大提升咱們的頁面資源加載速度。

二、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)$'),
      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打包構建的時候作這件事是最合理的。

finally

謝謝你們的觀看！本期節目到此結束~下期再會~