壓縮文件的目的就是為了把傳輸文件的體積減小，加快傳輸速度。在 http 傳輸中開啟 gZip的目的也是如此

傳輸壓縮文件給別人時候一般都帶著后綴名 .rar, .zip之類，對方在拿到文件后根據(jù)相應(yīng)的后綴名選擇不同的解壓方式然后去解壓文件。我們在 http 傳輸時候解壓文件的這個角色的扮演者就是我們使用的瀏覽器

• 服務(wù)端發(fā)送的數(shù)據(jù)可以配置一個 Content-Encoding 字段，這個字段用于說明數(shù)據(jù)的壓縮方法

• 客戶端在接受到返回的數(shù)據(jù)后去檢查對應(yīng)字段的信息，然后根據(jù)對應(yīng)的格式去做相應(yīng)的解碼。客戶端在請求時，可以用 Accept-Encoding 字段說明自己接受哪些壓縮方法。

在網(wǎng)上看到最多的也是諸如 nginx 開啟 gZip 配置之類的文章，但是現(xiàn)在前端流行 spa 應(yīng)用, 用 react, vue 之類的框架時候總伴隨這一套自己的腳手架,一般用 webpack 作為打包工具，其中可以配置插件 如compression-webpack-plugin 可以讓我們把生成文件進(jìn)行 gZip 等壓縮并生成對應(yīng)的壓縮文件，而我們應(yīng)用在構(gòu)架時候有可能也會在服務(wù)區(qū)和前端文件中放置一層 node 應(yīng)用來進(jìn)行接口鑒權(quán)和文件轉(zhuǎn)發(fā)。nodejs中我們熟悉的express 框架中也有一個compression 中間件，可以開啟gZip,

NGINX壓縮有壓縮等級1-10，如果這個壓縮等級越高，服務(wù)器要壓縮很久才返回數(shù)據(jù)，反而會損耗CPU和時間?，F(xiàn)在的應(yīng)用都會使用spa應(yīng)用，文件都是打包生成的，所以webpack中打包生成高壓縮等級的文件，作為靜態(tài)資源存放在服務(wù)器上，接收到請求后把壓縮文件返回回來，是一種更好的解決方式。

const CompressionWebpackPlugin = require('compression-webpack-plugin');
?
webpackConfig.plugins.push(
 new CompressionWebpackPlugin({
 asset: '[path].gz[query]',
 algorithm: 'gzip',
 test: new RegExp('\\.(js|css)/pre>),
 threshold: 10240,
 minRatio: 0.8
 })
) // 壓縮使用的是 zlib 庫，而 zlib 分級來說，默認(rèn)是 6 ，最高的級別就是9

服務(wù)端怎么找到這些文件

壓縮文件會產(chǎn)生index.css, index.js的壓縮文件，在服務(wù)端簡單處理可以判斷這兩個請求然后給予相對應(yīng)的壓縮文件。以 node 的 express 為例

...
app.get(['/index.js','/index.css'], function (req, res, next) {
 req.url = req.url + '.gz'
 res.set('Content-Encoding', 'gzip')
 res.setHeader("Content-Type", generateType(req.path)) // 這里要根據(jù)請求文件設(shè)置content-type
 next()
})

圖片之類文件則不會被 gzip 壓縮太多，因為它們已經(jīng)內(nèi)置了一些壓縮，一些文件（比如一些已經(jīng)被壓縮的像.zip文件那種）再去壓縮可能會讓生成的文件體積更大一些。當(dāng)然已經(jīng)很小的文件也沒有去壓縮的必要了。