如何改進 NGINX 配置文件節省帶寬？

本文翻譯轉載自nginx官網，原文地址

一、爲HTML，CSS和JavaScript文件啓用Gzip壓縮

如你所知，用於在現代網站上構建頁面的HTML，CSS和JavaScript文件可能很是龐大。在大多數狀況下，Web服務器能夠即時壓縮這些和其餘文本文件，以節省網絡帶寬。

查看Web服務器是否正在壓縮文件的一種方法是使用瀏覽器的開發人員工具。對於許多瀏覽器，你可使用F12鍵訪問這些工具，而且相關信息位於Network 選項卡上。這是一個例子：

如你在左下方所見，沒有壓縮：文本文件的大小爲1.15 MB，而且傳輸了不少數據。

默認狀況下，NGINX中禁用壓縮，可是根據你的安裝或Linux發行版，某些設置可能會在默認的nginx.conf文件中啓用。在這裏，咱們在NGINX配置文件中啓用gzip壓縮：

gzip on;
gzip_types application/xml application/json text/css text/javascript application/javascript;
gzip_vary on;
gzip_comp_level 6;
gzip_min_length 500;
複製代碼

如你在如下屏幕截圖中所見，壓縮後的數據傳輸量僅爲260 KB ，減小了約80％！對於頁面上的每一個新用戶，你能夠節省大約917 KB的數據傳輸。對於咱們的WooCommerce安裝，天天62 MB，或每個月1860 MB。

二、設置緩存頭

當瀏覽器檢索網頁的文件時，它會將副本保留在本地磁盤緩存中，這樣，當你再次訪問該頁面時，它沒必要從服務器從新獲取文件。每一個瀏覽器都使用本身的邏輯來決定什麼時候使用文件的本地副本以及什麼時候在服務器上更改了文件時再次獲取它。可是，做爲網站全部者，你能夠在發送的HTTP響應中設置緩存控制和過時標頭，以提升瀏覽器的緩存行爲的效率。從長遠來看，你會收到不少沒必要要的HTTP請求。

首先，你能夠爲字體和圖像設置較長的緩存過時時間，這些字體和圖像可能不會常常更改（即便更改，它們一般也會得到新的文件名）。在如下示例中，咱們指示客戶端瀏覽器將字體和圖像在本地緩存中保留一個月：

location ~* \.(?:jpg|jpeg|gif|png|ico|woff2)$ {
    expires 1M;
    add_header Cache-Control "public";
}
複製代碼

三、啓用HTTP / 2協議支持

HTTP / 2是用於服務網頁的下一代協議，旨在更好地利用網絡和主機服務器。根據Google文檔，它能夠更快地加載頁面：

生成的協議對網絡更友好，由於與HTTP / 1.x相比，使用的TCP鏈接更少。這意味着與其餘流量的競爭減小，鏈接壽命更長，從而能夠更好地利用可用網絡容量。

NGINX 1.9.5和更高版本（以及NGINX Plus R7和更高版本）支持HTTP / 2協議，你所須要作的就是啓用它。爲此，請在你的NGINX配置文件中http2的listen指令中包含參數：

listen 443 ssl http2;
複製代碼

請注意，在大多數狀況下，你還須要啓用TLS才能使用HTTP / 2。

你能夠經過HTTP2.Pro服務驗證你（或任何站點）是否支持HTTP / 2 ：

四、優化日誌

讓本身喝一杯本身喜歡的飲料，溫馨地坐着，而後思考：你上次查看訪問日誌文件是何時？上週，上個月，歷來沒有？即便將其用於站點的平常監視，你也可能只關注錯誤（400和500狀態代碼等），而不關注成功的請求。

經過減小或消除沒必要要的日誌記錄，能夠節省服務器上的磁盤存儲，CPU和I / O操做。這不只使你的服務器更快一點-若是將你部署在雲環境中，則釋放的I / O吞吐量和CPU週期可能爲同一虛擬機上的其餘虛擬機或應用程序節省生命。

有幾種不一樣的方法能夠減小和優化日誌記錄。在這裏，咱們重點介紹三個。

方法1：禁用頁面資源請求的記錄

若是你不須要記錄檢索普通頁面資源（例如圖像，JavaScript文件和CSS文件）的請求，則這是一種快速簡便的解決方案。你須要作的就是建立一個location與這些文件類型匹配的新塊，並禁用其中的日誌記錄。（你也能夠將此access_log指令添加到咱們設置標頭的上方的location塊中。）Cache-Control

location ~* \.(?:jpg|jpeg|gif|png|ico|woff2|js|css)$ {
    access_log off;
}
複製代碼

方法2：禁用成功請求的日誌記錄

這是一種更強大的方法，由於它會丟棄帶有或響應代碼的查詢，僅記錄錯誤。它比方法1稍微複雜一點，由於它取決於如何配置NGINX日誌記錄。在咱們的示例中，咱們使用Ubuntu Server發行版中包含的標準nginx.conf，所以，不管虛擬主機如何，全部請求都記錄到**/var/log/nginx/access.log中**。2*xx*``3*xx*

使用官方NGINX文檔中的示例，讓咱們打開條件日誌記錄。建立一個變量$loggable，並將其設置爲，0以使用和代碼進行請求，不然設置爲 。而後在指令中將此變量做爲條件引用。2*xx*``3*xx*``1``access_log

這是**/etc/nginx/nginx.conf**中http上下文中的原始指令：

access_log /var/log/nginx/access.log;
複製代碼

添加一個map塊並從access_log指令中引用它：

map $status $loggable {
    ~^[23] 0;
    default 1;
}

access_log /var/log/nginx/access.log combined if=$loggable;
複製代碼

請注意，儘管這combined是默認的日誌格式，可是在包含if參數時，你須要明確指定它。

方法3：使用緩衝最小化I / O操做

即便你要記錄全部請求，也能夠經過打開訪問日誌緩衝來最大程度地減小I / O操做。使用此指令，NGINX會等待將日誌數據寫入磁盤，直到填滿512 KB緩衝區或自上次刷新以來通過1分鐘（以先發生者爲準）。

access_log /var/log/nginx/access.log combined buffer=512k flush=1m;
複製代碼

五、限制特定URL的帶寬

若是服務器提供較大的文件（或較小但很是受歡迎的文件，例如表單或報表），則設置客戶端下載文件的最大速度可能頗有用。若是你的站點已經承受了很高的網絡負載，則限制下載速度會留下更多帶寬，以使應用程序的關鍵部分保持響應速度。這是硬件製造商使用的很是流行的解決方案–你可能須要等待更長的時間才能爲打印機下載3 GB的驅動程序，可是同時有成千上萬的其餘人下載你仍然能夠下載。

使用limit_rate指令限制特定URL的帶寬。在這裏，咱們將**/ download** 下每一個文件的傳輸速率限制爲每秒50 KB。

location /download/ {
    limit_rate 50k;
}
複製代碼

你可能還但願僅對較大的文件進行速率限制，這可使用limit_rate_after指令進行。在此示例中，每一個文件（來自任何目錄）的前500 KB都不受速度限制地進行傳輸，以後的全部內容均以50 KB / s爲上限。這樣能夠加快網站關鍵部分的交付速度，同時下降其餘部分的速度。

location / {
    limit_rate_after 500k;
    limit_rate 50k;
}
複製代碼

請注意，速率限制適用於瀏覽器和NGINX之間的單個HTTP鏈接，所以請不要阻止用戶使用下載管理器來解決速率限制。

最後，你還能夠限制到服務器的併發鏈接數或請求速率。有關詳細信息，請參見咱們的文檔。