博文大綱:
創(chuàng)新互聯(lián)主營博興網(wǎng)站建設的網(wǎng)絡公司,主營網(wǎng)站建設方案,app軟件開發(fā)公司,博興h5微信平臺小程序開發(fā)搭建,博興網(wǎng)站營銷推廣歡迎博興等地區(qū)企業(yè)咨詢
- 一、Nginx的安裝;
- 二、Nginx服務實現(xiàn)反向代理;
- 三、Nginx服務優(yōu)化
關(guān)于Nginx的基本概念,在之前的博文中:搭建Nginx服務器及其配置文件詳解 有詳細的介紹,這篇博文就直接從安裝開始談起。
環(huán)境準備:
- 三臺centos 7.5,其中一臺運行Nginx,另外兩臺運行簡單的web服務即可,主要用來測試Nginx反向代理的效果;
- 下載我提供的包,安裝Nginx時需要,用來做緩存及壓縮等優(yōu)化項的。
注(實現(xiàn)效果如下):
- 結(jié)合 proxy 和 upstream 模塊實現(xiàn)后端 web 負載均衡;
- 使用 proxy 模塊實現(xiàn)靜態(tài)文件緩存;
- 結(jié)合 nginx 默認自帶的 ngx_http_proxy_module 模塊 和 ngx_http_upstream_module 模塊實現(xiàn)后端服務器的健康檢查,也可以使用第三方模塊 nginx_upstream_check_module;
- 使用 nginx-sticky-module 擴展模塊實現(xiàn) 保持會話;
- 使用 ngx_cache_purge 實現(xiàn)更強大的緩存清除功能;
- 使用ngx_brotli模塊實現(xiàn)網(wǎng)頁文件壓縮。
上面提到的 2 個模塊都屬于第三方擴展模塊,需要提前下好源碼(我在前面的下載鏈接中包含著這幾個模塊),然后編譯時通過--add-moudle=src_path 一起安裝。
[root@nginx nginx-1.14.0]# yum -y erase httpd #卸載系統(tǒng)默認的httpd服務,防止端口沖突
[root@nginx nginx-1.14.0]# yum -y install openssl-devel pcre-devel #安裝所需依賴
[root@nginx src]# rz #rz命令上傳所需源碼包
[root@nginx src]# ls #確認上傳的源碼包
nginx-sticky-module.zip ngx_brotli.tar.gz
nginx-1.14.0.tar.gz ngx_cache_purge-2.3.tar.gz
#將上傳的源碼包進行解壓
[root@nginx src]# tar zxf nginx-1.14.0.tar.gz
[root@nginx src]# unzip nginx-sticky-module.zip
[root@nginx src]# tar zxf ngx_brotli.tar.gz
[root@nginx src]# tar zxf ngx_cache_purge-2.3.tar.gz
[root@nginx src]# cd nginx-1.14.0/ #切換至nginx目錄
[root@nginx nginx-1.14.0]# ./configure --prefix=/usr/local/nginx1.14 --user=www --group=www --with-http_stub_status_module --with-http_realip_module --with-http_ssl_module --with-http_gzip_static_module --http-client-body-temp-path=/var/tmp/nginx/client --http-proxy-temp-path=/var/tmp/nginx/proxy --http-fastcgi-temp-path=/var/tmp/nginx/fcgi --with-pcre --add-module=/usr/src/ngx_cache_purge-2.3 --with-http_flv_module --add-module=/usr/src/nginx-sticky-module && make && make install
#進行編譯安裝,并且使用“--add-module”選項加載需要的模塊
#注意,以上并沒有加載ngx_brotli模塊,是為了稍后展示在已經(jīng)安裝nginx服務后,如何添加模塊
關(guān)于上述的編譯選項解釋如下:
- --with-http_stub_status_module:通過網(wǎng)頁監(jiān)控nginx的狀態(tài);
- --with-http_realip_module:獲取客戶端的真實IP地址;
- --with-http_ssl_module:開啟nginx的加密傳輸功能;
- --with-http_gzip_static_module:開啟壓縮功能;
- --http-client-body-temp-path=/var/tmp/nginx/client:客戶端訪問數(shù)據(jù)臨時存放路徑(緩存存放的路徑);
- --http-proxy-temp-path=/var/tmp/nginx/proxy:同上;
- --http-fastcgi-temp-path=/var/tmp/nginx/fcgi:同上;
- --with-pcre:支持正則匹配表達式;
- --add-module=/usr/src/ngx_cache_purge-2.3:添加nginx的第三方模塊,語法為:--add-module=第三方模塊路徑;
- --add-module=/usr/src/nginx-sticky-module:同上;
- --with-http_flv_module:支持flv視頻流。
[root@nginx nginx-1.14.0]# ln -s /usr/local/nginx1.14/sbin/nginx /usr/local/sbin/
#創(chuàng)建nginx命令的軟連接,以便可以直接使用
[root@nginx nginx-1.14.0]# useradd -M -s /sbin/nologin www
[root@nginx nginx-1.14.0]# mkdir -p /var/tmp/nginx/client
[root@nginx nginx-1.14.0]# nginx -t #檢查nginx配置文件
nginx: the configuration file /usr/local/nginx1.14/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx1.14/conf/nginx.conf test is successful
[root@nginx nginx-1.14.0]# nginx #啟動nginx服務
[root@nginx nginx-1.14.0]# netstat -anpt | grep ":80" #查看80端口是否在監(jiān)聽
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 7584/nginx: master
在實現(xiàn)這個反向代理之前,這里還是要說一下,什么是反向代理?什么是正向代理?
用于代理內(nèi)部網(wǎng)絡對 Internet 的連接請求(如 NAT),客戶端指定代理服務器,并將本來要直接發(fā)送給目標Web服務器的HTTP請求先發(fā)送到代理服務器上, 然后由代理服務器去訪問 Web 服務器, 并將 Web 服務器返回的信息的回傳給客戶端,此時,這個代理服務器就是正向代理。
與正向代理相反,如果局域網(wǎng)向Internet提供資源,并讓Internet上的其他用戶可以訪問局域網(wǎng)內(nèi)資源, 也可以設置一個代理服務器, 它提供的服務就是反向代理. 反向代理服務器接受來自 Internet 的連接,然后將請求轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡上的服務器,并將 web服務器的返回信息回傳給
Internet 上請求連接的客戶端。
總而言之:正向代理的對象是客戶端,代替客戶端去訪問web服務器;反向代理的對象是web服務器,代理web服務器去回應客戶端。
可以配置 nginx 作為反向代理和負載均衡,同時利用其緩存功能,將靜態(tài)頁面在 nginx 緩存,以達到降低后端服務器連接數(shù)的目的并檢查后端 web 服務器的健康狀況。
環(huán)境如下:
- 一臺Nginx服務器作為反向代理;
- 兩臺后端web服務器組成web服務器池;
- 客戶端訪問Nginx代理服務器,可以多次刷新頁面,得到不同后端web服務器返回的頁面。
開始配置Nginx服務器:
[root@nginx ~]# cd /usr/local/nginx1.14/conf/ #切換至指定目錄
[root@nginx conf]# vim nginx.conf #編輯主配置文件
........................#省略部分內(nèi)容
http{
........................#省略部分內(nèi)容
upstream backend {
sticky;
server 192.168.20.2:80 weight=1 max_fails=2 fail_timeout=10s;
server 192.168.20.3:80 weight=1 max_fails=2 fail_timeout=10s;
}
........................#省略部分內(nèi)容
server {
location / {
#root html; #將原本的根目錄注釋掉
#index index.html index.htm; #注釋掉改行
proxy_pass http://backend; #這里指定的“backend”須與上面的web池名稱對應。
}
}
}
#編輯完成后,保存退出即可。
[root@nginx conf]# nginx -t #檢查配置文件,確認無誤
[root@nginx conf]# nginx -s reload #重啟nginx服務,以便生效
上述web服務器池的配置中有一個“sticky”的配置項,其實就是加載了nginx-sticky模塊,這個模塊的作用是通過 cookie 黏貼的方式將來自同一個客戶端(瀏覽器)的請求發(fā)送到同一個后端服務器上處理,這樣一定程度上可以解決多個 backend servers 的會話同步的問題(所謂會話同步,就好比訪問頁面時,登錄一次即可,在一定時間段內(nèi)無需再次登錄,這就是會話的概念),而 RR 輪詢模式必須要運維人員自己考慮 session 同步的實現(xiàn)。另外內(nèi)置的 ip_hash 也可以實現(xiàn)根據(jù)客戶端 IP 來分發(fā)請求,但它很容易造成負載不均衡的情況,而如果 nginx 前面有來自同一局域網(wǎng)的訪問,它接收的客戶端 IP 是一樣的,容易造成負載不均衡現(xiàn)象。nginx-sticky-module 的 cookie 過期時間,默認瀏覽器關(guān)閉就過期。
這個模塊并不合適不支持 Cookie 或手動禁用了 cookie 的瀏覽器,此時默認 sticky 就會切換成 RR。它不能與 ip_hash 同時使用。
sticky只是Nginx支持的其中一種調(diào)度算法,下面是Nginx的負載均衡模塊支持的其他調(diào)度算法:
- 輪詢(默認,RR):每個請求按時間順序逐一分配到不同的后端服務器,如果后端某臺服務器宕機,故障系統(tǒng)被自動剔除,使用戶訪問不受影響。Weight 指定輪詢權(quán)值,Weight 值越大,分配到的訪問機率越高,主要用于后端每個服務器性能不均的情況下。
- ip_hash : 每個請求按訪問 IP 的 hash 結(jié)果分配,這樣來自同一個 IP 的訪客固定訪問一個后端服務器,有效解決了動態(tài)網(wǎng)頁存在的 session 共享問題。當然如果這個節(jié)點不可用了,會發(fā)到下個節(jié)點,而此時沒有 session 同步的話就注銷掉了。
- least_conn :請求被發(fā)送到當前活躍連接最少的 realserver 上。會考慮 weight 的值。
- url_hash : 此方法按訪問 url 的 hash 結(jié)果來分配請求,使每個 url 定向到同一個后端服務器,可以進一步提高后端緩存服務器的效率。Nginx 本身是不支持 url_hash 的,如果需要使用這種調(diào)度算法,必須安裝 Nginx 的 hash 軟件包 nginx_upstream_hash 。
- fair :這是比上面兩個更加智能的負載均衡算法。此種算法可以依據(jù)頁面大小和加載時間長短智能地進行負載均衡,也就是根據(jù)后端服務器的響應時間來分配請求,響應時間短的優(yōu)先分配。Nginx 本身是不支持 fair 的,如果需要使用這種調(diào)度算法,必須下載 Nginx的upstream_fair 模塊。
關(guān)于上述配置文件中web池中web服務器IP地址后面的配置解釋:
- weight : 輪詢權(quán)值也是可以用在 ip_hash 的,默認值為 1;
- max_fails : 允許請求失敗的次數(shù),默認為 1。當超過最大次數(shù)時,返回 proxy_next_upstream模塊定義的錯誤。
- fail_timeout : 有兩層含義,一是在 10s 時間內(nèi)最多容許2次失??;二是在經(jīng)歷了2次失敗以后,10s 時間內(nèi)不分配請求到這臺服務器。
web服務器池中的服務器配置如下(僅供參考,這里為了測試,只是簡便的搭建了一下httpd服務):
[root@web01 ~]# yum -y install httpd #安裝httpd服務
[root@web01 ~]# echo "192.168.20.2" > /var/www/html/index.html #兩臺web服務器準備不同的網(wǎng)頁文件
[root@web01 ~]# systemctl start httpd #啟動web服務
第二臺web服務器進行以上相同的操作即可,只是注意要準備不同的網(wǎng)頁文件,以便測試負載均衡的效果。
現(xiàn)在就可以進行客戶端訪問驗證了,但是需要注意的是,nginx代理服務器必須可以和兩臺wbe服務器進行通信。
在nginx代理服務器上訪問自己本身測試(可以看到是在對web服務器池中的web服務器進行輪詢):
若使用Windows客戶端進行訪問測試,由于配置文件中有“sticky”配置,所以會將每次的刷新請求還是轉(zhuǎn)交給同一臺web服務器,并無法測試出負載均衡的效果,只需將“sticky”那行注釋掉,即可測試出負載均衡的效果。
所謂優(yōu)化,除了控制其工作線程以外,還有幾個更重要的概念,也就是緩存及網(wǎng)頁壓縮,由于其涉及的配置項比較多,我將把完整的http{ }字段的配置文件寫到下面,并注釋,在博文的末尾會附上一個沒有注釋的http{ }字段。
在優(yōu)化之前,我好像在編譯安裝Nginx時,故意漏掉一個模塊沒有加載,就是為了展示如果沒有加載所需的模塊,怎么進行加載?
配置如下:
[root@nginx conf]# cd /usr/src/nginx-1.14.0/ #切換至Nginx源碼包
[root@nginx nginx-1.14.0]# nginx -V #執(zhí)行“ Nginx -V ”,查看已加載的模塊
nginx version: nginx/1.14.0
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC)
built with OpenSSL 1.0.2k-fips 26 Jan 2017
TLS SNI support enabled
configure arguments: --prefix=/usr/local/nginx1.14 --user=www --group=www --with-http_stub_status_module --with-http_realip_module --with-http_ssl_module --with-http_gzip_static_module --http-client-body-temp-path=/var/tmp/nginx/client --http-proxy-temp-path=/var/tmp/nginx/proxy --http-fastcgi-temp-path=/var/tmp/nginx/fcgi --with-pcre --add-module=/usr/src/ngx_cache_purge-2.3 --with-http_flv_module --add-module=/usr/src/nginx-sticky-module
[root@nginx nginx-1.14.0]# ./configure --prefix=/usr/local/nginx1.14 --user=www --group=www --with-http_stub_status_module --with-http_realip_module --with-http_ssl_module --with-http_gzip_static_module --http-client-body-temp-path=/var/tmp/nginx/client --http-proxy-temp-path=/var/tmp/nginx/proxy --http-fastcgi-temp-path=/var/tmp/nginx/fcgi --with-pcre --add-module=/usr/src/ngx_cache_purge-2.3 --with-http_flv_module --add-module=/usr/src/nginx-sticky-module --add-module=/usr/src/ngx_brotli && make
#將上述查到的已加載的模塊復制以下,重新編譯以下,同時,加上需要添加的模塊
#如我在上面添加了第三方模塊“--add-module=/usr/src/ngx_brotli”
[root@nginx nginx-1.14.0]# mv /usr/local/nginx1.14/sbin/nginx /usr/local/nginx1.14/sbin/nginx.bak
#將原本的Nginx控制文件更改名字,備份一下
[root@nginx nginx-1.14.0]# cp objs/nginx /usr/local/nginx1.14/sbin/
#將新生成的Nginx命令移動到相應的目錄下
[root@nginx nginx-1.14.0]# ln -sf /usr/local/nginx1.14/sbin/nginx /usr/local/sbin/
#對新的nginx命令做軟連接
[root@nginx ~]# nginx -s reload #nginx重啟一下服務
至此,新的模塊就添加完成了。
緩存也就是將 js、css、image 等靜態(tài)文件從后端服務器緩存到 nginx 指定的緩存目錄下,既可以減輕后端服務器負擔,也可以加快訪問速度,但這樣緩存及時清理成為了一個問題,所以需要 ngx_cache_purge 這個模塊來在過期時間未到之前,手動清理緩存。
proxy 模塊中常用的指令時 proxy_pass 和 proxy_cache。
nginx 的 web 緩存功能的主要是由 proxy_cache、fastcgi_cache 指令集和相關(guān)指令集完成,proxy_cache 指令負責反向代理緩存后端服務器的靜態(tài)內(nèi)容,fastcgi_cache 主要用來處理FastCGI 動態(tài)進程緩存(生產(chǎn)環(huán)境中不建議對動態(tài)頁面進行緩存)。
配置如下:
http {
include mime.types;
default_type application/octet-stream;
upstream backend {
sticky;
server 192.168.20.2:80 weight=1 max_fails=2 fail_timeout=10s;
server 192.168.20.3:80 weight=1 max_fails=2 fail_timeout=10s;
}
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"' #注意刪除這行后面的分號。
'"$upstream_cache_status"'; #增加這一行,記錄緩存的命中率到日志中
access_log logs/access.log main;
#增加以下幾行配置
proxy_buffering on; #代理的時候,開啟緩沖后端服務器的響應
proxy_temp_path /usr/local/nginx1.14/proxy_temp;
proxy_cache_path /usr/local/nginx1.14/proxy_cache levels=1:2 keys_zone=my-cache:100m inactive=600m max_size=2g;
# server字段配置如下:
server {
listen 80;
server_name localhost;
#charset koi8-r;
#access_log logs/host.access.log main;
location ~/purge(/.*) { #這個purge字段用來實現(xiàn)手動清除緩存
allow 127.0.0.1;
allow 192.168.20.0/24;
deny all;
proxy_cache_purge my-cache $host$1$is_args$args;
}
location / {
proxy_pass http://backend;
#這個“/ ”字段中添加以下配置,以便配置緩存相關(guān)的
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
proxy_cache my-cache;
add_header Nginx-Cache $upstream_cache_status;
proxy_cache_valid 200 304 301 302 8h;
proxy_cache_valid 404 1m;
proxy_cache_valid any 1d;
proxy_cache_key $host$uri$is_args$args;
expires 30d;
}
}
#編輯完成后,保存退出即可
[root@nginx conf]# nginx -t #檢查配置文件
nginx: the configuration file /usr/local/nginx1.14/conf/nginx.conf syntax
nginx: [emerg] mkdir() "/usr/local/nginx1.10/proxy_temp" failed (2: No suc
nginx: configuration file /usr/local/nginx1.14/conf/nginx.conf test failed
#提示相應的目錄沒有找到
[root@nginx conf]# mkdir -p /usr/local/nginx1.10/proxy_temp #那就創(chuàng)建相應的目錄咯
[root@nginx conf]# nginx -t #再次檢查,OK了
nginx: the configuration file /usr/local/nginx1.14/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx1.14/conf/nginx.conf test is successful
[root@nginx conf]# nginx -s reload #重啟Nginx服務
客戶端訪問測試(使用的是谷歌瀏覽器,訪問前按F12):
按“F5”刷新一下:
MISS 表示未命中,請求被傳送到后端;HIT 緩存命中(因為第一次訪問,Nginx服務器并沒有相應網(wǎng)頁的緩存,所以會傳送到后端web,第二次刷新時,Nginx本地就有緩存了,所以是“HIT”,緩存命中)。
查看Nginx的訪問日志,也可以查看到記錄的緩存相關(guān)信息:
[root@nginx conf]# tail ../logs/access.log #查看訪問日志
客戶端訪問以下地址(客戶端必須在 location ~/purge(/.*)允許的網(wǎng)段內(nèi)),可以在緩存失效前,手動清除Nginx服務器上的緩存(若沒有成功,先手動清除一下客戶端瀏覽器的緩存):
我這里的圖片截錯了,不好意思,若需要手動清理緩存的話,如果訪問時指定的URL是“192.168.20.5/index.html”,那么在清除緩存時,需要指定的URL就是“192.168.20.5/purge/index.html”,若訪問時指定的URL是“192.168.20.5”,那么在手動清除緩存時,需要指定的URL是“ 192.168.20.5/purge/ ”
以上部分配置的相關(guān)解釋如下:
- proxy_buffering [ on | off ]; 代理的時候,開啟或關(guān)閉緩沖后端服務器的響應,當開啟緩沖時,nginx 盡可能快地從被代理的服務器接收響應,再將它存入緩沖區(qū)中。
- proxy_temp_path : 緩存臨時目錄。后端的響應并不直接返回客戶端,而是先寫到一個臨時文件中,然后被 rename 一下當做緩存放在 proxy_cache_path 。0.8.9 版本以后允許 temp和 cache 兩個目錄在不同文件系統(tǒng)上(分區(qū)),然而為了減少性能損失還是建議把它們設成一個文件系統(tǒng)上。
- proxy_cache_path: 設置緩存目錄,目錄里的文件名是 cache_key 的 MD5 值。
- levels=1:2 keys_zone=my-cache:50m 表示采用 2 級目錄結(jié)構(gòu),第一層目錄只有一個字符,是由levels=1:2設置,總共二層目錄,子目錄名字由二個字符組成。Web緩存區(qū)名稱為my-cache,內(nèi)存緩存空間大小為 100MB,這個緩沖 zone 可以被多次使用。文件系統(tǒng)上看到的緩存文件名類似于 /usr/local/nginx1.10/proxy_cache/c/29/b7f54b2df7773722d382f4809d65029c 。
- inactive=600 max_size=2g 表示 600 分鐘沒有被訪問的內(nèi)容自動清除,硬盤最大緩存空間為2GB,超過這個值將清除最近最少使用的數(shù)據(jù)。
- proxy_cache : 引用前面定義的緩存區(qū) my-cache。
- proxy_cache_key :定義如何生成緩存的鍵,設置 web 緩存的 key 值,nginx 根據(jù) key 值 md5哈希存儲緩存。
- proxy_cache_valid : 為不同的響應狀態(tài)碼設置不同的緩存時間,比如 200、302 等正常結(jié)果可以緩存的時間長點,而 404、500 等緩存時間設置短一些,這個時間到了文件就會過期,而不論是否剛被訪問過。
- add_header 指令來設置 response header, 語法: add_header name value。
- $upstream_cache_status 這個變量來顯示緩存的狀態(tài),我們可以在配置中添加一個 http 頭來顯示這一狀態(tài)。
########### $upstream_cache_status 包含以下幾種狀態(tài):############- MISS 未命中,請求被傳送到后端;
- HIT 緩存命中;
- EXPIRED 緩存已經(jīng)過期請求被傳送到后端;
- UPDATING 正在更新緩存,將使用舊的應答;
- STALE 后端將得到過期的應答;
- expires : 在響應頭里設置 Expires:或 Cache-Control:max-age,返回給客戶端的瀏覽器緩存失效時間。
更改配置文件如下(相關(guān)解釋請參考博文末尾):
http {
include mime.types;
default_type application/octet-stream;
brotli on;
brotli_types text/plain text/css text/xml application/xml application/json;
brotli_static off; #是否允許查找預處理好的、以 .br結(jié)尾的壓縮文件,可選值為on、off、always。
brotli_comp_level 11; #壓縮的級別,范圍是“1~14”,值越大,壓縮比越高
brotli_buffers 16 8k; #讀取緩沖區(qū)數(shù)量和大小
brotli_window 512k; #滑動窗口大小
brotli_min_length 20; #指定壓縮數(shù)據(jù)的最小字節(jié)
gzip on; #開啟 gzip 壓縮輸出,減少網(wǎng)絡傳輸。
gzip_comp_level 6; # gzip 壓縮比,1 壓縮比最小處理速度最快,9 壓縮比最大但處理速度最慢(傳輸快但比較消耗 cpu)。
gzip_http_version 1.1; #用于識別 http 協(xié)議的版本,早期的瀏覽器不支持 Gzip 壓縮,用戶就會看到亂碼,所以為了支持前期版本加上了這個選項,如果你用了 Nginx 的反向代理并期望也啟用 Gzip 壓縮的話,由于末端通信是 http/1.1協(xié)議,故請設置為 1.1。
gzip_proxied any; #Nginx 作為反向代理的時候啟用,根據(jù)某些請求和應答來決定是否在對代理請求的應答啟用 gzip 壓縮,是否壓縮取決于請求頭中的“Via”字段,指令中可以同時指定多個不同的參數(shù),意義如下:
# off – 關(guān)閉所有的代理結(jié)果數(shù)據(jù)的壓縮
# 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_min_length 1k;
gzip_buffers 16 8k;
gzip_types text/plain text/css text/javascript application/json application/javascript application/x-javascript application/xml;
gzip_vary on; #和 http 頭有關(guān)系,加個 vary 頭,給代理服務器用的,有的瀏覽器支持壓縮,有的不支持,所以避免浪費不支持的也壓縮,所以根據(jù)客戶端的 HTTP 頭來判斷,是否需要壓縮
client_max_body_size 10m; #允許客戶端請求的最大單文件字節(jié)數(shù)。如果有上傳較大文件,請設置它的限制值
client_body_buffer_size 128k; #緩沖區(qū)代理緩沖用戶端請求的最大字節(jié)數(shù)
server_tokens off; #隱藏 nginx 的版本號
#以下是http_proxy模塊:
proxy_connect_timeout 75; #nginx 跟后端服務器連接超時時間(代理連接超時)
proxy_send_timeout 75;
proxy_read_timeout 75; #定義從后端服務器讀取響應的超時。此超時是指相鄰兩次讀操作之間的最長時間間隔,而不是整個響應傳輸完成的最長時間。如果后端服務器在超時時間段內(nèi)沒有傳輸任何數(shù)據(jù),連接將被關(guān)閉。
proxy_buffer_size 4k; #設置緩沖區(qū)的大小為 size。nginx 從被代理的服務器讀取響應時,使用該緩沖區(qū)保存響應的開始部分。這部分通常包含著一個小小的響應頭。該緩沖區(qū)大小默認等于 proxy_buffers 指令設置的一塊緩沖區(qū)的大小,但它也可以被設置得更小。
proxy_buffers 4 32k; #語法: proxy_buffers the_number is_size;為每個連接設置緩沖區(qū)的數(shù)量為 number,每塊緩沖區(qū)的大小為 size。這些緩沖區(qū)用于保存從被代理的服務器讀取的響應。每塊緩沖區(qū)默認等于一個內(nèi)存頁的大小。這個值是 4K 還是8K,取決于平臺。
#附:[root@nginx ~]# getconf PAGESIZE #查看Linux內(nèi)存頁的大小
#4096
proxy_busy_buffers_size 64k; #高負荷下緩沖大?。J大小是 proxy_buffers 指令設置單塊緩沖大小的 2 倍)
proxy_temp_file_write_size 64k; #當緩存被代理的服務器響應到臨時文件時,這個選項限制每次寫臨時文件的大小。
proxy_buffering on;
proxy_temp_path /usr/local/nginx1.14/proxy_temp;
proxy_cache_path /usr/local/nginx1.14/proxy_cache levels=1:2 keys_zone=my-cache:100m inactive=600m max_size=2g;
upstream backend {
sticky;
server 192.168.20.2:80 weight=1 max_fails=2 fail_timeout=10s;
server 192.168.20.3:80 weight=1 max_fails=2 fail_timeout=10s;
}
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"'
'"$upstream_cache_status"';
access_log logs/access.log main;
sendfile on; #開啟高效文件傳輸模式。
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65; #長連接超時時間,單位是秒,長連接請求大量小文件的時候,可以減少重建連接的開銷,如果設置時間過長,用戶又多,長時間保持連接會占用大量資源。
server {
listen 80;
server_name localhost;
#charset koi8-r;
#access_log logs/host.access.log main;
location ~/purge(/.*) {
allow 127.0.0.1;
allow 192.168.20.0/24;
deny all;
proxy_cache_purge my-cache $host$1$is_args$args;
}
location / {
proxy_pass http://backend; #請求轉(zhuǎn)向 backend 定義的服務器列表,即反向代理,對應 upstream 負載均衡器。也可以proxy_pass http://ip:port。
proxy_redirect off; #指定是否修改被代理服務器返回的響應頭中的 location 頭域跟 refresh 頭域數(shù)值
#例如:
# 設置后端服務器“Location”響應頭和“Refresh”響應頭的替換文本。 假設后端服務器返回的
# 響應頭是 “Location: http://localhost:8000/two/some/uri/”,那么指令proxy_redirect
# http://localhost:8000/two/ http://frontend/one/;將把字符串改寫為 “Location:
# http://frontend/one/some/uri/”。
proxy_set_header Host $host; #允許重新定義或者添加發(fā)往后端服務器的請求頭。
#Host 的含義是表明請求的主機名,nginx 反向代理服務器會向后端真實服務器發(fā)送請求,
#并且請求頭中的host字段重寫為proxy_pass指令設置的服務器。因為nginx作為反向代理使
#用,而如果后端真實的服務器設置有類似防盜鏈或者根據(jù) http 請求頭中的 host 字段來進行
#路由或判斷功能的話,如果反向代理層的nginx不重寫請求頭中的host字段,將會導致請求失敗。
proxy_set_header X-Real-IP $remote_addr;
#web 服務器端獲得用戶的真實 ip 但是,實際上要獲得用戶的真實 ip,也可以通過下面的X-Forward-For
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
#后端的 Web服務器可以通過 X-Forwarded-For 獲取用戶真實 IP,X_Forward_For 字段
#表示該條 http 請求是有誰發(fā)起的?如果反向代理服務器不重寫該請求頭的話,那么后端
#真實服務器在處理時會認為所有的請求都來自反向代理服務器,如果后端有防護策略
#的話,那么機器就被封掉了。因此,在配置用作反向代理的 nginx 中一般會增加兩條配置,以便修改 http 的請求頭部
#以下兩條是修改 http 的請求頭部:
proxy_set_header Host $host;
proxy_set_header X-Forward-For $remote_addr;
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
#增加故障轉(zhuǎn)移,如果后端的服務器返回 502、504、執(zhí)行超時等錯誤,
#自動將請求轉(zhuǎn)發(fā)到upstream 負載均衡池中的另一臺服務器,實現(xiàn)故障轉(zhuǎn)移。
proxy_cache my-cache;
add_header Nginx-Cache $upstream_cache_status;
proxy_cache_valid 200 304 301 302 8h;
proxy_cache_valid 404 1m;
proxy_cache_valid any 1d;
proxy_cache_key $host$uri$is_args$args;
expires 30d;
}
location /nginx_status {
stub_status on;
access_log off;
allow 192.168.31.0/24;
deny all;
}
....................#省略部分內(nèi)容
}
#更改完成后保存退出即可
[root@nginx nginx1.14]# nginx -t #檢查配置文件
nginx: the configuration file /usr/local/nginx1.14/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx1.14/conf/nginx.conf test is successful
[root@nginx nginx1.14]# nginx -s reload #重啟Nginx服務
驗證:
1、訪問以下地址,可以查看Nginx服務器的狀態(tài)統(tǒng)計頁:
2、查看GZIP功能是否開啟:
3、測試br壓縮功能是否開啟(需要使用命令行的方式訪問):
附加:http{ }字段、server{ }字段無注釋的配置文件如下:
http {
include mime.types;
default_type application/octet-stream;
brotli on;
brotli_types text/plain text/css text/xml application/xml application/json;
brotli_static off;
brotli_comp_level 11;
brotli_buffers 16 8k;
brotli_window 512k;
brotli_min_length 20;
gzip on;
gzip_comp_level 6;
gzip_http_version 1.1;
gzip_proxied any;
gzip_min_length 1k;
gzip_buffers 16 8k;
gzip_types text/plain text/css text/javascript application/json application/javascript application/x-javascript application/xml;
gzip_vary on;
client_max_body_size 10m;
client_body_buffer_size 128k;
server_tokens off;
proxy_connect_timeout 75;
proxy_send_timeout 75;
proxy_read_timeout 75;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
proxy_buffering on;
proxy_temp_path /usr/local/nginx1.14/proxy_temp;
proxy_cache_path /usr/local/nginx1.14/proxy_cache levels=1:2 keys_zone=my-cache:100m inactive=600m max_size=2g;
upstream backend {
sticky;
server 192.168.20.2:80 weight=1 max_fails=2 fail_timeout=10s;
server 192.168.20.3:80 weight=1 max_fails=2 fail_timeout=10s;
}
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"'
'"$upstream_cache_status"';
access_log logs/access.log main;
sendfile on;
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65;
#gzip on;
server {
listen 80;
server_name localhost;
#charset koi8-r;
#access_log logs/host.access.log main;
location ~/purge(/.*) {
allow 127.0.0.1;
allow 192.168.20.0/24;
deny all;
proxy_cache_purge my-cache $host$1$is_args$args;
}
location / {
proxy_pass http://backend;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
proxy_cache my-cache;
add_header Nginx-Cache $upstream_cache_status;
proxy_cache_valid 200 304 301 302 8h;
proxy_cache_valid 404 1m;
proxy_cache_valid any 1d;
proxy_cache_key $host$uri$is_args$args;
expires 30d;
}
location /nginx_status {
stub_status on;
access_log off;
allow 192.168.20.0/24;
deny all;
}
location = /50x.html {
root html;
}
}
}
———————— 本文至此結(jié)束,感謝閱讀 ————————