Nginx基本優化一

NGINX基本優化

更改nginx服務默認用戶
優化nginx進程對應配置
優化綁定不一樣的nginx進程到不一樣cpu，
nginx事件處理模型優化，採用epoll模型
調整優化單個worker進程併發鏈接數
配置nginx worker進程最大打開文件數
優化服務器域名的hash表大小
開啓高效文件傳輸模式sendfile，設置tcp_nopush參數
優化nginx鏈接參數調整鏈接超時時間
上傳文件大小（http Request body size）的限制
fastcgi相關參數調優，fastcgi buffer/cache
配置nginx gzip壓縮實現性能優化
配置nginx expires緩存實現性能優化
訪問日誌輪詢，不記錄某些日誌，代理不開訪問日誌
Nginx站點目錄及文件URL訪問控制
限制網站來源IP訪問

 

1、隱藏版本號優化

http://nginx.org/en/docs/http/ngx_http_core_module.html#server_tokens
Syntax: server_tokens on | off | string;
Default: server_tokens on;
Context: http, server, location
Enables or disables emitting nginx version in error messages and in the 「Server」 response header field.

# curl -I 192.168.0.82
HTTP/1.1 200 OK
Server: nginx/1.8.1
Date: Sun, 10 Jul 2016 08:30:40 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Sun, 15 May 2016 23:28:20 GMT
Connection: keep-alive
ETag: "57390614-264"
Accept-Ranges: bytes

# vi /usr/local/nginx/conf/nginx.conf
在http標籤內加入參數server_tokens off;
# curl -I 192.168.0.82
HTTP/1.1 200 OK
Server: nginx

 

二、隱藏軟件名稱

# vi /home/tools/nginx-1.8.1/src/core/nginx.h
13 #define NGINX_VERSION      "1.8.1"   　　　　　　　　　　 #顯示的版本號，修改成想要顯示的版本號
14 #define NGINX_VER          "nginx/" NGINX_VERSION  　　#將nginx修改成想要的軟件名稱，如GWS
22 #define NGINX_VAR          "NGINX" 　　　　　　　　　　　　#顯示的軟件名稱如如GWS(GTMSWEB SERVER)
23 #define NGX_OLDPID_EXT     ".oldbin"

# vi /home/tools/nginx-1.8.1/src/http/ngx_http_header_filter_module.c
49 static char ngx_http_server_string[] = "Server: nginx" CRLF;    改==> "Server: GTMSWS" CRLF;

# vi /home/tools/nginx-1.8.1/src/http/ngx_http_special_response.c
     21 static u_char ngx_http_error_full_tail[] =
     22 "<hr><center>" NGINX_VER "</center>" CRLF
     23 "</body>" CRLF
     24 "</html>" CRLF
     25 ;
     26 
     27 
     28 static u_char ngx_http_error_tail[] =
     29 "<hr><center>nginx</center>" CRLF   ==》修改成/GTMS WEB SERVER /
     30 "</body>" CRLF
     31 "</html>" CRLF
[root@test83 core]# /usr/local/nginx/sbin/nginx -V  取到編譯參數後從新編譯安裝
nginx version: nginx/1.8.1
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) 
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled
configure arguments: --prefix=/usr/local/nginx-1.8.1 --user=nginx --group=nginx --with-http_stub_status_module --with-http_ssl_module

三、更改nginx服務的默認用戶

編譯時未指定user和group，默認nobody
編譯時指定，默認即爲nginx用戶
root@test83 conf]# ps -ef | grep nginx | grep -v grep 
root       1873      1  0 16:45 ?        00:00:00 nginx: master process /usr/local/nginx/sbin/nginx
nginx      1874   1873  0 16:45 ?        00:00:00 nginx: worker process    
默認主進程是root，在高標準環境通常設置爲普通用戶，防止提權。也能使普通用戶對服務進行重啓等管理

4、優化nginx進程對應配置（worker進程數）

# vi /usr/local/nginx/conf/nginx.conf
worker_processes  1;    #通常cpu核數，後續繼續調整，最高通常爲2倍 
查看cpu個數信息   top按1 能夠看到核數
# grep processor /proc/cpuinfo | wc -l  或者# grep processor -c /proc/cpuinfo    （查看核數）
1    ==>1顆單核
# grep "physical id" /proc/cpuinfo | sort|uniq|wc -l    (cpu個數)
1

 

5、優化綁定不一樣的nginx進程到不一樣cpu，使平均運行（ngx_core_module）,實測差很少

默認狀況nginx的多個進程有可能跑在某一個或某一核的CPU上,致使nginx進程使用的硬件的資源不均,
本節優化是儘量地分配不一樣的nginx進程給不一樣的CPU處理,達到充分有效利用硬件的多CPU多核資源的目的優化nginx進程對應不一樣的CPU配置
在優化不一樣的nginx進程對應不一樣CPU配置時,四核CPU服務器的參考配置參考以下
worker_processes    4;
worker_cpu_affinity 0001 0010 0100 10000;
#worker_cpu_affinity就是配置nginx進程CPU親和力的參數,即把不一樣的進程分配給不一樣的CPU處理,0001等掩碼,分別表明CPU核心,因爲worker_processes進程爲4,所以,上述配置會把每一個進程分配一核CPU處理,默認不會綁定,參數配置爲main段

# man taskset   分配cpu功能
NAME
       taskset - retrieve or set a process?[7m<80><99>s CPU affinity
SYNOPSIS
       taskset [options] mask command [arg]...
       taskset [options] -p [mask] pid
舉例   task -c 1,2,3 /etc/init.d/mysql start  (多實例能夠指定）

 

6、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];
本次用的是centos6.6,所以咱們將nginx的事件處理模型調整爲epoll模型
events {               加到main區塊event標籤，通常nginx已經自動用epoll模式
    worker_connections  1024;
    use epoll;
}

7、調整優化單個worker進程併發鏈接數及worker進程最大打開文件數

worker_connections是個時間模塊指令，用於定義nginx每一個進程的最大併發鏈接數，默認1024，最大客戶端鏈接數等於worker_processes* worker_connections。
進程的最大鏈接數也受linux系統進程的最大打開文件數限制，在執行「ulimit -HSn 65535」或配置相應文件後，此設置才生效
events {
    worker_connections 1024;
}
說明：這個鏈接數包括了全部鏈接(一個用戶請求是兩個連接)例如：代理服務器的鏈接、客戶端的鏈接等，
實際的併發鏈接數受此參數控制外，還和最大打開文件數worker_rlimit_nofile有關

配置nginx進程最大打開文件數
worker_rlimit_nofile 65535;
==>可設置爲系統優化後的ulimit -HSn的結果
Syntax: worker_rlimit_nofile number;
Default: —  

8、優化服務器域名的hash表大小

確切名字和通配符名字存儲在哈希表中。哈希表和監聽端口關聯，每一個端口都最多關聯三張表:確切的名字的哈希表，以星號（*）起始的通配符名字的哈希表和以星號結束的通配符名字的哈希表。
哈希表的尺寸在配置階段進行了優化，能夠以最小的CPU緩存命中失敗來找到名字。nginx首先搜索切確名字的的哈希表，若是沒有找到，則搜索以星號（*）其實的通配符名字的哈希表，若是仍是沒有找到，繼續搜索以星號結束的通配符名字的哈希表。
由於名字是按照域名的節點來搜索的。因此搜索通配符名字的哈希表比搜索確切名字的哈希錶慢。注意:nginx.org存儲在通配符名字的哈希表中，而不在確切名字的哈希表中。正則表達式是一個一個串行的測試，因此是最慢的，並且不可擴展。
因爲上述緣由，咱們通常儘量的使用確切的名字。好比若是使用nginx.org和www.nignx.org來訪問服務器是最頻繁的，那麼咱們明確的定義出來對訪問搜索域名的速度效率來講更有效:

若是定義了大量名字，或者定義了很是長的名字，那就須要在php配置模塊中調整server_names_hash_max_size    默認512kb，通常是cpu L1的4-5倍，
存放server name的最大哈希表大小server_names_hash_bucket_size  Sets the bucket size for the server names hash tables.
server_names_hash_bucket_size的默認值多是32，或者是64，或者是其餘值，取決於CPU的緩存行的長度。若是這個值是32，那麼定義「too.long.server.name.nginx.org」做爲虛擬機主機名就會失敗，顯示以下錯誤信息：
 could not build the server_names_hash,
 you should increase server_names_hash_bucket_size;32
出現這種狀況，那就須要設置值擴大一倍：
 http{
  server_names_hash_bucket_size 64;
 }

9 、開啓高效文件傳輸模式sendfile

sendfile參數用於開啓文件的高效傳輸模式。同時將tcp_nopush和tcp_nodely兩個指令設置爲on，可防止網絡及磁盤IO阻塞，提高nginx工做效率
http://nginx.org/en/docs/http/ngx_http_core_module.html#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

設置tcp_nopush參數
tcp_nopush on
http://nginx.org/en/docs/http/ngx_http_core_module.html#tcp_nopush
Syntax: tcp_nopush on | off;
Default: tcp_nopush off;
Context: http, server, location
參數做用：激活或者禁用linux上的TCP_CORK scoket選項，此選項僅僅當開啓sendfile才生效，
激活tcp_nopush參數能夠容許把http response header和文件的開始放在一個文件裏發佈，積極的做用是減小網絡報文的數量

10、優化nginx鏈接參數調整鏈接超時時間

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

鏈接超時的做用：簡單來講是一種自我管理，自我保護的重要機制
1、設置將無用的鏈接儘快超時，能夠保護服務器的系統資源（cpu、內存、磁盤）
2、當鏈接不少時。及時斷掉那些已經創建好的可是長時間不作事的鏈接，減小其佔用服務器資源，由於服務器維護鏈接也是消耗資源的
3、有時黑客或惡意用戶攻擊網站，就會不斷地和服務器創建多個鏈接，消耗鏈接數，可是啥也不幹，只是持續創建鏈接，就會大量消耗服務器資源，此時就應該及時斷掉這些惡意佔用資源的鏈接
4、lnmp環境中，若是用戶請求了動態服務，則nginx就會創建鏈接請求fastcgi服務以及mysql服務，此時這個nginx鏈接就要設定一個超時時間，
　　在用戶容忍的時間內返回數據，或者再多等一會後端服務返回數據，具體策略按具體業務分析，固然，後端的fastcgi服務以及mysql服務也有對鏈接超時的控制

鏈接超時帶來的問題 1、服務器創建新鏈接也是要消耗資源的，所以，超時設置的過短，就會致使服務器瞬間沒法響應用戶的請求，致使體驗降低
2、企業生產有些PHP程序站點但願設置短鏈接，由於PHP程序創建鏈接消耗的資源和時間要少。
　　而JAVA程序站點通常創建設置長鏈接，由於java程序創建的鏈接消耗的資源和時間更多，這是語言運行的機制決定的
nginx鏈接超時的參數設置 1、keepalive_timeout 60;  
設置客戶端鏈接保持會話的超時時間爲60秒，超事後，服務器會關閉該鏈接，此數值爲參考值
http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests
Syntax: keepalive_timeout timeout [header_timeout];
Default: keepalive_timeout 75s;
Context: http, server, location


2、tcp_nodelay on;
激活tcp_nodelay功能，提升IO性能
http://nginx.org/en/docs/http/ngx_http_core_module.html#tcp_nodelay
Syntax: tcp_nodelay on | off;
Default: tcp_nodelay on;
Context: http, server, location 
參數做用：默認狀況下數據發送時，內核並不會立刻發送，可能會等待更多的字節組成一個數據包，這樣能夠提升IO性能，可是，在每次發送不多字節的業務場景，
使用此功能，等待時間會比較長
生效條件：激活或禁用tcp_nodelay選項，當一個鏈接進入到keep_alive狀態時生效


3、client_header_timeout 15s;
設置讀取客戶端請求頭部數據的超時時間。若是超過這個時間客戶端還沒發送完整的header數據，服務端將返回「Request time out （408）」錯誤。經驗參考值15秒，指定一個超時時間防止客戶端利用http協議進行攻擊
http://nginx.org/en/docs/http/ngx_http_core_module.html#client_header_timeout
Syntax: client_header_timeout time;
Default: client_header_timeout 60s;
Context: http, server


4、client_body_timeout 15s;
設置讀取客戶端請求主體的超時時間，默認60
http://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_timeout
Syntax: client_body_timeout time;
Default: client_body_timeout 60s;
Context: http, server, location 
參數做用：讀取客戶端請求主題的超時時間，這個超時僅僅爲兩次成功的讀取操做之間的一個超時，非請求整個主題數據的時間，如在這個超時時間內，客戶端沒有發送任何數據，nginx將返回「Request time out （408）」錯誤


5、send_timeout 25s;
http://nginx.org/en/docs/http/ngx_http_core_module.html#send_timeout
Syntax: send_timeout time;
Default: send_timeout 60s;
Context: http, server, location 
參數做用：設置服務器端傳送http響應信息到客戶端的超時時間，這個超時時間僅僅爲兩次成功握手後的一個超時，非請求整個數據的超時時間，在這個超時時間內，客戶端沒有接受任何數據，鏈接將被關閉


client_max_body_size

 

 

十一、nginx fastcgi相關參數調優（配合PHP引擎動態服務）

fastcgi_connect_timeout
Syntax: 	fastcgi_connect_timeout time;
Default: 	fastcgi_connect_timeout 60s;
Context: 	http, server, location
Defines a timeout for establishing a connection with a FastCGI server. It should be noted that this timeout cannot usually exceed 75 seconds.
表示nginx服務器和後端fastcgi服務器服務器鏈接的超時時間默認60s，這個參數值一般不要超過75s，由於創建的鏈接越多消耗的資源就越多

fastcgi_send_timeout
Syntax: 	fastcgi_send_timeout time;
Default: 	fastcgi_send_timeout 60s;
Context: 	http, server, location
Sets a timeout for transmitting a request to the FastCGI server. The timeout is set only between two successive write operations, not for the transmission of the whole request.
 If the FastCGI server does not receive anything within this time, the connection is closed.
設置nginx容許fastcgi服務器端返回數據的超時時間，即在規定時間以內後端服務器必須傳完全部數據，不然，nginx將斷開這個鏈接，默認爲60s

fastcgi_read_timeout
Syntax: 	fastcgi_read_timeout time;
Default: 	fastcgi_read_timeout 60s;
Context: 	http, server, location
Defines a timeout for reading a response from the FastCGI server. The timeout is set only between two successive read operations, not for the transmission of the whole response.
 If the FastCGI server does not transmit anything within this time, the connection is closed.
設置nginx從fastcgi服務器端讀取響應信息的超時時間，表示鏈接創建成功後，nginx等待後端服務器的響應時間，是nginx已經進入後端的排隊之中等待處理的時間

fastcgi_buffer_size
Syntax: 	fastcgi_buffer_size size;
Default: 	fastcgi_buffer_size 4k|8k;
Context: 	http, server, location
Sets the size of the buffer used for reading the first part of the response received from the FastCGI server. This part usually contains a small response header. 
By default, the buffer size is equal to one memory page. This is either 4K or 8K, depending on a platform. It can be made smaller, however.
這個是nginx fastcgi的緩衝區大小參數，設定用來讀取從fastcgi服務器收到的第一部分響應信息的緩衝區大小，這裏的第一部分一般會包含一個小的響應頭部，默認狀況，這個參數的大小是由fastcgi_buffers指定的一個緩衝區大小。


fastcgi_buffers
Syntax: 	fastcgi_buffers number size;
Default: 	fastcgi_buffers 8 4k|8k;
Context: 	http, server, location
Sets the number and size of the buffers used for reading a response from the FastCGI server, for a single connection. 
By default, the buffer size is equal to one memory page. This is either 4K or 8K, depending on a platform.  
指定本地須要用多少和多大的緩衝區來緩衝FastCGI的應答請求。若是一個PHP腳本所產生的頁面大小爲256KB，那麼會爲其分配4個64KB的緩衝區來緩存；
若是頁面大小大於256KB，那麼大於256KB的部分會緩存到fastcgi_temp指定的路徑中，可是這並非好方法，由於內存中的數據處理速度要快於硬盤。
通常這個值應該爲站點中PHP腳本所產生的頁面大小的中間值，若是站點大部分腳本所產生的頁面大小爲256KB，那麼能夠把這個值設置爲「16 16k」、「4 64k」等。

fastcgi_busy_buffers_size
Syntax: 	fastcgi_busy_buffers_size size;
Default: 	fastcgi_busy_buffers_size 8k|16k;
Context: 	http, server, location
When buffering of responses from the FastCGI server is enabled, limits the total size of buffers that can be busy sending a response to the client while the response is not yet fully read. 
In the meantime, the rest of the buffers can be used for reading the response and, if needed, buffering part of the response to a temporary file. 
By default, size is limited by the size of two buffers set by the fastcgi_buffer_size and fastcgi_buffers directives.

fastcgi_temp_file_write_size
Syntax: 	fastcgi_temp_file_write_size size;
Default: 	fastcgi_temp_file_write_size 8k|16k;
Context: 	http, server, location
Limits the size of data written to a temporary file at a time, when buffering of responses from the FastCGI server to temporary files is enabled. 
By default, size is limited by two buffers set by the fastcgi_buffer_size and fastcgi_buffers directives. The maximum size of a temporary file is set by the fastcgi_max_temp_file_size directive.

fastcgi_temp_path
Syntax: 	fastcgi_temp_path path [level1 [level2 [level3]]];
Default: 	fastcgi_temp_path fastcgi_temp;
Context: 	http, server, location
Defines a directory for storing temporary files with data received from FastCGI servers. Up to three-level subdirectory hierarchy can be used underneath the specified directory. 
For example, in the following configuration  fastcgi_temp_path /spool/nginx/fastcgi_temp 1 2;
a temporary file might look like this:
    /spool/nginx/fastcgi_temp/7/45/00000123457
See also the use_temp_path parameter of the fastcgi_cache_path directive.

fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 128k;
fastcgi_temp_path /usr/local/nginx/fastcgi_tmp 1 2;

fastcgi_cache(buffer一份給用戶，一份寫到緩存)
表示開啓FastCGI緩存併爲其指定一個名稱。開啓緩存很是有用，能夠有效下降CPU的負載，而且防止502錯誤的發生，可是開啓緩存也會引發不少問題，要視具體狀況而定。
爲FastCGI緩存指定一個文件路徑、目錄結構等級、關鍵字區域存儲時間和非活動刪除時間
Syntax: 	fastcgi_cache_path path [levels=levels] [use_temp_path=on|off] keys_zone=name:size [inactive=time] [max_size=size] 
[manager_files=number] [manager_sleep=time] [manager_threshold=time] [loader_files=number] [loader_sleep=time] 
[loader_threshold=time] [purger=on|off] [purger_files=number] [purger_sleep=time] [purger_threshold=time];
Default: 	—
Context: 	http

 

 

12、配置nginx gzip壓縮實現性能優化

nginx gzip壓縮功能介紹
Syntax: 	gzip on | off;
Default: 	gzip off;
Context: 	http, server, location, if in location

nginx gzip壓縮模塊提供了對文件內容壓縮的功能,nginx服務器將用戶請求的內容在發送給用戶客戶端以前會根據一些具體的策略實施壓縮,以節約網站出口帶寬,同時加快了數據數據傳輸效率,提高了用戶訪問體驗
nginx gzip壓縮的優勢
1、提高網站用戶體驗
因爲發給用戶的內容小了，因此用戶訪問單位大小的頁面就快了，用戶體驗提高了，網站口碑就行了。
2、節約網站帶寬成本
因爲數據是壓縮傳輸的，所以，此舉節省了網站的帶寬流量成本，不過壓縮時會稍微消耗些CPU資源，這個通常能夠忽略
此功能既讓用戶舒服了，公司也少花錢了，一舉多得，對於全部web服務器來講，這是個很是重要的功能

須要(大於1k的純文本)和不須要壓縮的對象
1、    純文本內容壓縮比很高，所以純文本的內容最好要壓縮，例如html、js、css、xml、shtml等各式的文件
2、    被壓縮的純文本文件必須大於1kb，因爲壓縮算法的特殊緣由，極小的文件壓縮可能反而變大
3、    圖片、視頻（流媒體）等文件儘可能不要壓縮，由於這些文件大多都是通過壓縮的，若是再壓縮極可能不會減少或減少不少，或者有可能增大，而在壓縮時還會消耗大量的CPU、內存資源
完整的配置以下
gzip on;
gzip_min_length  1k;      # 1k以上進行壓縮
gzip_buffers  4  32k;       # 4個32k的buffer
gzip_http_version 1.1;         #壓縮版本
gzip_comp_level 9;          #壓縮級別9最大，傳輸速度最快，但處理最慢，也比較消耗cpu資源。
gzip_types  text/css/  test/html  text/xml  application/javascript;   #cat mime.types
gzip_vary on;   #vary header支持。該選項可讓前端的緩存服務器緩存通過gzip壓縮的頁面，例如用squid緩存通過nginx壓縮的數據

使用firefox 安裝yslow firebug檢驗

 

 

配置nginx expires緩存實現性能優化

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

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

nginx expires功能優勢
1、expires 能夠下降網站的帶寬，節約成本。
2、加快用戶訪問網站的速度，提高了用戶訪問體驗。
3、服務器訪問量下降了，服務器壓力就減輕了，服務器成本也會下降，甚至能夠節約人力成本。
對於幾乎全部web服務來講，這都是很是重要的功能之一，Apache服務也有此功能
Server {
    listen  80;
    root    html/www;
    server_name www.gmts.org;
    location / {
        index index.html index.htm;}
    location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
        {expires      10y;}
    location ~ .*\.(js|css)$
        {expires      30d;}
        }
    location ~ ^/(images|javascript|js|css|flash|media|static)/ {
    expires 360d
    }     #也能夠針對目錄

root@test80 ~]# curl  -I http://d1.leju.com/ia/2016/10/14/f580042c2895a2img.gif
HTTP/1.1 200 OK
Date: Sat, 22 Oct 2016 17:28:08 GMT
Content-Type: image/gif
Content-Length: 15073
Connection: keep-alive
Expires: Thu, 12 Jan 2017 02:37:09 GMT     緩存過時時間
Server: Apache
Last-Modified: Fri, 14 Oct 2016 02:28:18 GMT
Accept-Ranges: bytes
Cache-Control: max-age=7776000    緩存的總時間(毫秒）
X-Ser: BC18_dx-hebei-shijiazhuang-1-cache-1, BC26_dx-jiangsu-xuzhou-1-cache-3

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


企業網站緩存日期曾經的案例參考
不一樣的企業的業務和網站訪問量不一樣，網站的緩存期時間設置也是不一樣的，好比，以下企業所用的緩存日期就是不同的
51cto  1周   sina 15天    京東 25年    淘寶 10年

企業網站有可能不但願被緩存的內容
1、廣告圖片，用於廣告服務，都緩存了就很差控制展現了
2、網站流量統計工具（js代碼），都緩存了流量統計就不許了
3、更新頻繁的文件（goole的logo），若是這個按天，緩存效果仍是顯著的

 

nginx日誌相關優化與安全

nginx沒有相似Apache的cronolog日誌分割處理的功能，可是，能夠經過nginxNginx的信號控制功能或者reload重載，而後利用腳原本實現日誌的自動切割。
1、配置日誌切割腳本: 
mkdir -p /server/scripts/  
cd /server/scripts/
cat cut_nginx_log.sh
cd /application/nginx/logs && \
/bin/mv www_access.log www_access_$(date +%F -d -1day).log
/application/nginx/sbin/nginx -s reload
提示：實際上腳本的功能很簡單，就是改名日誌，而後從新加載nginx，從新生成文件記錄日誌

2、將這段腳本保存後加入到Linux的crontab守護進程，讓此腳本在天天凌晨0點執行，就能夠實現日誌的天天分割功能了，操做結果以下：
crontab -l |tail -2
#cut nginx log on 00:00 everynight
00  00 * * * /bin/sh  /server/scripts/cut_nginx_log.sh >/dev/null 2>&1


不記錄不須要的訪問日誌
在實際工做中，對於負載均衡器健康檢查節點或某些特定文件（圖片，js，css）的日誌，通常不須要記錄下來，由於在統計PV時時按照頁面計算的。並且日誌寫入太頻繁會大量消耗磁盤I/O，下降服務的性能
具體配置方法爲：
location ~ .*\.(js|jpg|jpeg|JPEG|css|bmp|gif|GIF)$ {
access_log off;
}
訪問日誌的權限設置
假如日誌目錄爲/app/logs，則受權方法爲：
chown –R root.root /app/logs
chmod –R 700 /app/logs
#不須要在日誌目錄上給nginx用戶讀或者寫許可，不必給大權限，nginx有master進程root用戶，控制能夠寫入日誌

Nginx站點目錄及文件URL訪問控制

根據擴展名限制程序和文件訪問
Web2.0時代，絕大多數網站都是以用戶爲中心，例如：bbs、blog、sns產品，這幾個產品有個共同的特色，就是不但容許用戶發佈內容到服務器，還容許用戶發圖片甚至附件到服務器上，因爲爲用戶開了上傳功能，所以給服務器帶來了很大的安全風險，雖然不少程序在上傳前會作必定的控制。例如：文件的大小、類型等，可是，一不當心就會被黑客鑽了空子，上傳了木馬程序
安全的權限： 
1、全部站點目錄的用戶和組都應該爲root，
2、全部目錄默認權限是755；
3、全部文件默認權限爲644；
注意：網站服務的用戶不能用root，
以上權限的設置能夠作到防止黑客上傳木馬，以及修改站點文件，可是，合理的用戶上傳內容也被拒之門外了，那麼如何解決可讓合法的用戶上傳文件又不至於被黑客利用攻擊呢？
這就是對業務進行分離，在比較好的網站業務架構中，應該把資源文件，包括用戶上傳的圖片，附件等的服務和程序
大多數公司的不安全的受權以下：
1）chmod -R 777 /sitedir（最不安全）
2) chmod -R nginx.nginx /sitedir（最不安全）
若是大多數公司受權通常的受權，會給網站帶來最大的安全隱患
下面是利用Nginx配置禁止訪問上傳資源目錄下的PHP、shell、perl、python程序文件，這樣用戶即便上傳了木馬文件也無法去執行，從而增強了網站的安全
範例1: 配置nginx限制指定目錄下的指定程序被解析，須要寫在PHP配置的前面
location ~ ^images/.*\.(php|php5|.sh|.pl|.py)$
{    deny all;  }

location ~ ^/static/.*\.(php|php5|.sh|.pl|.py)$
{    deny all;  }

location ~* ^/data/(attachment|avatar)/.*\.(php|php5)$
{    deny all;  }
範例2：Nginx下配置禁止訪問*.txt文件，實際配置信息以下：
location ~* \.(txt|doc)$
if (-f $request_filename) {
root /data/www/www;
#rewrite …… 能夠重定向到某個URL
break;
}
location ~* \.(txt|doc)$ {
    root /data/www/www;
    deny all;
    }
配置禁止訪問指定的單個或多個目錄。單目錄
location ~ ^/(static)/ {
    deny all;
    }
location ~ ^/static {
    deny all;
    }
多個目錄：
location ~ ^ /(static|js){
     deny all;
}

範例2：禁止訪問目錄並返回指定的http狀態碼
server {
    listen        80;
    server_name     www.gmts.org
    root        /data0/www/www;
    index        index.html index.htm;
    access_log  /app/logs/www_access.log  commonlog;
    location /admin/ { return 404; }
    location /templates/ { return 403;}
    }

限制網站來源IP訪問

下面介紹如何使用ngx_http_access_module限制網站來源ip訪問
案例環境：phpmyadmin數據庫的web客戶端，內部開發人員用的。
範例1：禁止某目錄讓外界訪問，可是容許某IP訪問該目錄，且支持PHP解析
location ~ ^/gtms/ {
    allow 202.111.12.211;
    deny all;
}

方法1：使用if來控制
if  ($remote_addr = 10.0.0.7 ) {
return 403;
    }
if  ($remote_addr = 218.247.17.130 ) {
    set $allow_access_root  `true`;
}
注意事項：經過防火牆 效率高
1、deny 必定要加一個ip，不然403，不往下執行了，如在同一域名下，會形成死循環
2、ip段 127.0.0.    10.10.10.0/16
3、以deny all;結尾，表示除了上面allow的，其餘都禁止，如
location / {
deny 192.168.1.1;
allow 127.0.0.0/24
allow .......
deny all;
}

Nginx如何防止用戶IP訪問網站(惡意域名解析,也至關因而直接IP訪問企業網站)
方法一、讓使用IP訪問網站的，或者訪問經惡意解析域名，收到501錯誤
說明：直接報501錯誤，從用戶體驗上不是很好
上述代碼放到第一個虛擬主機前面
方法2：經過301跳轉到主頁
server {
listen 80 default_server;
server_name _;
return 501;
#經過ip訪問返回501 Not Implemented
#nginx
#rewrite ^(.*) http://blog.gtms.org/$1 permanent
}
方法3：發現某域名惡意解析到公司的服務器IP，在server標籤裏添加如下代碼便可，如有多個server要多處添加。
if ($host  !~ www/.gtms/.com$) {
    rewrite ^(.*) http://www.gtms.com/$1 permanent;
}