Linux實戰教學筆記37：企業級Nginx Web服務優化實戰（上）

一，Nginx基本安全優化

1.1 調整參數隱藏Nginx軟件版本號信息

• 通常來講，軟件的漏洞都和版本有關，這個很像汽車的缺陷，同一批次的要有問題就都有問題，別的批次可能就都是好的。所以，咱們應儘可能隱藏或消除Web服務對訪問用戶顯示各種敏感信息（例如Web軟件名稱及版本號等信息），這樣惡意的用戶就很難猜到他攻擊的服務器所用的是否有特定漏洞的軟件，或者是否有對應漏洞的某一特定版本，從而增強Web服務的安全性。這在武俠小說裏，就至關於隱身術，你隱身了，對手就很難打着你了。
• 想要隱身，首先要了解所使用軟件的版本號，對於Linux客戶端，可經過命令行查看Nginx版本號，最簡單的方法就是在Linux客戶端系統命令行執行以下curl命令：

[root@LNMP html]# curl -I 192.168.0.220
HTTP/1.1 200 OK
Server: nginx/1.6.2 #這裏清晰的暴露了Web版本號（1.6.2）及軟件名稱（nginx）
Date: Wed, 23 Aug 2017 10:45:47 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
X-Powered-By: PHP/5.3.28
Link: <http://192.168.0.220/wp-json/>; rel="https://api.w.org/"

在Windows客戶端上，經過瀏覽器訪問Web服務時，若找不到頁面，默認報錯的信息以下圖所示：

以上雖然是不一樣的客戶端，可是都得到了Nginx軟件名稱，並且查到了Nginx的版本號，這就使得Nginx Web服務的安全存在必定的風險，所以，應隱藏掉這些敏感信息或用一個其餘的名字將其替代。例如，下面是百度搜索引擎網站Web軟件的改名作法：

[root@LNMP html]# curl -I baidu.com
HTTP/1.1 200 OK
Date: Fri, 25 Aug 2017 12:22:29 GMT
Server: Apache          #將Web服務軟件改名爲了Apache，而且版本號也去掉了
[root@LNMP html]# curl -I -s www.baidu.com 
HTTP/1.1 200 OK
Server: bfe/1.0.8.18        #將Web服務軟件改名爲了bfe，而且版本號改成1.0.8.18(閉源軟件名稱和版本就無所謂了)

門戶網站尚且如此，咱們也學着隱藏或改掉應用服務軟件名和版本號把！事實上，還能夠經過配置文件加參數來隱藏Nginx版本號。編輯nginx.conf配置文件增長參數，實現隱藏Nginx版本號的方式以下：

#在Nginx配置文件nginx.conf中的http標籤段內加入「server_tokens off」

http
{
...............
server_tokens off;
...............
}

此參數放置在http標籤內，做用是控制http response header內的Web服務版本信息的顯示，以及錯誤信息中Web服務版本信息的顯示。

server_tokens參數的官方說明以下：
syntax:     server_tokens on|off;   #此行爲參數語法，on爲開啓狀態，off爲關閉狀態
default:    server_tokens on;       #此行意思是不配置該參數，軟件默認狀況的結果
context:    http,server,location    #此行爲server_tokens參數能夠放置的位置參數做用：激活或禁止Nginx的版本信息顯示在報錯信息和Server的響應首部位置中。

官方資料地址：http://nginx.org/en/docs/http/ngx_http_core_module.html

配置完畢後保存，從新加載配置文件，再次經過curl查看，結果以下：

[root@LNMP nginx]# curl -I 192.168.0.220
HTTP/1.1 200 OK
Server: nginx #版本號已經消失
Date: Wed, 23 Aug 2017 11:22:15 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
X-Powered-By: PHP/5.3.28
Link: <http://192.168.0.220/wp-json/>; rel="https://api.w.org/"

此時，瀏覽器的報錯提示中沒有了版本號，以下圖所示，修改爲功。

1.2 更改源碼隱藏Nginx軟件名及版本號

隱藏了Nginx版本號後，更進一步，能夠經過一些手段把Web服務軟件的名稱也隱藏起來，或者更改成其餘Web服務軟件名以迷惑黑客。但軟件名字的隱藏修改，通常狀況下不會有配置參數和入口，Nginx也不例外，這多是因爲商業及品牌展現等緣由，軟件提供商不但願使用者把軟件名字隱藏起來。所以，此處須要更改Nginx源代碼，具體的解決方法以下：

1.2.1 第一步：依次修改3個Nginx源碼文件。

修改的第一個文件爲nginx-1.6.3/src/core/nginx.h,以下：

[root@LNMP ~]# cd /usr/src/nginx-1.6.2/src/core/
[root@LNMP core]# ls -l nginx.h
-rw-r--r--. 1 1001 1001 351 Sep 16  2014 nginx.h
[root@LNMP core]# sed -n '13,17p' nginx.h
#define NGINX_VERSION "1.6.2" #修改成想要顯示的版本號
#define NGINX_VER "nginx/" NGINX_VERSION
#將nginx修改成想要修改的軟件名稱。
#define NGINX_VAR "NGINX" #將nginx修改成想要修改的軟件名稱
#define NGX_OLDPID_EXT ".oldbin"

修改後的結果以下：

[root@LNMP core]# sed -n '13,17p' nginx.h
#define NGINX_VERSION "0.0.0.0"
#define NGINX_VER "yunjisuan/" NGINX_VERSION
 #define NGINX_VAR "YUNJISUAN"
#define NGX_OLDPID_EXT ".oldbin"

修改的第二個文件是nginx-1.6.3/src/http/ngx_http_header_filter_module.c的第49行，須要修改的字符串內容以下：

ls -l /usr/src/nginx-1.6.2/src/http/ngx_http_header_filter_module.c 
-rw-r--r--. 1 1001 1001 19321 Sep 16  2014 /usr/src/nginx-1.6.2/src/http/ngx_http_header_filter_module.c
[root@LNMP http]# grep -n 'Server: nginx' ngx_http_header_filter_module.c 
49:static char ngx_http_server_string[] = "Server: nginx" CRLF;           #修改本行結尾的nginx

經過sed替換修改，後以下：

[root@LNMP http]# grep -n 'Server: nginx' ngx_http_header_filter_module.c 
49:static char ngx_http_server_string[] = "Server: nginx" CRLF;
[root@LNMP http]# sed -i 's#Server: nginx#Server: yunjisuan#g' ngx_http_header_filter_module.c 
[root@LNMP http]# grep -n 'Server: yunjisuan' ngx_http_header_filter_module.c 
49:static char ngx_http_server_string[] = "Server: yunjisuan" CRLF;

修改的第三個文件是nginx-1.6.3/src/http/nginx_http_special_response.c,對面頁面報錯時，它會控制是否展開敏感信息。這裏輸出修改前的信息ngx_http_special_response.c中的第21~30行，以下：

[root@LNMP http]# sed -n '21,30p' ngx_http_special_response.c 
static u_char ngx_http_error_full_tail[] =
"<hr><center>" NGINX_VER "</center>" CRLF       #此行須要修改
"</body>" CRLF
"</html>" CRLF
;

static u_char ngx_http_error_tail[] =
"<hr><center>nginx</center>" CRLF               #此行須要修改
"</body>" CRLF

修改後的結果以下：

[root@LNMP nginx-1.6.2]# sed -n '21,32p' src/http/ngx_http_special_response.c 
static u_char ngx_http_error_full_tail[] =
"<hr><center>" NGINX_VER " (Mr.chen 2018-08-26)</center>"  CRLF    #此行是定義對外展現的內容
"</body>" CRLF
"</html>" CRLF
;


static u_char ngx_http_error_tail[] =
"<hr><center>yunjisuan</center>" CRLF       #此行將對外展現的Nginx名字更改成yunjisuan
"</body>" CRLF
"</html>" CRLF
;

1.2.2 第二步是修改後編輯軟件，使其生效

修改後再編譯安裝軟件，若是是已經安裝好的服務，須要從新編譯Nginx，配好配置，啓動服務。
再次使瀏覽器出現404錯誤，而後看訪問結果，以下圖所示：

如上面所示：Nginx的軟件和版本名都被改掉了，而且加上了本人的大名。
再看看Linux curl命令響應頭部信息，以下：

[root@LNMP conf]# curl -I localhost/xxx/
HTTP/1.1 404 Not Found
Server: yunjisuan/0.0.0.0 #也更改了
Date: Wed, 23 Aug 2017 15:33:54 GMT
Content-Type: text/html
Content-Length: 196
Connection: keep-alive

1.3 更改Nginx服務的默認用戶

• 爲了讓Web服務更安全，要儘量地改掉軟件默認的全部配置，包括端口，用戶等。
• 下面就來更改Nginx服務的默認用戶
• 首先，查看Nginx服務對應的默認用戶。通常狀況下，Nginx服務啓動後，默認使用的用戶是nobody，查看默認的配置文件，以下：

[root@LNMP conf]# cd /usr/local/nginx/conf/
[root@LNMP conf]# grep "#user" nginx.conf.default
#user nobody;

爲了防止黑客猜到這個Web服務的用戶，咱們須要更改爲特殊的用戶名，例如nginx或特殊點的inca，可是這個用戶必須是系統裏事先存在的，下面以nginx用戶爲例進行說明。

（1）爲Nginx服務創建新用戶

useradd nginx -s /sbin/nologin -M
#不須要有系統登陸權限，應當禁止登錄。

（2）配置Nginx服務，讓其使用剛創建的nginx用戶

更改Nginx服務默認使用用戶，方法有二：

第一種：直接更改配置文件參數，將默認的#user nobody；改成以下內容：

user nginx nginx;

若是註釋或不設置上述參數，默認爲nobody用戶，不推薦使用nobody用戶名，最好採用一個普通用戶，此處用你們習慣的，前面創建好的nginx用戶。

第二種：直接在編譯nginx軟件時指定編譯的用戶和組，命令以下：

./configure --user=nginx --group=nginx --prefix=/usr/local/nginx --with-http_stub_status_module --with-http_ssl_module

#提示：
#前文在編譯Nginx服務時，就是這樣帶着參數的，所以不管配置文件中是否加參數，默認都是nginx用戶。

（3）檢查更改用戶的效果

從新加載配置後，檢查Nginx服務進程的對應用戶，以下：

[root@LNMP conf]# ps -ef | grep nginx | grep -v grep
root      52023      1  0 11:30 ?        00:00:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx     52024  52023  0 11:30 ?        00:00:00 nginx: worker process

經過查看上述更改後的Nginx進程，能夠看到worker processes進程對應的用戶都變成了nginx。因此，咱們有理由得出結論，上述的兩種方法均可設置Nginx的worker進程運行的用戶。固然，Nginx的主進程仍是以root身份運行的。

二，根據參數優化Nginx服務性能

2.1 優化Nginx服務的worker進程個數

• 在高併發，高訪問量的Web服務場景，須要事先啓動好更多的Nginx進程，以保證快速響應並處理大量併發用戶的請求。
• 這相似於開飯店，在營業前，須要事先招聘必定數量的服務員準備接待顧客，但這裏就有一個問題，若是飯店對客流沒有正確預估，就會致使一些問題發生，例如：服務員人數招聘多了，可是客流不多，那麼服務員就可能很閒，沒事幹，飯店的成本也高了；若是客流很大，而服務員人數少了，可能就接待不過來顧客，致使顧客吃飯體驗差。所以，飯店要根據客戶的流量及併發量來調整接待的服務人員數量，而後根據檢測顧客量變化及時調整到最佳配置。
• Nginx服務就至關於飯店，網站用戶就至關於顧客，Nginx的進程就至關於服務員，下面就來優化Nginx進程的個數。

2.1.1 優化Nginx進程對應的配置

#優化Nginx進程對應Nginx服務的配置參數以下：
worker_processes 1;     #指定了Nginx要開啓的進程數，結尾數字就是進程個數

上述參數調整的是Nginx服務的worker進程數，Nginx有Master進程和worker進程之分，Master爲管理進程，真正接待「顧客」的是worker進程。

2.1.2 優化Nginx進程個數的策略

• 前面已經講解過，worker_processes參數大小的設置最好和網站的用戶數量相關聯，可若是是新配置，不知道網站的用戶數量該怎麼辦呢？
• 搭建服務器時，worker進程數最開始的設置能夠等於CPU的核數，且worker進程數要多一些，這樣起始提供服務時就不會出現由於訪問量快速增長而臨時啓動新進程提供服務的問題，縮短了系統的瞬時開銷和提供服務的時間，提高了服務用戶的速度。高流量高併發場合也能夠考慮將進程數提升至CPU核數*2，具體狀況要根據實際的業務來選擇，由於這個參數除了要和CPU核數匹配外，也和硬盤存儲的數據及系統的負載有關，設置爲CPU的核數是一個好的起始配置，這也是官方的建議。

2.1.3 查看Web服務器CPU硬件資源信息

下面介紹查看Linux服務器CPU總核數的方法：

（1）經過/proc/cpuinfo可查看CPU個數及總核數。查看CPU總核數的示例以下：

[root@LNMP ~]# grep processor /proc/cpuinfo 
processor   : 0
processor   : 1
processor   : 2
processor   : 3
[root@LNMP ~]# grep processor /proc/cpuinfo | wc -l
4               #表示爲1顆CPU四核
[root@LNMP ~]# grep -c processor /proc/cpuinfo
4               #表示爲1顆CPU四核

#查看CPU總顆數示例以下：
[root@LNMP ~]# grep "physical id" /proc/cpuinfo 
physical id : 0     #物理ID一致，同一顆CPU
physical id : 0     #物理ID一致，同一顆CPU
physical id : 0     #物理ID一致，同一顆CPU
physical id : 0     #物理ID一致，同一顆CPU
[root@LNMP ~]# grep "physical id" /proc/cpuinfo | sort | uniq | wc -l
1               #去重複，表示1顆CPU

（2）經過執行top命令，而後按數字1，便可顯示全部的CPU核數，以下：

2.1.4 實踐修改Nginx配置

假設服務器的CPU顆數爲1顆，核數爲4核，則初始的配置可經過查看默認的nginx.conf裏的worker_processes數來了解，命令以下:

[root@LNMP ~]# grep worker_processes /usr/local/nginx/conf/nginx.conf
worker_processes  1;
[root@LNMP ~]# sed -i 's#worker_processes 1#worker_processes 4#' /usr/local/nginx/conf/nginx.conf
[root@LNMP ~]# grep worker_processes /usr/local/nginx/conf/nginx.conf
worker_processes  4;        #提示能夠經過vi修改

#優雅重啓Nginx，使修改生效，以下：
[root@LNMP ~]# /usr/local/nginx/sbin/nginx -t
nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful
[root@LNMP ~]# /usr/local/nginx/sbin/nginx -s reload

#如今檢查修改後的worker進程數量，以下：
[root@LNMP ~]# ps -ef | grep "nginx" | grep -v grep
root       1110      1  0 11:12 ?        00:00:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx      1429   1110  0 11:33 ?        00:00:00 nginx: worker process      
nginx      1430   1110  0 11:33 ?        00:00:00 nginx: worker process      
nginx      1431   1110  0 11:33 ?        00:00:00 nginx: worker process      
nginx      1432   1110  0 11:33 ?        00:00:00 nginx: worker process

從「worker_processes 4」可知，worker進程數爲4個。Nginx Master主進程不包含在這個參數內，Nginx Master的主進程爲管理進程，負責調度和管理worker進程。

有關worker_processes參數的官方說明以下：

syntax:         worker_processes number;    #此行爲參數語法，number爲數量
default:        worker_processes 1;     #此行意思是不匹配該參數，軟件默認狀況數量爲1
context:        main;   #此行爲worker_processes參數能夠放置的位置

worker_processes爲定義worker進程數的數量，建議設置爲CPU的核數或CPU核數*2，具體狀況要根據實際的業務來選擇，由於這個參數，除了要和CPU核數匹配外，和硬盤存儲的數據以系統的負載也有關，設置爲CPU的個數或核數是一個好的起始配置。From：http://nginx.org/en/docs/ngx_core_module.html

2.2 優化綁定不一樣的Nginx進程到不一樣的CPU上

• 默認狀況下，Nginx的多個進程有可能跑在某一個CPU或CPU的某一核上，致使Nginx進程使用硬件的資源不均，本節的優化是儘量地分配不一樣的Nginx進程給不一樣的CPU處理，達到充分有效利用硬件的多CPU多核資源的目的。
• 在優化不一樣的Nginx進程對應不一樣的CPU配置時，四核CPU服務器的參數配置參考以下：

worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;

#worker_cpu_affinity就是配置Nginx進程與CPU親和力的參數，即把不一樣的進程分給不一樣的CPU處理。這裏0001 0010 0100 1000是掩碼，分別表明第1，2，3，4核CPU，因爲worker_processes進程數爲4，所以，上述配置會把每一個進程分配一核CPU處理，默認狀況下進程不會綁定任何CPU，參數位置爲main段。

四核和八核CPU服務器的參數配置參考以下：

#八核掩碼
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000；
 #四核掩碼
worker_cpu_affinity 0001 0010 0100 1000；

worker_cpu_affinity 的做用是綁定不一樣的worker進程數到一組CPU上。經過設置bitmask控制進程容許使用的CPU，默認worker進程不會綁定到任何CPU（自動平均分配。）

2.2.1 實驗環境準備

主機名	IP地址	備註
Nginx	192.168.0.220	nginxWeb
測試機1	192.168.0.240	Webbench壓力測試
測試機2	192.168.0.245	Webbench壓力測試

#安裝webbench
tar xf webbench-1.5.tar.gz 
cd webbench-1.5
mkdir /usr/local/man
make install clean
which webbench.

虛擬機開啓4核心

2.2.2 第一步：不綁定worker進程進行壓力測試

#配置文件以下：（未綁定worker進程）
[root@LNMP nginx]# cat conf/nginx.conf
worker_processes  4;
#worker_cpu_affinity 0001 0010 0100 1000;
events {
    worker_connections  10240;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    server {
        listen       80;
        server_name  bbs.yunjisuan.com;
        location / {
            root   html;
            index  index.html index.htm;
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }
}

#在NginxWeb上執行以下命令：
[root@LNMP nginx]# top -u nginx
Tasks: 120 total, 1 running, 119 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.2%sy, 0.0%ni, 99.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1004412k total, 911632k used, 92780k free, 6952k buffers
Swap: 2031608k total, 0k used, 2031608k free, 749976k cached

   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                 
  1454 nginx     20   0 49240 5640  468 S  0.0  0.6   0:00.00 nginx                                                                                    
  1455 nginx     20   0 49240 5672  500 S  0.0  0.6   0:00.00 nginx                                                                                    
  1456 nginx     20   0 49240 5672  500 S  0.0  0.6   0:00.00 nginx                                                                                    
  1457 nginx     20   0 49240 5672  500 S  0.0  0.6   0:00.00 nginx  
  

#在以上界面時按鍵盤的數值1鍵，出現以下界面：
top - 14:44:46 up 36 min,  1 user,  load average: 0.00, 0.00, 0.00
Tasks: 120 total, 1 running, 119 sleeping, 0 stopped, 0 zombie
Cpu0  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem: 1004412k total, 911384k used, 93028k free, 6960k buffers
Swap: 2031608k total, 0k used, 2031608k free, 749976k cached

   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                 
  1454 nginx     20   0 49240 5640  468 S  0.0  0.6   0:00.00 nginx                                                                                    
  1455 nginx     20   0 49240 5672  500 S  0.0  0.6   0:00.00 nginx                                                                                    
  1456 nginx     20   0 49240 5672  500 S  0.0  0.6   0:00.00 nginx                                                                                    
  1457 nginx     20   0 49240 5672  500 S  0.0  0.6   0:00.00 nginx

在另外的兩臺測試機器上同時進行壓力測試，命令以下：
webbench -c 2000 -t 60 http://192.168.0.220/

結果以下：

2.2.3 第二步：綁定worker進程進行壓力測試

#配置文件以下（綁定worker進程）
[root@LNMP nginx]# cat conf/nginx.conf
worker_processes  4;
worker_cpu_affinity 0001 0010 0100 1000;    #修改本行
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    server {
        listen       80;
        server_name  bbs.yunjisuan.com;
        location / {
            root   html;
            index  index.html index.htm;
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html { root html; } } }

在另外的兩臺測試機器上同時進行壓力測試，命令以下：
webbench -c 2000 -t 60 http://192.168.0.220/

結果以下：

根據圖示，咱們基本能夠看出，平均綁定worker進程和不綁定的實驗效果基本是一致的（CPU0是默認會被使用的）。緣由在nginx在通過不斷的優化後，會自動對worker進程進行動態的平均分配。

2.2.4 第三步：修改nginx配置，將全部worker進程綁定到CPU3上

#配置文件以下所示：
[root@LNMP nginx]# cat conf/nginx.conf
worker_processes  4;
worker_cpu_affinity 1000 1000 1000 1000;    #修改本行
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    server {
        listen       80;
        server_name  bbs.yunjisuan.com;
        location / {
            root   html;
            index  index.html index.htm;
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html { root html; } } }

在另外的兩臺測試機器上同時進行壓力測試，命令以下：
webbench -c 2000 -t 60 http://192.168.0.220/

結果以下：

從上圖咱們能夠得知，worker進程的壓力被集中分配到了CPU3上。（CPU0是默認被使用的）

2.3 Nginx事件處理模型優化

• Nginx的鏈接處理機制在不一樣的操做系統會採用不一樣的額I/O模型，在Linux下，Nginx使用epoll的I/O多路複用模型，在Freebsd中使用kqueue的I/O多路複用模型，在Solaris中使用/dev/poll方式的I/O多路複用模型，在Windows中使用的是icop，等等。
• 要根據系統類型選擇不一樣的事件處理模型，可供使用的選擇有「use [kqueue|rtsig|epoll|/dev/poll|select|poll];」。由於教學使用的是CentOS 6.5 Linux，所以將Nginx的事件處理模型調整爲epoll模型。

#具體的配置參數以下：
events      #events指令是設定Nginx的工做模式及鏈接數上限
{
    use epoll；     #use是一個事件模塊指令，用來指定Nginx的工做模式。Nginx支持的工做模式有select，poll，kqueue，epoll，rtsig和/dev/poll。其中select和poll都是標準的工做模式，kqueue和epoll是高效的工做模式，不一樣的是epoll用在Linux平臺上，而kqueue用在BSD系統中。對於Linux系統Linux2.6+內核，推薦選擇epoll工做模式，這是高性能高併發的設置
}

根據Nginx官方文檔建議，也能夠不指定事件處理模型，Nginx會自動選擇最佳的事件處理模型服務。
對於使用鏈接進程的方法，一般不須要進行任何設置，Nginx會自動選擇最有效辦法。

2.4 調整Nginx單個進程容許的客戶端最大鏈接數

接下來，調整Nginx單個進程容許的客戶端最大鏈接數，這個控制鏈接數的參數爲work_connections。
worker_connections的值要根據具體服務器性能和程序的內存使用量來指定（一個進程啓動使用的內存根據程序肯定），以下：

events  #events指令是設定Nginx的工做模式和鏈接數上線
{
    worker_connections 20480;
    #worker_connections也是個事件模塊指令，用於定義Nginx每一個進程的最大鏈接數，默認是1024.最大客戶端鏈接數由worker_processes和worker_connections決定，即Max_client= worker_processes*worker_connections。進程的最大鏈接數受Linux系統進程的最大打開文件數限制，在執行操做系統命令「ulimit -HSn 65535」或配置相應文件後，worker_connections的設置才能生效。
}

下面是worker_connections的官方說明

參數語法：worker_connections number
默認配置：worker_connections 512
放置位置：events

說明：

worker_connections用來設置一個worker process支持的最大併發鏈接數，這個鏈接數包括了全部連接，例如：代理服務器的鏈接，客戶端的鏈接等，實際的併發鏈接數除了受worker_connections參數控制外，還和最大打開文件數worker_rlimit_nofile有關(見下文)，Nginx總併發鏈接=worker數量*worker_connections。
參考資料：http://nginx.org/en/docs/ngx_core_module.html

2.5 配置Nginx worker進程最大打開文件數

接下來，調整配置Nginx worker進程的最大打開文件數，這個控制鏈接數的參數爲worker_rlimit_nofile。該參數的實際配置以下：

worker_rlimit_nofile 65535;
#最大打開文件數，可設置爲系統優化後的ulimit -HSn的結果

下面是worker_rlimit_nofile number的官方說明：

參數語法：worker_rlimit_nofile number
默認配置：無
放置位置：主標籤段

說明：此參數的做用是改變worker processes能打開的最大文件數
參考資料：http://nginx.org/en/docs/ngx_core_module.html

備註：
Linux系統文件最大打開數設置：ulimit -n 65535

2.5.1 實驗環境準備

主機名	IP地址	備註
Nginx	192.168.0.220	nginxWeb
測試機1	192.168.0.240	Webbench壓力測試
測試機2	192.168.0.245	Webbench壓力測試

2.5.2 修改nginx.conf配置文件

[root@LNMP nginx]# cat conf/nginx.conf
worker_processes  1;
#worker_cpu_affinity 0000 0010 0100 1000;
#worker_rlimit_nofile 65535;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    server {
        listen       80;
        server_name  bbs.yunjisuan.com;
        location / {
            root   html;
            index  index.html index.htm;
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html { root html; } } }

先定1核1024鏈接數。同窗們注意多開幾個虛擬機進行壓力測試。否則的話，web服務器還沒出問題，你測試服務器先down掉了。

2.5.2 測試nginx服務鏈接數的極值

#使用這個命令能夠抓取nginx的鏈接數
[root@LNMP nginx]# netstat -antp | grep nginx | wc -l
554
[root@LNMP nginx]# netstat -antp | grep nginx | wc -l
471

逐漸提升壓力，抓鏈接數，看看nginx啥時候down

2.6 開啓高效文件傳輸模式

（1）設置參數：sendfile on;

sendfile參數用於開啓文件的高效傳輸模式。同時將tcp_nopush和tcp_nodelay兩個指令設置爲on，可防止網絡及磁盤I/O阻塞，提高Nginx工做效率。

#sendfile參數的官方說明以下：
syntax:     sendfile on | off;   #參數語法
default:    sendfile off;        #參數默認大小
context:    http,server,location,if in location #能夠放置的標籤段

參數做用：
激活或禁用sendfile()功能功能。sendfile()是做用於兩個文件描述符之間的數據拷貝函數，這個拷貝操做是在內核之中的，被稱爲「零拷貝」，sendfile()比read和write函數要高效不少，由於，read和write函數要把數據拷貝到應用層再進行操做。相關控制參數還有sendfile_max_chunk,同窗們能夠執行查詢。細節見http://nginx.org/en/docs/http/ngx_http_core_module.html#sendfile

（2）設置參數：tcp_nopush on;

#tcp_nopush參數的官方說明以下：
syntax:     tcp_nopush on | off;    #參數語法
default:    tcp_nopush off;         #參數默認大小
context:    http,server,location    #能夠放置的標籤段

參數做用：
激活或禁用Linux上的TCP_CORK socket選項，此選項僅僅當開啓sendfile時才生效，激活這個tcp_nopush參數能夠容許把http response header和文件的開始部分放在一個文件裏發佈，其積極的做用是減小網絡報文段的數量。細節見http://nginx.org/en/docs/http/ngx_http_core_module.html。

2.7 優化Nginx鏈接參數，調整鏈接超時時間

2.7.1 什麼是鏈接超時

• 先來個比喻吧，某飯店請了服務員招待顧客，可是如今飯店不景氣，此時，爲多餘的服務員發工資使得成本被提升，想減小飯店開支成本就得解僱服務員。
• 這裏的服務員就至關於Nginx服務創建的鏈接，當服務器創建的鏈接沒有接收處理請求時，可在指定的時間內就讓它超時自動退出。還有當Nginx和FastCGI服務創建鏈接請求PHP時，若是由於一些緣由（負載高，中止響應），FastCGI服務沒法給Nginx返回數據，此時能夠經過配置Nginx服務參數使其不會死等，由於前面用過戶還等着它返回數據呢，例如，可設置爲若是請求FastCGI 10秒內不能返回數據，那麼Nginx就中斷本次請求，向用戶彙報取不到數據的錯誤。

2.7.2 鏈接超時的做用

• 將無用的鏈接設置爲儘快超時，能夠保護服務器的系統資源（CPU，內存，磁盤）。
• 當鏈接不少時，及時斷掉那些已經創建好的但又長時間不作事的鏈接，以減小其佔用的服務器資源，由於服務器維護鏈接也是消耗資源的。
• 有時黑客或惡意用戶攻擊網站，就會不斷地和服務器創建多個鏈接，消耗鏈接數，可是啥也不幹，大量消耗服務器的資源，此時就應該及時斷掉這些惡意佔用資源的鏈接。
• LNMP環境中，若是用戶請求了動態服務，則Nginx就會創建鏈接，請求FastCGI服務以及後端MySQL服務，此時這個Nginx鏈接就要設定一個超時時間，在用戶容忍的時間內返回數據，或者再多等一下子後端服務返回數據，具體的策略要根據具體業務進行具體分析。固然了，後端的FastCGI服務及MySQL服務也有對鏈接的超時控制。

簡單的說，鏈接超時是服務的一種自我管理，自我保護的重要機制。

2.7.3 鏈接超時帶來的問題，以及不一樣程序鏈接設定知識

• 服務器創建新鏈接也是要消耗資源的，所以，超時設置得過短而併發很大，就會致使服務器瞬間沒法響應用戶的請求，致使用戶體驗降低。
• 企業生產有些PHP程序站點會但願設置成短鏈接，由於PHP程序創建鏈接消耗的資源和時間相對要少些。而對於Java程序站點來講，通常建議設置長鏈接，由於Java程序創建鏈接消耗的資源和時間更多，這是語言運行機制決定的。

2.7.4 Nginx鏈接超時的參數設置

（1）設置參數：keepalive_timeout 60;

用於設置客戶端鏈接保持會話的超時時間爲60秒。超過這個時間，服務器會關閉該鏈接，此數值爲參考值。

keepalive_timeout參數的官方說明以下：
syntax: keepalive_timeout  timeout [header_timeout] #參數語法
default: keepalive_timeout 75s;     #參數默認大小
context: http,serverr,location      #能夠放置的標籤段

參數做用：

• keep-alive可使客戶端到服務器端已經創建的鏈接一直工做不退出，當服務器有持續請求時，keep-alive會使用已經創建的鏈接提供服務，從而避免服務器從新創建新鏈接處理請求。
• 此參數設置一個keep-alive(客戶端鏈接在服務器端保持多久後退出)，其單位是秒，和HTTP響應header域的「Keep-Alive:timeout=time」參數有關，這些header信息也會被客戶端瀏覽器識別並處理，不過有些客戶端並不能按照服務器端的設置來處理，例如：MSIE大約60秒後會關閉keep-alive鏈接。細節見：http://nginx.org/en/docs/http/ngx_http_core_module.html

（2）設置參數：tcp_nodelay on;

用於激活tcp_ondelay功能，提升I/O性能。

#tcp_nodelay參數的官方說明以下：
syntax:     tcp_nodelay on | off    #參數語法
default:    tcp_nodelay on;         #參數默認大小
context:    http,server,location    #能夠放置的標籤段

參數做用：
默認狀況下當數據發送時，內核並不會立刻發送，可能會等待更多的字節組成一個數據包，這樣能夠提升I/O性能。可是，在每次只發送不多字節的業務場景中，使用tcp_nodelay功能，等待時間會比較長。
參數生效條件：
激活或禁用TCP_NODELAY選項，當一個鏈接進入keep-alive狀態時生效。細節見http://nginx.org/en/docs/http/ngx_http_core_module.html。

（3）設置參數：client_header_timeout 15;

用於設置讀取客戶端請求頭數據的超時時間。此處的數值15，其單位是秒，爲經驗參考值。

#client_header_timeout參數的官方說明以下：
syntax:     client_header_timeout time; #參數語法
default:    client_header_timeout 60s;  #參數默認大小
context:    http,server         #能夠放置的標籤段

參數做用：
設置讀取客戶端請求頭數據的超時時間。若是超過這個時間，客戶端尚未發送完整的header數據，服務器端將返回「Request time out (408)」錯誤，可指定一個超時時間，防止客戶端利用http協議進行攻擊。細節見：http://nginx.org/en/docs/http/ngx_http_core_module.html。

（4）設置參數：client_body_timeout 15;

用於設置讀取客戶端請求主體的超時時間，默認值60

#client_body_timeout參數的官方說明以下：
syntax:     client_body_timeout time;   #參數語法
default:    client_body_timeout 60s;    #默認60
context:    http,server,location    #能夠放置的標籤段

參數做用：
設置讀取客戶端請求主體的超時時間。這個超時僅僅爲兩次成功的讀取操做之間的一個超時，非請求整個主體數據的超時時間，若是在這個超時時間內，客戶端沒有發送任何數據，Nginx將返回「Request time out(408)」錯誤，默認值60，細節見:http://nginx.org/en/docs/http/ngx_http_core_module.html

（5）設置參數：send_timeout 25;

用於指定響應客戶端的超時時間。這個超時僅限於兩個鏈接活動之間的時間，若是超過這個時間，客戶端沒有任何活動，Nginx將會關閉鏈接，默認值爲60秒，能夠改成參考值25秒。

#send_timeout參數的官方說明以下：
syntax:     send_timeout    time;   #參數語法
default:    send_timeout    60s;    #默認值60
context:    http,server,location    #能夠放置的標籤段

參數做用：
設置服務器端傳送HTTP響應信息到客戶端的超時時間，這個超時僅僅爲兩次成功握手後的一個超時，非請求整個響應數據的超時時間，如在這個超時時間內，客戶端沒有接收任何數據，鏈接將被關閉。細節見http://nginx.org/en/docs/http/ngx_http_module.html。

備註：結合http原理畫圖講解超時參數

2.8 上傳文件大小的限制（動態應用）

下面咱們學習如何調整上傳文件的大小（http Request body size）限制。

#首先，咱們能夠在Nginx主配置文件里加入以下參數：
client_max_body_size 8m;

#具體大小根據公司的業務作調整，若是不清楚就先設置爲8m把，有關客戶端請求主體的解釋在HTTP原理一節已經解釋過了，通常狀況下，HTTP的post方法在提交數據時纔會攜帶請求主體信息。
#client_max_body_size參數的官方說明以下：
syntax:     client_max_body_size size;  #參數語法
default:    client_max_body_size 1m;    #默認值1m
context：   http,server,location        #能夠放置的1標籤段

參數做用：
設置最大的容許的客戶端請求主體大小，在請求頭域有「Content-Length」，若是超過了此配置值，客戶端會受到413錯誤，意思是請求的條目過大，有可能瀏覽器不能正確顯示。設置爲0表示禁止檢查客戶端請求主體大小。此參數對提升服務器端的安全性有必定做用。細節見http://nginx.org/en/docs/http/ngx_http_core_module.html

2.9 FastCGI相關參數調優（配合PHP引擎動態服務）

FastCGI參數是配合Nginx向後請求PHP動態引擎服務的相關參數。Nginx FastCGI工做的邏輯圖以下圖所示：

此處講解的參數均爲Nginx FastCGI客戶端向後請求PHP動態引擎服務（php-fpm（FastCGI服務器端））的相關參數，屬於Nginx的配置參數。下表是Nginx FastCGi常見參數的說明。

FastCGI Cache資料見http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_cache。

FastCGI常見參數的Nginx配置示例以下：

[root@LNMP nginx]# cat /usr/local/nginx/conf/nginx.conf
worker_processes  4;
worker_cpu_affinity 0001 0010 0100 1000;
worker_rlimit_nofile 65535;
user nginx;
events {
    use epoll;
    worker_connections  10240;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    tcp_nopush      on;
    keepalive_timeout  65;
    tcp_nodelay     on;
    client_header_timeout 15;
    client_body_timeout   15;
    send_timeout          15;
    log_format main '$remote_addr - $remote_user [$time_local] "$request"'
    '$status $body_bytes_sent "$http_referer"'
    '"$http_user_agent""$http_x_forwarded_for"';
    server_tokens off;
    fastcgi_connect_timeout 240;        #Nginx容許fcgi鏈接超時時間
    fastcgi_send_timeout 240;           #Nginx容許fcgi返回數據的超時時間
    fastcgi_read_timeout 240;           #Nginx讀取fcgi響應信息的超時時間
    fastcgi_buffer_size 64k;            #Nginx讀取響應信息的緩衝區大小
    fastcgi_buffers 4 64k;              #指定Nginx緩衝區的數量和大小
    fastcgi_busy_buffers_size 128k;     #當系統繁忙時buffer的大小
    fastcgi_temp_file_write_size 128k;  #Nginx臨時文件的大小
# fastcgi_temp_path /data/ngx_fcgi_tmp; #指定Nginx臨時文件放置路徑
    fastcgi_cache_path  /data/ngx_fcgi_cache    levels=2:2  keys_zone=ngx_fcgi_cache:512m   inactive=1d;    #指定Nginx緩存放置路徑
    
# web

    server {
        listen       80;
        server_name  www.yunjisuan.com;
    location / {
        root html;
        index index.php index.html index.htm;
        if (-f $request_filename/index.html){
            rewrite (.*) $1/index.html break;
        }
        if (-f $request_filename/index.php){
            rewrite (.*) $1/index.php;
        }
        if (!-f $request_filename){
            rewrite (.*) /index.php;
        }
    }
    access_log  logs/web_www_access.log     main;
        location ~ .*\.(php|php5)?$ {
                root   html;
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
        include fastcgi.conf;
        fastcgi_cache ngx_fcgi_cache;       #開啓fcgi緩存並起名叫ngx_fcgi_cache,很重要，有效下降CPU負載，而且防止502錯誤發生。
        fastcgi_cache_valid 200 302 1h; #指定應答代碼的緩存時間，1h=1小時
        fastcgi_cache_valid 301 1d;     #1d=1天
        fastcgi_cache_valid any 1m;     #and 1m：將其餘應答緩存1分鐘
        fastcgi_cache_min_uses 1;       #待緩存內容至少要被用戶請求過1次
        fastcgi_cache_use_stale error timeout invalid_header http_500;  #當遇到error，timeout，或者返回碼500時，啓用過時緩存返回用戶（返回過時也比返回錯誤強）
# fastcgi_cache_key http://$host$request_uri; 
        
        }
    }
    upstream    www_yunjisuan {

    server 192.168.0.225:8000 weight=1;

    }
    server {
        
    listen 8000;
    server_name www.yunjisuan.com;
    location / {
# root html;
        proxy_pass      http://www_yunjisuan;
        proxy_set_header    host    $host;
        proxy_set_header    x-forwarded-for $remote_addr;

    }
    access_log  logs/proxy_www_access.log   main;
    }
}

Nginx的FastCGI的相關參數和反向代理proxy的相關參數很是接近，同窗們能夠拿來比對，一塊兒理解。

2.10 配置Nginx gzip壓縮實現性能優化

2.10.1 Nginx gzip壓縮功能介紹

Nginx gzip壓縮模塊提供了壓縮文件內容的功能，用戶請求的內容在發送到用戶客戶端以前，Nginx服務器會根據一些具體的策略實施壓縮，以節約網站出口帶寬，同時加快數據傳輸效率，來提高用戶訪問體驗。

2.10.2 Nginx gzip壓縮的優勢

• 提高網站用戶體驗：發送給用戶的內容小了，用戶訪問單位大小的頁面就加快了，用戶體驗提高了，網站口碑就行了。
• 節約網站帶寬成本：數據是壓縮傳輸的，所以節省了網站的帶寬流量成本，不過壓縮時會稍微消耗一些CPU資源，這個通常能夠忽略。

此功能既能提高用戶體驗，又能使公司少花錢，一舉多得。對於幾乎全部的Web服務來講，這是一個很是重要的功能，Apache服務也有此功能。

2.10.3 須要和不須要壓縮的對象

• 純文本內容壓縮比很高，所以，純文本的內容最好進行壓縮，例如：html，js，css，xml，shtml等格式的文件。
• 被壓縮的純文本文件必需要大於1KB，因爲壓縮算法的特殊緣由，極小的文件壓縮後可能反而變大。
• 圖片，視頻（流媒體）等文件儘可能不要壓縮，由於這些文件大多都是通過壓縮的，若是再壓縮極可能不會減小或減小不多，或者有可能增大，同時壓縮時還會消耗大量的CPU，內存資源。

2.10.4 參數介紹及配置說明

此壓縮功能與早期Apache服務的mod_deflate壓縮功能很類似，Nginx的gzip壓縮功能依賴於ngx_http_gzip_module模塊，默認已安裝。

對應的壓縮參數說明以下：

#######壓縮的配置介紹######
gzip on；
#開啓gzip壓縮功能
gzip_min_length 1k;
#設置容許壓縮的頁面最小字節數，頁面字節數從header頭的Content-Length中獲取。默認值0，表示無論頁面多大都進行壓縮。建議設置成大於1K，若是小於1K可能會越壓越大。
gzip_buffers 4 16K;
#壓縮緩衝區大小。表示申請4個單位爲16K的內存做爲壓縮結果流緩存，默認值是申請與原始數據大小相同的內存空間來存儲gzip壓縮結果。
gzip_http_version 1.1;
#壓縮版本（默認1.1，前端爲squid2.5時使用1.0），用於設置識別HTTP協議版本，默認是1.1，目前大部分瀏覽器已經支持GZIP解壓，使用默認便可。
gzip_comp_level 2;
#壓縮比率。用來指定gzip壓縮比，1壓縮比最小，處理速度最快；9壓縮比最大，傳輸速度快，但處理最慢，也比較消耗CPU資源。
gzip_types text/plain application/x-javascript text/css application/xml;
#用來指定壓縮的類型，「text/html」類型老是會被壓縮，這個就是HTTP原理部分講的媒體類型。
gzip_vary on;
#vary header支持。該選項可讓前端的緩存服務器緩存通過gzip壓縮的頁面，例如用Squid緩存通過Nginx壓縮的數據。

不一樣的Nginx版本中，gzip_types的配置可能會有不一樣，上述配置示例適合Nginx 1.6.3。對應的文件類型，請查看安裝目錄下的mime.types文件。

更多官方資源請看http://nginx.org/en/docs/http/ngx_http_gzip_module.html

2.10.5 Nginx壓縮配置效果檢查

可經過火狐瀏覽器+firebug插件+yslow插件查看gzip壓縮及expires緩存結果。提早安裝好yslow插件，開啓監控，而後打開LNMP時安裝的博客地址，就能夠看到以下圖所示的壓縮結果：

2.10.6 重要的前端網站調試工具介紹

常見的前端網站調試工具備以下幾種：

• Google瀏覽器（Chrome）：經過該瀏覽器直接按F12鍵便可查看壓縮及緩存結果，另外，谷歌瀏覽器（Chrome）上也能夠直接安裝yslow插件
• 火狐瀏覽器：在該瀏覽器上安裝firebug，yslow，便可進行調試（火狐要用老版本好比V28）
• IE瀏覽器：在該瀏覽器上安裝httpwatch便可進行調試（省略）

2.11 配置Nginx expires緩存實現性能優化

2.11.1 Nginx expires功能介紹

• 簡單說，Nginx expires的功能就是爲用戶訪問的網站內容設定一個過時時間，當用戶第一次訪問這些內容時，會把這些內容存儲在用戶瀏覽器本地，這樣用戶第二次及之後繼續訪問該網站時，瀏覽器會檢查加載已經緩存在用戶瀏覽器本地的內容，就不會去服務器下載了，直到緩存的內容過時或被清除位置。
• 更深刻的理解：expires的功能就是容許經過Nginx配置文件控制HTTP的「Expires」和「Cache-Control」響應頭部內容，告訴客戶端瀏覽器是否緩存和緩存多久之內訪問的內容。這個expires模塊控制Nginx服務器應答時的expires頭內容和Cache-Control頭的max-age指令。緩存的有效期能夠設置爲相對於源文件的最後修改時刻或客戶端的訪問時刻。
• 這些HTTP頭向客戶端代表了額內容的有效性和持久性。若是客戶端本地有內容緩存，則內容就能夠從緩存而不是從服務器中讀取，而後客戶端會檢查緩存中的副本，看其是否過時或失效，以決定是否從新從服務器得到內容更新。

2.11.2 Nginx expires做用介紹

在網站的開發和運營中，視頻，圖片，CSS，JS等網站元素的更改機會較少，特別是圖片，這時能夠將圖片設置在客戶瀏覽器本地緩存365天或3650天，而將CSS，JS，html等代碼緩存10~30天。這樣用戶第一次打開頁面後，會在本地的瀏覽器按照過時日期緩存相應的內容，下次用戶再打開相似的頁面時，重複的元素就無需下載了，從而加快用戶訪問速度。用戶的訪問請求和數據減小了，也可節省大量的服務器端帶寬。此功能同Apache的expires功能相似。

2.11.3 Nginx expires功能優勢

• expires能夠下降網站的帶寬，節約成本。
• 加快用戶訪問網站的速度，提高用戶訪問體驗。
• 服務器訪問量下降了，服務器壓力就減輕了，服務器成本也會下降，甚至能夠節約人力成本。
• 對於幾乎全部的Web服務來講，這是很是重要的功能之一，Apache服務也有此功能。

2.11.4 Nginx expires配置詳解

前面已經介紹了expires的功能原理，接下來就來配置Nginx expires的功能。這裏以location標籤爲例進行講解，經過location URI規則將須要緩存的擴展名列出來，而後指定緩存時間。若是針對全部內容設置緩存，也能夠不用location。Nginx默認安裝了expires功能。

（1）根據文件擴展名進行判斷，添加expires功能範例

範例1：

location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
{
    expires 3650d;
}

該範例的意思是當用戶訪問網站URL結尾的文件擴展名爲上述指定類型的額圖片時，設置緩存3650天，即10年。

範例2：

location ~ .*\.(js|css)$
 {
    expires 30d;
 }

該範例的意思是當用戶訪問網站URL結尾的文件擴展名爲js，css類型的元素時，設置緩存30天，即1個月。

（2）根據URL中的路徑（目錄）進行判斷，添加expires功能範例

範例3：

location ~ ^/(images|javascript|js|css|flash|media|static)/
{
    expires 360d;
}

該範例的意思是當用過戶訪問網站URL中包含上述路徑（例：images，js，css，這些在服務器端是程序目錄）時，把訪問的內容設置緩存360天，即1年。

2.11.5 Nginx expires配置效果檢查

檢查Nginx expires的方法和檢查Nginx gzip的方法相同。
經過火狐瀏覽器加yslow插件查看gzip壓縮及expires緩存結果時，要提早安裝好火狐瀏覽器，而且要安裝好yslow插件，開啓監控，而後打開LNMP時安裝的博客地址（帶有圖片，JS，CSS），就能夠看到以下圖所示的緩存結果了。

在Linux客戶端可經過以下curl命令查看圖片URL的緩存header信息：

[root@localhost ~]# curl -I 192.168.0.220:8000
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 30 Aug 2017 02:15:54 GMT
Content-Type: text/html
Content-Length: 18
Connection: keep-alive
Last-Modified: Tue, 29 Aug 2017 19:37:44 GMT
ETag: "59a5c288-12"
Expires: Sat, 09 Sep 2017 02:15:54 GMT      #緩存的過時時間
Cache-Control: max-age=864000               #緩存的總時間，單位秒
Accept-Ranges: bytes

2.11.6 Nginx expires功能缺點及解決方法

• 幾乎全部的事物都是有兩面性，沒有十全十美的人和事。Nginx expires功能也不例外，雖然這個功能很好，可是也會給企業帶來一些困惑。
• 當網站被緩存的頁面或數據更新了，此時用戶端看到的可能仍是舊的已經緩存的內容，這樣就會影響用戶體驗，那麼如何解決這個問題呢？解決方法以下。
• 第一，對於常常須要變更的圖片等文件，能夠縮短對象緩存時間，例如：谷歌和百度的首頁圖片常常根據不一樣的日期換成一些節日的圖，因此這裏能夠將這個圖片設置爲緩存期1天。
• 第二，當網站改版或更新時，能夠在服務器將緩存的對象更名（網站代碼程序）。
• 對於網站的圖片，附件，通常不會被用戶直接修改，用戶層面上的修改圖片，其實是從新傳到服務器，雖然內容同樣可是是一個新的圖片名了。
• 網站改版升級會修改JS，CSS元素，若改版時對這些元素改了名，會使得前端的CDN及用戶端須要從新緩存內容。

2.11.7 企業網站緩存日期曾經的案例參考

若企業的業務和網站訪問量不一樣，那麼網站的緩存期時間設置也是不一樣的，好比，以下企業所用的緩存日期就是不同的。

• 51CTO：1周
• 新浪：15天
• 京東：25年
• 淘寶：10年

2.11.8 企業網站有可能不但願被緩存的內容

• 廣告圖片，用於廣告服務，都緩存了就很差控制展現了。
• 網站流量統計工具（JS代碼），都緩存了流量統計就不許了。
• 更新很頻繁的文件（google的logo），這個若是按天，緩存效果仍是顯著的。

三，Nginx日誌相關優化與安全

3.1 編寫腳本實現Nginx access日誌輪詢

當用戶請求一個軟件時，絕大多數軟件都會記錄用戶的訪問狀況，Nginx服務也不例外。Nginx軟件目前尚未相似Apache的經過cronolog或rotatelog對日誌分割處理的功能，可是，運維人員能夠利用腳本開發，Nginx的信號控制功能或reload從新加載，來實現日誌的自動切割，輪詢。

日誌切割腳本以下：

[root@localhost nginx]# cat /server/scripts/cut_nginx_log.sh 
#!/bin/bash
#日誌切割腳本可掛定時任務，天天00點整執行

Dateformat=`date +%Y%m%d`
Basedir="/usr/local/nginx"
Nginxlogdir="$Basedir/logs"
Logname="access"

[ -d $Nginxlogdir ] && cd $Nginxlogdir || exit 1
[ -f ${Logname}.log ] || exit 1
/bin/mv ${Logname}.log ${Dateformat}_${Logname}.log
$Basedir/sbin/nginx -s reload

[root@localhost nginx]# cat >>/var/spool/cron/root << KOF
#cut nginx access log by Mr.chen
00 00 * * * /bin/bash /server/scripts/cut_nginx_log.sh >/dev/null 2>&1

3.2 不記錄不須要的訪問日誌

在實際工做中，對於負載均衡器健康節點檢查或某些特定文件（好比圖片，JS，CSS）的日誌，通常不須要記錄下來，由於在統計PV時是按照頁面計算的，並且日誌寫入太頻繁會消耗大量磁盤I/O，下降服務的性能。

具體配置方法以下：

location ~ .*\.(js|jpg|JPG|jpeg|JPEG|css|bmp|gif|GIF)$
{
    access_log  off;
}
#這裏用location標籤匹配不記錄日誌的元素擴展名，而後關閉日誌

3.3 訪問日誌的權限設置

假如日誌目錄爲/app/logs,則受權方法以下：

chown -R root.root /app/logs
chmod -R 700 /app/logs

不須要在日誌目錄上給Nginx用戶讀或寫許可，但不少網友都沒注意這個問題，他們把該權限直接給了Nginx或Apache用戶，這就成爲了安全隱患。