第七節——壓縮和解壓

1    介紹

壓縮響應一般能夠顯著減小傳輸數據的大小。然而，壓縮發生在運行時，也會增長至關大的處理開銷，對性能有負面影響。NGINX在發送響應到客戶端時執行壓縮，但不對已經壓縮的響應「二次壓縮」。

2    啓用壓縮

爲了啓用壓縮，設置gzip指令爲on：

gzip on;

默認，NGINX只壓縮MIME爲text/html類型的響應。爲了壓縮其它MIME類型的響應，須要設置gzip_types指令。

gzip_types text/plain application/xml;

使用gzip_min_length指令指定進行壓縮的響應的最小大小。默認是20字節（下面調整爲1000字節）。

gzip_min_length 1000;

默認，NGINX不壓縮代理請求（來自代理服務器的請求）的響應。來自代理服務器的請求由請求的Via頭字段決定。使用gzip_proxied指令配置壓縮這些響應。指令有大量參數指定NGINX應該壓縮那些種類的代理請求的響應。例如，只有請求不緩存在代理服務器上，壓縮響應纔是合理的。因爲這個目的，gzip_proxied指令有參數指示NGINX檢查響應的Cache-Control頭字段，若是值是no-cache、no-store或private則壓縮響應。此外，你必須爲Expires頭字段指定expired參數值。在下面例子中，這些參數和auth參數同樣被設置，檢查Authorization頭字段的存在性（特定終端用戶已受權的響應一般不會緩存）：

gzip_proxied no-cache no-store private expired auth;

和大多數其它指令同樣，壓縮指令能夠包括在http、server或location配置塊。

gzip的整體配置以下所示：

server {

    gzip on;

    gzip_types      text/plain application/xml;

    gzip_proxied    no-cache no-store private expired auth;

    gzip_min_length 1000;

    # ...

}

3    啓用解壓

有些客戶端不支持gzip編碼響應。同時，這些客戶端能夠存儲壓縮數據，或壓縮動態響應並存儲在緩存中。爲了成功的服務能接收和不能接收壓縮數據的客戶端，NGINX能動態解壓數據發送給不能接收壓縮數據的客戶端。

使用gunzip指令啓用運行時解壓。

location /storage/ {

    gunzip on;

    # ...

}

gunzip指令和gzip指令能夠用於相同上下文：

server {

    gzip on;

    gzip_min_length 1000;

    gunzip on;

    # ...

}

注意，這個指令是一個單獨的模塊，默認，沒有包括在開源NGINX構建中。

4    發送壓縮文件

爲了發送一個壓縮版本的文件給客戶端而不是普通的，設置gzip_static指令爲on。

location / {

    gzip_static on;

}

在這種狀況下，服務請求/path/to/file，NGINX嘗試找到併發送文件/path/to/file.gz。若是文件不存在，或客戶端不支持gzip，NGINX發送未壓縮的文件。

注意，gzip_static指令不啓用在線壓縮。它只是使用壓縮工具預先壓縮好文件。爲了在運行時壓縮內容（不只是靜態內容），使用gzip指令。

注意，這個指令是一個單獨的模塊，默認，沒有包括在開源的Nginx構建中。