Nginx 請求壓縮的實(shí)現(xiàn)(動態(tài)壓縮,靜態(tài)壓縮)

更新時(shí)間：2023年03月03日 09:46:36 作者：千城丶Y

本文主要介紹了Nginx 請求壓縮的實(shí)現(xiàn)(動態(tài)壓縮,靜態(tài)壓縮)，文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧

一、介紹

請求壓縮，是將服務(wù)器的結(jié)果通過 Nginx 將內(nèi)容進(jìn)行壓縮后，在發(fā)送給客戶端，降低網(wǎng)絡(luò)傳輸壓力，提升傳輸效率。

常見的兩種請求方式是： gzip 、brotli（Google），相當(dāng)于 brotli 的效率會高，后續(xù)內(nèi)容詳解。

請求壓縮的話分為：動態(tài)壓縮，靜態(tài)壓縮，動態(tài)壓縮會導(dǎo)致 Nginx內(nèi)部的 sendfile 失效。對于一些不變的內(nèi)容可以使用靜態(tài)壓縮，提升請求效率。

用于請求結(jié)果的壓縮，需要客戶端和服務(wù)器雙方支持壓縮協(xié)議，在服務(wù)器進(jìn)行結(jié)果的壓縮，客戶端進(jìn)行數(shù)據(jù)解壓縮，在壓縮會占用服務(wù)器端一些性能效率，這個(gè)損耗根據(jù)壓縮的等級來定，等級越高，耗損越大?？梢詼p少網(wǎng)絡(luò)傳輸壓力。

壓縮只針對于代理方式請求才生效。

二、請求壓縮的流程

執(zhí)行的流程是：客戶端向服務(wù)器端發(fā)送請求，nginx 接收請求之后，會向上游服務(wù)器服務(wù)器發(fā)送請求，Nginx和上游服務(wù)器之間會創(chuàng)建網(wǎng)絡(luò)通道，之間會進(jìn)行數(shù)據(jù)的傳輸，在這里如果是開啟了壓縮操作，那么Nginx會將結(jié)果數(shù)據(jù)進(jìn)行壓后，在將數(shù)據(jù)返回給客戶端，在瀏覽器接收到nginx的請求，會先處理請求頭，發(fā)現(xiàn)有壓縮協(xié)議，那么就會判斷當(dāng)前瀏覽器是否支持該協(xié)議，如果支持則會將數(shù)進(jìn)行解壓的操作并數(shù)據(jù)展示給用戶。

開啟壓縮之后用戶是無感的，可以降低傳輸壓力，但是圖片和視頻就不建議壓縮了，因?yàn)楹蟮拇笮∽兓淮?，gzip是網(wǎng)絡(luò)傳輸?shù)膲嚎s的，需要客戶端支持，服務(wù)器端也需要支持，將傳輸?shù)臄?shù)據(jù)進(jìn)行壓縮，將傳輸數(shù)據(jù)變小，我們可以設(shè)置下，當(dāng)然壓縮必越高，解壓縮和壓縮的時(shí)間更長，服務(wù)器端壓力會大些。

三、Gzip壓縮

3.1 gzip介紹

Gzip是GNUzip的縮寫，最早用于UNIX系統(tǒng)的文件壓縮。HTTP協(xié)議上的Gzip編碼是一種用來改進(jìn)Web應(yīng)用程序性能的技術(shù)，Web服務(wù)器和客戶端（瀏覽器）必須共同支持Gzip。目前主流瀏覽器：Chrome、Firefox等都支持該協(xié)議，常見的服務(wù)器：Apache、Nginx、IIS同樣支持Gzip。

Gzip的壓縮比率在3-10倍左右（純文本），可以大大節(jié)省服務(wù)器的網(wǎng)絡(luò)帶寬。在實(shí)際應(yīng)用中，并不是對所有文件進(jìn)行壓縮，通常只壓縮靜態(tài)文件（js\css\html）。JPEG這類文件用Gzip壓縮的不夠好，而且壓縮也是耗費(fèi)CPU資源的。

那么Gzip是如何進(jìn)行壓縮的呢？簡單來說，Gzip壓縮是在一個(gè)文本文件中找出類似的字符串，并臨時(shí)替換他們，使整個(gè)文件變小。這種形式的壓縮對Web來說非常合適，因?yàn)镠TML和CSS文件通常包含大量的重復(fù)字符串，例如空格、標(biāo)簽等。

3.2 gzip的使用

gzip模塊是Nginx中內(nèi)置的，所以不需要添加其他的默認(rèn)，只要配置安裝好Nginx既可。

使用作用域： http , server , location

Nginx 如下配置

gzip on ;

是否開啟壓縮。
默認(rèn)值：gzip off默認(rèn)關(guān)閉

gzip_buffers 32 4k | 16 8k

壓縮緩沖區(qū)大小。
默認(rèn)值： gzip_buffers 32 4k | 16 8k

gzip_comp_level 1 ;

壓縮等級 1-9 ，數(shù)字越大壓縮比越高。
越小壓縮速度和解壓縮速度越快，壓縮占比越小
默認(rèn)值：gzip_comp_leve 1

gzip_http_version 1.1

使用gzip 的最小的http版本。

gzip_min_length

設(shè)置將被 gzip 壓縮的響應(yīng)的最小長度。長度僅由 "Content-Length" 響應(yīng)報(bào)頭字段確定。

gzip_proxied 多選

對于上游服務(wù)器返回不同的head來決定是不是要進(jìn)行壓縮，兩種常見的一種off一種any
一般啟用cache的話都是已經(jīng)進(jìn)行過壓縮的所有可以規(guī)避一些細(xì)節(jié)
off 為不做限制。
作為反向代理時(shí)，針對于上游服務(wù)器返回的頭信息進(jìn)行壓縮。
expired - 啟用壓縮，如果header頭中包含 "Expires" 頭信息
no-cache - 啟用壓縮，如果header頭中包含 "Cache-Control:no-cache" 頭信息
no-store - 啟用壓縮，如果header頭中包含 "Cache-Control:no-store" 頭信息
private - 啟用壓縮，如果header頭中包含 "Cache-Control:private" 頭信息
no_last_modified - 啟用壓縮,如果header頭中不包含 "Last-Modified" 頭信息
no_etag - 啟用壓縮 ,如果header頭中不包含 "ETag" 頭信息
auth - 啟用壓縮 , 如果header頭中包含 "Authorization" 頭信息
any - 無條件啟用壓縮。

gzip_vary on ;

增加一個(gè)header ，適配老的瀏覽器 Vary : Accept-Encoding

gzip_types :

哪些 mime類型的文件進(jìn)行壓縮。

gzip_disable ：

禁止哪些瀏覽器使用gzip。
建議不要配置
默認(rèn)值： gzip_disable 'msie6MSIE [4-6]\.MSIE 6.0'

location / {
  
  gzip off ;  # 開啟gzip壓縮
  gzip_buffers 32 4k ; # 設(shè)置緩沖區(qū)大小
  gzip_comp_level 5; # 設(shè)置壓縮等級 1-9 
  gzip_disable 'msie6MSIE [4-6]\.MSIE 6.0';  # 禁止哪些瀏覽器不使用壓縮
  gzip_http_version 1.1; # 設(shè)置壓縮所需要的最低的http版本。 
  gzip_min_length 20 ; # 設(shè)置響應(yīng)的數(shù)據(jù)最小限制，在這個(gè)限制之后再回進(jìn)行壓縮
  gzip_vary on ; # 增加一個(gè)header ，適用于老的瀏覽器 Vary:Accept-Encoding 
  gzip_proxied any; # 無條件啟動壓縮
  # 哪些mime類型的文件進(jìn)行壓縮 
  #gzip_types text/plain application/x-javascript text/css application/xml; 
  gzip_types
    text/xml application/xml application/atom+xml application/rss+xml application/xhtml+xml image/svg+xml
    text/javascript application/javascript application/x-javascript
    text/x-json application/json application/x-web-app-manifest+json
    text/css text/plain text/x-component
    font/opentype application/x-font-ttf application/vnd.ms-fontobject
    image/x-icon;
}

3.3 gzip的請求

當(dāng)啟動了gzip，我們的請求到nginx服務(wù)器上，nginx就已經(jīng)給我們生產(chǎn)了response heard 但是數(shù)據(jù)還沒有生成，他也不知道具體數(shù)據(jù)有多大，因?yàn)閚ginx是異步響應(yīng)式請求，他一步一步來的，他先把header準(zhǔn)備好然后請求內(nèi)容去壓縮，最后將兩塊內(nèi)容合并去壓縮，最后發(fā)過來，也就是因?yàn)楫惒綄?dǎo)致他不知道具體大小。

他是先將請求頭返回然后數(shù)據(jù)在慢慢讀。

----------------------------------響應(yīng)體-------------------------------------------------
Connection: keep-alive
Content-Encoding: gzip # 結(jié)果啟動了gzip壓縮 
Content-Type: application/json # 響應(yīng)結(jié)果 
Date: Mon, 13 Feb 2023 09:13:19 GMT
Keep-Alive: timeout=65
Server: nginx/1.20.2
Transfer-Encoding: chunked # 傳輸?shù)母袷竭@個(gè)對應(yīng)的就是length，這個(gè)是他會發(fā)送一個(gè)一個(gè)的包，當(dāng)最后一個(gè)包是0表示傳輸結(jié)束
Vary: Accept-Encoding
 
 
 
------------------------------------請求頭-----------------------------------------------
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Cache-Control: max-age=0
Connection: keep-alive
Host: 192.168.101.128
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36

注意：以上是動態(tài)壓縮就是所有的請求都會經(jīng)歷一次壓縮，這個(gè)有一個(gè)致命的缺點(diǎn)就是不支持sendfile，sendfile是數(shù)據(jù)零拷貝，不會將數(shù)據(jù)加載到nginx，而是通過網(wǎng)絡(luò)接口傳遞數(shù)據(jù)，但是一旦開啟了 gzip動態(tài)壓縮會導(dǎo)致sendfile失效，可以使用靜態(tài)壓縮。

在多層 Nginx時(shí)，建議和服務(wù)器創(chuàng)建連接的Nginx進(jìn)行開啟Gzip 就可以了，這樣就會支持gzip，在任意一臺開啟都是會開啟的gzip的。

3.4 靜態(tài)壓縮

為什么要使用靜態(tài)壓縮呢？

首先動態(tài)壓縮無法使用 sendfile 而靜態(tài)壓縮則完美的解決了這個(gè)問題。

靜態(tài)壓縮是一個(gè)互補(bǔ)或者說是一個(gè)擴(kuò)展的功能，他可以把請求的這些資源文件，我們可以預(yù)先的將內(nèi)容進(jìn)行壓縮成一個(gè)壓縮包。

首先靜態(tài)的資源一定是要比動態(tài)的資源要效率高，通過壓縮之后可以減少磁盤的大小，并且還可以節(jié)約網(wǎng)絡(luò)的通道資源。

什么是靜態(tài)壓縮

靜態(tài)壓縮不適合反向代理只適合資源服務(wù)器，他可以把壓縮的文件傳遞給客戶端，靜態(tài)壓縮就是在資源路徑下會有一個(gè)資源文件還會有一個(gè)對應(yīng)名稱的壓縮包。并且Nginx會優(yōu)先找壓縮包，直接通過 sendfile 將數(shù)據(jù)傳遞過去。

Nginx 將壓縮的文件通過網(wǎng)絡(luò)發(fā)送過去，然后當(dāng)瀏覽器接收到Nginx發(fā)送的壓縮包文件，并進(jìn)行解壓縮的操作。他會在發(fā)送給客戶端之前將壓縮包接口在發(fā)送給客戶端。

3. 配置

該http_gzip_static_module模塊允許發(fā)送帶有“”文件擴(kuò)展名的預(yù)壓縮文件，.gz而不是常規(guī)文件。默認(rèn)情況下不構(gòu)建此模塊，應(yīng)使用 --with-http_gzip_static_module 配置參數(shù)啟用它。這個(gè)模塊沒有在預(yù)編譯的包里，需要手動添加，這個(gè)模塊的作用就是把壓縮包解壓開

with是內(nèi)部模塊，add是外部的模塊。

首次安裝 nginx時(shí)使用

./configure --prefix==/usr/local/nginx --with-hhtp_gzip_static_module
make && make install

已經(jīng)安裝過 nginx，對nginx客戶端升級時(shí)使用命令

./configure --prefinx==/usr/local/nginx --with-http_gzip_static_module

make不要make install 否則會覆蓋之前的文件

在將 objs的nginx 程序拷貝到 /usr/local/nginx/sbin 下·，注意需要做好原 nginx 程序備份。

語法： gzip_static on | off | always;

作用：是否開啟靜態(tài)壓縮功能。

參數(shù)值：

on ：開啟靜態(tài)壓縮，并會檢測瀏覽器是否支持，如果不支持則不會走靜態(tài)壓縮，
off ：關(guān)閉靜態(tài)壓縮
always：是否使用靜態(tài)壓縮，無論瀏覽器是否支持靜態(tài)壓縮功能。
- 這樣就會引發(fā)一個(gè)問題，如果客戶端不支持，就解不開，如果磁盤上沒有未壓縮的文件默認(rèn)會報(bào)404，可以配合 ngx_http_gunzip_module ，模塊使用。
默認(rèn)值：gzip_static on
適用于：http、server、location

使用的需要將本地的資源文件進(jìn)行壓縮，壓縮成 xxx.gz的文件

cd /usr/local/nginx/html 
gzip *

注意：開啟之后默認(rèn)就會先訪問 .gz 的文件了，如果不支持靜態(tài)壓縮則會訪問正常文件，如果沒有正常的文件只有 .gz 那么就會報(bào)錯(cuò) 。

4. nginx_http_gunzip_module 模塊

這個(gè)模塊是配合 gzip_static always時(shí)使用的，因?yàn)?當(dāng)配置程 always 時(shí)，所有的請求會都進(jìn)行找壓縮文件，在文件存不存在或者說瀏覽器支不支持靜態(tài)壓縮，nginx都會將靜態(tài)壓縮文件返回給瀏覽器，如果瀏覽器不支持的話會導(dǎo)致文件解不開，也就是 404 。

這個(gè)模塊它沒有在預(yù)編譯的包里，需要手動添加，這個(gè)模塊的作用就是把靜態(tài)的壓縮包解壓開，他會在發(fā)送給客戶端之前將壓縮包接口在發(fā)送給客戶端，它相當(dāng)于是一層攔截器，它的作用就是可以把源文件進(jìn)行壓縮，我們可以把源文件進(jìn)行刪除了，節(jié)省磁盤空間，但是一般會用到。

注意： with 是內(nèi)部、 add 是外部的

安裝命令：

./configure --prefix=/usr/local/nginx --add-module=/tools/nginx-sticky --with-http_gzip_static_module --with-http_gunzip_module

make

如果是替換的話，則將這個(gè)文件中的這個(gè)文件 cp 到 nginx的安裝目錄下的 sbin

移動命令：

 cp /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.old2
 
 cd /tools/nginx/objs 
 mv nginx /usr/local/nginx/sbin/

這里沒有g(shù)zip，但也沒有 context-length 因?yàn)閚ginx需要把文件解壓縮，他也不知道具體文件有多大，這個(gè) gzip_static 適用場景：在作為cdn服務(wù)器或者 cdn上游服務(wù)器文件存儲服務(wù)器時(shí)，我們就可以把本地原始文件刪了，只展示zip 包，把解壓縮的壓力丟棄給客戶端，同時(shí)可以把本地壓縮等級，提高不是 gzip的壓縮等級，經(jīng)常高配訪問的一些頁面 css js ，也可以通過 static壓縮。

靜態(tài)壓縮響應(yīng)結(jié)果會有 Context-Encoding : gzip 、Conten-Length：392 有展示 context-length 表示他開啟了靜態(tài)壓縮，預(yù)壓縮直接返回zip包沒有源文件，1.速度快，2節(jié)省服務(wù)器資源。

四、Brotli

Brotli 是 Google 推出的開源壓縮算法，通過變種的 LZ77 算法、Huffman 編碼以及二階文本建模等方式進(jìn)行數(shù)據(jù)壓縮，與其他壓縮算法相比，它有著更高的壓縮效率，性能也比我們目前常見的 Gzip 高17-25%，可以幫我們更高效的壓縮網(wǎng)頁中的各類文件大小及腳本，從而提高加載速度，提升網(wǎng)頁瀏覽體驗(yàn)。需要說明的是 Brotli 壓縮只在 https 下生效，因?yàn)?在 http 請求中 request header 里的 Accept-Encoding: gzip, deflate 是沒有 br 的。

Brotli 如此高的壓縮比率，得益于其使用一個(gè)預(yù)定義的字典，該字典包含超過 13000 個(gè)來自文本和 HTML 文檔的大型語料庫的常用字符串，預(yù)定義的算法可以提升較小文件的壓縮密度，而壓縮與解壓縮速度則大致不變。

Brotli 憑借它優(yōu)異的壓縮性能迅速占領(lǐng)了市場，從下圖可以看到，除了 IE 和 Opera Mini 之外，幾乎所有的主流瀏覽器都已支持 Brotli 算法，因此處于資源占用的考慮，比如說流量，建議啟用：

Brotil 規(guī)范由 Google 員工 Jyrki Alakuijala 和 Zoltan Szabadka 于 2013-2016開發(fā)，并伴隨著規(guī)范的倆個(gè)作者Evgenii Kuliuchniko 和 Lode Vandevenne共同開發(fā)的參考實(shí)現(xiàn)，后者之前開發(fā)了谷歌的zopfli在2013年重新實(shí)現(xiàn)了收縮 /gzip 壓縮格式。與zopfli不同，后者是對現(xiàn)有數(shù)據(jù)格式規(guī)范的重新實(shí)現(xiàn)，Brotli 是一種新的數(shù)據(jù)格式，并允許作者進(jìn)一步提高壓縮比。

4.1 Brotli 概述

Brotli 的編碼器提供了 12 個(gè)質(zhì)量級別（從 0 到 11）。它們是壓縮速度換取壓縮效率的壓縮模式：更高質(zhì)量的幾倍速度較慢，但會產(chǎn)生更好的壓縮比。

一個(gè) Brotli 壓縮文件由元塊（meta-blocks）集合組成。每個(gè)元塊最多可容納 16 MiB，由倆部分組成：一個(gè) 數(shù)據(jù)部分（data part），它存儲 LZ77 壓縮的放入快，以及一個(gè) 標(biāo)題（header），每個(gè)塊的壓縮遵循經(jīng)典的 ①LZ77 壓縮方案并由 ②計(jì)算具有良好的LZ77解析和計(jì)算 LZ 短語的簡潔編碼這倆個(gè)主要階段組成。

它效率高是因?yàn)閮?nèi)置了 n多個(gè)字典，包含都是一些常見的文件文件 css 、js 等等一些標(biāo)簽，如果我們將這些標(biāo)簽歸類生成一個(gè)字典之后，我們就可以按照序號去解壓這個(gè)文件了。

并且它在 Nginx 中話是可以和 Gzip 共存，開啟了Brotli 不會導(dǎo)致 Gzip失效，如果瀏覽器支持brotli 那么優(yōu)先使用 Brotli ，不支持在使用 Gzip。

4.2 Brotli 的安裝

--add-dynamic-module表示動態(tài)的引入模塊在配置文件中還需要單獨(dú)加入 load_module path/xxx

官網(wǎng)

https://github.com/google/ngx_brotli
https://codeload.github.com/google/brotli/tar.gz/refs/tags/v1.0.9

下載倆個(gè)項(xiàng)目

解壓縮

brotli-1.0.9 是 brotli 算法模塊，需要先解壓。
- tar -zxvf brotli-1.0.9.tar.gz
ngx_brotli-1.0.0rc 是nginx的 brotli的模塊。這模塊里需要引入 brotli 算法模塊
- tar -zxvf ngx_brotli-1.0.0rc.tar.gz

接下來講 brotli 的內(nèi)容全部復(fù)制到 ngx_brotli 的 deps/brotli/目錄

cd /tools/brotli-1.0.9
cp -r * /tools/ngx_brotli-1.0.0rc/deps/brotli/

模塊化編譯：

./configure --with-compat --add-dynamic-module=/tools/ngx_brotli-1.0.0rc --prefix=/usr/local/nginx/

或

--add-dynamic-module=brotli目錄

加載所有的壓縮模塊

./configure --with-compat --add-dynamic-module=/tools/ngx_brotli-1.0.0rc --prefix=/usr/local/nginx/ --add-module=/tools/nginx-sticky --with-http_gzip_static_module --with-http_gunzip_module

make && make install

下載的兩個(gè)模塊拷貝到 /usr/local/nginx/modules/

首先在 /usr/local/nginx創(chuàng)建一個(gè)modules文件夾 mkdir modules

mv ngx_http_brotli_filter_module.so ngx_http_brotli_static_module.so /usr/local/nginx/modules/

最后將新編譯的 nginx 啟動程序復(fù)制到 /usr/local/nginx/sbin下做好之前程序復(fù)制。

cp /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.oid3
mv /tools/nginx-12.0/objs/nginx /usr/local/nginx/sbin/

在配置文件中動態(tài)加載模塊

load_module "/usr/local/nginx/modules/ngx_http_brotli_filter_module.so";
load_module "/usr/local/nginx/modules/ngx_http_brotli_static_module.so";

4.3 配置選項(xiàng)

具體的配置選項(xiàng)可以查看GitHub： https://github.com/google/ngx_brotli

brotli的配置可以參考Gzip的配置，幾乎一致。

brotli

語法：brotli on | off
默認(rèn)值：brotli off
適用于： http、server、location、if
作用：開啟或者禁用brotli 壓縮功能。

brotli_static

語法：brotli_static on | off | always
默認(rèn)值：brotli_static off
適用于：http、server、location
作用：brotli 也是支持預(yù)先壓縮文件，啟用或禁用檢查是否存在帶擴(kuò)展名的預(yù)壓縮文件.br 。使用該always值，在所有情況下都使用預(yù)壓縮文件，而不檢查客戶端是否支持它。

brotli_types

語法：brotli_types <mime_type> [...]
默認(rèn)值：brotli_types text/html
適用于： http、server、location
作用：指定哪些資源類型需要進(jìn)行壓縮操作，特殊值*匹配任何 MIME類型。

brotli_buffers

語法：brotli_buffers <number> <size>
默認(rèn)值： 32 4k | 16 8 k
適用于： http、server、location
作用：設(shè)置壓縮緩沖區(qū)大小，最新版本以及棄用了。

brotli_comp_level

語法：brotli_comp_level <level>
默認(rèn)值：6'
適用于： http、server、location
作用：設(shè)置即時(shí)壓縮 Brotli 質(zhì)量（壓縮）level。0可接受的值在從到的范圍內(nèi)11。

brotli_window

語法：brotli_window <size>
默認(rèn)值： 512k
適用于：http、server、 location
作用：設(shè)置 Brotli 窗口size?？梢员茸魇且粋€(gè)桌子，將要壓縮的文件同時(shí)放在這個(gè)桌子上，這個(gè)桌子上可以放多少文件的大小，這個(gè)值也不越大越好，他比較占內(nèi)存，值增加建議是2的倍數(shù)，可接受的值為1k, 2k, 4k, 8k, 16k, 32k, 64k, 128k, 256k, 512k, 1m, 2m,和4m。8m 16m

brotli_min_length

語法：brotli_min_length <length>
默認(rèn)值：20
適用于： http、server、location
作用：指定進(jìn)行壓縮的文件最小的長度，如果小于這個(gè)值則不壓縮。

#加載動態(tài)模塊 
load_module "/usr/local/nginx/modules/ngx_http_brotli_filter_module.so";
load_module "/usr/local/nginx/modules/ngx_http_brotli_static_module.so";
worker_processes  1;
events {
    worker_connections  1024;
}
 
http {
    server {
    listen       80;
    server_name  localhost;
        location  / {
          #brotli配置 
          brotli on;  # 開啟 壓縮
        brotli_static on; # 是否開啟預(yù)先壓縮，開啟之后就會 .br的壓縮包
          brotli_comp_level 6; # 壓縮等級
          brotli_buffers 16 8k; # 緩沖區(qū)大小 ，已經(jīng)啟用 
          brotli_min_length 20; # 壓縮時(shí)文件最小限制 
          # 對哪些mime.types類型進(jìn)行壓縮
          brotli_types text/plain text/css text/javascript application/javascript text/xml application/xml application/xml+rss application/json image/jpeg image/gif image/png;
    
          }
  }
}

4.4 brotli 測試

因?yàn)槟J(rèn) brotli 是必現(xiàn) https 請求才能使用的，因?yàn)?http的請求請求頭的 Accept-Encoding 是沒有 br的，所以服務(wù)器是無法知道客戶端可以使用的。

測試方案：

使用 linux 的 curl 命令：

curl -H 'Accept-Encding : br' -I 192.168.101.128/index.html

[root@localhost sbin]# curl -H Accept-Encoding:br  -I http://192.168.101.128/static_page.html
HTTP/1.1 200 OK
Server: nginx/1.20.2
Date: Fri, 17 Feb 2023 08:11:05 GMT
Content-Type: text/html
Last-Modified: Fri, 17 Feb 2023 03:28:14 GMT
Connection: keep-alive
Keep-Alive: timeout=65
Vary: Accept-Encoding
ETag: W/"63eef44e-31"
Content-Encoding: br
[root@localhost sbin]# curl  -I http://192.168.101.128/static_page.html
HTTP/1.1 200 OK
Server: nginx/1.20.2
Date: Fri, 17 Feb 2023 08:11:54 GMT
Content-Type: text/html
Last-Modified: Fri, 17 Feb 2023 03:28:14 GMT
Connection: keep-alive
Keep-Alive: timeout=65
Vary: Accept-Encoding
ETag: W/"63eef44e-31"

到此這篇關(guān)于Nginx 請求壓縮的實(shí)現(xiàn)(動態(tài)壓縮,靜態(tài)壓縮)的文章就介紹到這了,更多相關(guān)Nginx 請求壓縮內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: