Nginx 之二: nginx.conf 配置及基本優化

一:經常使用功能優化:html

1:網絡鏈接的優化:前端

  只能在events模塊設置,用於防止在同一一個時刻只有一個請求的狀況下,出現多個睡眠進程會被喚醒但只能有一個進程可得到請求的尷尬,若是不優化,在多進程的nginx會影響以部分性能。linux

events {
accept_mutex on; #優化同一時刻只有一個請求而避免多個睡眠進程被喚醒的設置,on爲防止被同時喚醒,默認爲off,所以nginx剛安裝完之後要進行適當的優化。
}

2.設置是否容許同時接受多個網絡鏈接:nginx

  只能在events模塊設置,Nginx服務器的每一個工做進程能夠同時接受多個新的網絡鏈接,可是須要在配置文件中配置,此指令默認爲關閉,即默認爲一個工做進程只能一次接受一個新的網絡鏈接,打開後幾個同時接受多個,配置語法以下:web

events {
accept_mutex on;
multi_accept on; #打開同時接受多個新網絡鏈接請求的功能。
}

3.隱藏ngxin版本號:正則表達式

  當前使用的nginx可能會有未知的漏洞,若是被黑客使用將會形成沒法估量的損失,可是咱們能夠將nginx的版本隱藏,以下:chrome

server_tokens off; #在http 模塊當中配置

4.:選擇事件驅動模型:json

  Nginx支持衆多的事件驅動,好比select、poll、epoll,只能設置在events模塊中設置:後端

events {
accept_mutex on;
multi_accept on;
use epoll; #使用epoll事件驅動,由於epoll的性能相比其餘事件驅動要好不少
}

5:配置單個工做進程的最大鏈接數:瀏覽器

  經過worker_connections number;進行設置,numebr爲整數,number的值不能大於操做系統能打開的最大的文件句柄數,使用ulimit -n能夠查看當前操做系統支持的最大文件句柄數,默認爲爲1024.

events {
    worker_connections  102400; #設置單個工做進程最大鏈接數102400
    accept_mutex on;
    multi_accept on;
    use epoll;
}

6:定義MIME-Type:

  在瀏覽器當中能夠顯示的內容有HTML/GIF/XML/Flash等內容,瀏覽器爲取得這些資源須要使用MIME Type,即MIME是網絡資源的媒體類型,Nginx做爲Web服務器必需要可以識別全都請求的資源類型,在nginx.conf文件中引用了一個第三方文件,使用include導入:

include mime.types;
default_type application/octet-stream;

7:自定義訪問日誌:

  訪問日誌是記錄客戶端即用戶的具體請求內容信息,全局配置模塊中的error_log是記錄nginx服務器運行時的日誌保存路徑和記錄日誌的level,所以有着本質的區別,並且Nginx的錯誤日誌通常只有一個,可是訪問日誌能夠在不一樣server中定義多個,定義一個日誌須要使用access_log指定日誌的保存路徑,使用log_format指定日誌的格式,格式中定義要保存的具體日誌內容:

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

8:將日誌定義爲json格式:

  在使用日誌分析工具如ELK對訪問日誌作統計的時候,就須要將日誌格式定義爲json格式,以便於取相應字段的key作統計,完整的定義以下:

   log_format logstash_json '{"@timestamp":"$time_iso8601",'
        '"host":"$server_addr",'
        '"clientip":"$remote_addr",'
        '"size":$body_bytes_sent,'
        '"responsetime":$request_time,'
        '"upstreamtime":"$upstream_response_time",'
        '"upstreamhost":"$upstream_addr",'
        '"http_host":"$host",'
        '"url":"$uri",'
        '"domain":"$host",'
        '"xff":"$http_x_forwarded_for",'
        '"referer":"$http_referer",'
        '"agent":"$http_user_agent",'
        '"status":"$status"}';
server {
    listen 8090;
    server_name samsung.chinacloudapp.cn;
    access_log /var/log/nginx/samsung1.access.log logstash_json;
    location / {
      root html;
      index index1.html index.htm;
    }
    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
    root html;
     }
  }

    access_log  /var/log/nginx/json.access.log  logstash_json;  #定義日誌路徑爲/var/log/nginx/json.access.log,並引用在主配置文件nginx.conf中定義的json日誌格式

json格式的日誌內以下:

{"@timestamp":"2016-04-25T13:16:29+08:00","host":"192.168.0.202","clientip":"106.120.73.171","size":0,"responsetime":0.000,"upstreamtime":"-","upstreamhost":"-","http_host":"samsung.chinacloudapp.cn","url":"/index1.html","domain":"samsung.chinacloudapp.cn","xff":"-","referer":"-","agent":"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.75 Safari/537.36","status":"304"}

9:配置容許sendfile方式傳輸文件:

  是由後端程序負責把源文件打包加密生成目標文件,而後程序讀取目標文件返回給瀏覽器;這種作法有個致命的缺陷就是佔用大量後端程序資源,若是遇到一些訪客下載速度巨慢,就會形成大量資源被長期佔用得不到釋放(如後端程序佔用的CPU/內存/進程等),很快後端程序就會由於沒有資源可用而沒法正常提供服務。一般表現就是 nginx報502錯誤,而sendfile打開後配合location能夠實現有nginx檢測文件使用存在,若是存在就有nginx直接提供靜態文件的瀏覽服務,所以能夠提高服務器性能.

  能夠配置在http、server或者location模塊,配置以下:

    sendfile        on;
    sendfile_max_chunk 512k;   #Nginxg工做進程每次調用sendfile()傳輸的數據最大不能超出這個值,默認值爲0表示無限制,能夠設置在http/server/location模塊中。

10:配置nginx工做進程最大打開文件數:

  能夠設置爲linux系統最大打開的文件數量一致,在全局模塊配置

worker_rlimit_nofile 65535;

11:會話保持時間:

  用戶和服務器創建鏈接後客戶端分配keep-alive連接超時時間,服務器將在這個超時時間事後關閉連接,咱們將它設置低些可讓ngnix持續工做的時間更長,1.8.1默認爲65秒,通常不超過120秒。

 keepalive_timeout  65 60;  #後面的60爲發送給客戶端應答報文頭部中顯示的超時時間設置爲60s:如不設置客戶端將不顯示超時時間。
  Keep-Alive:timeout=60  #瀏覽器收到的服務器返回的報文

若是設置爲0表示關閉會話保持功能,將以下顯示:
  Connection:close  #瀏覽器收到的服務器返回的報文

12配置網絡監聽:

  使用命令listen,能夠配置監聽IP+端口,端口或監聽unix socket:

listen       8090;   #監聽本機的IPV4和IPV6的8090端口,等於listen *:8000
listen       192.168.0.1:8090; #監聽指定地址的8090端口
listen     Unix:/www/file  #監聽unix socket

 

 二:server部分主要配置:

一、基於域名和IP的虛擬主機

 server_name  localhost www.a.com; #多個域名用空格間隔便可
 server_name  192.168.0.2;  #IP是本機的網卡IP地址

二、location 模塊正則匹配配置:

  在沒有使用正則表達式的時候,nginx會先在server中的多個location選取匹配度最高的一個uri,uri是用戶請求的字符串,即域名後面的web文件路徑,而後使用該location模塊中的正則url和字符串,若是匹配成功就結束搜索,並使用此location處理此請求。

  location 正則匹配的語法:

=  #用於標準uri前,須要請求字串與uri徹底匹配,若是匹配成功就中止向下匹配並當即處理請求。
~  #區分大小寫
~*  #不區分大寫
!~  #區分大小寫不匹配
!~* #不區分大小寫不匹配 
^  #匹配以什麼開頭
$  #匹配以什麼結尾
\  #轉義字符。能夠轉. * ?*  #表明任意長度的任意字符

-f和!-f #用來判斷是否存在文件
-d和!-d #用來判斷是否存在目錄
-e和!-e #用來判斷是否存在文件或目錄
-x和!-x #用來判斷文件是否可執行

 三、常見http狀態碼:

200 #請求成功,即服務器返回成功
301 #永久重定向
302 #臨時重定向
403 #禁止訪問,通常是服務器權限拒絕
400 #錯誤請求,請求中有語法問題,或不能知足請求。  
403 #服務器權限問題致使沒法顯示
404 #服務器找不到用戶請求的頁面 500 #服務器內部錯誤,大部分是服務器的設置或內部程序出現問題
501 #沒有將正在訪問的網站設置爲瀏覽器所請求的內容
502 #網關問題,是代理服務器請求後端服務器時,後端服務器不可用或沒有完成 相應網關服務器,這一般是反向代理服務器下面的節點出問題致使的。 503 #服務當前不可用,多是服務器超載或停機致使的,或者是反向代理服務器後面沒有能夠提供服務的節點。 504 #網關超時,通常是網關代理服務器請求後端服務器時,後端服務器沒有在指定的時間內完成處理請求,多數是服務器過載致使沒有在特定的時間內返回數據給前端代理服務器。
505 #該網站不支持瀏覽器用於請求網頁的HTTP協議版本(最爲常見的是HTTP/1.1)

 4.在server部分使用location配置一個web界面:

要求:在html/localtion/myweb 裏面有個index.html文件裏面寫了myweb,當訪問nginx 服務器的/myweb的時候要顯示此html文件的內容:

    server {
        listen       8090;
        server_name  samsung.chinacloudapp.cn;
        access_log  /var/log/nginx/samsung1.access.log   logstash_json;
        location / {
            root   html;
            index  index1.html index.htm;
        }
        
    location ~/myweb { #區分大小寫,即訪問Myweb是不行的
        root html/localtion;  #定義myweb所在的路徑,即在瀏覽器訪問myweb的時候,實際是訪問的html/localtion/myweb目錄裏面的web內容
        index   index.html; #默認首頁文件類型
    }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }

驗證以下:

 

三:sysctl.conf針對IPv4內核的7個參數的配置優化:

一、net.core.netdev_max_backlog  #每一個網絡接口的處理速率比內核處理包的速度快的時候,容許發送隊列的最大數目。

[root@Server1 nginx]# sysctl -a | grep max_backlog
net.core.netdev_max_backlog = 1000  這裏默認是1000,能夠設置的大一些,好比:
net.core.netdev_max_backlog = 102400

二、net.core.somaxconn: #用於調節系統同時發起的TCP鏈接數,默認值通常爲128,在客戶端存在高併發請求的時候,128就變得比較小了,可能會致使連接超時或者重傳問題。

net.core.somaxconn = 128  #默認爲128,高併發的狀況時候要設置大一些,好比:
net.core.somaxconn = 102400

三、net.ipv4.tcp_max_orphans:設置系統中作多容許多少TCP套接字不被關聯到任何一個用戶文件句柄上,若是超出這個值,沒有與用戶文件句柄關聯的TCP套接字將當即被複位,同時給出警告信息,這個值是簡單防止DDOS(Denial of service)的攻擊,在內存比較充足的時候能夠設置大一些:

net.ipv4.tcp_max_orphans = 32768 #默認爲32768,能夠改該打一些:
net.ipv4.tcp_max_orphans = 102400

四、net.ipv4.tcp_max_syn_backlog #用於記錄還沒有收到客戶度確認消息的鏈接請求的最大值,通常要設置大一些:

net.ipv4.tcp_max_syn_backlog = 256  #默認爲256,設置大一些以下:
net.ipv4.tcp_max_syn_backlog =  102400

五、net.ipv4.tcp_timestamps #用於設置時間戳,能夠避免序列號的卷繞,有時候會出現數據包用以前的序列號的狀況,此值默認爲1表示不容許序列號的數據包,對於Nginx服務器來講,要改成0禁用對於TCP時間戳的支持,這樣TCP協議會讓內核接受這種數據包,從而避免網絡異常,以下:

net.ipv4.tcp_timestamps = 1 #默認爲1,改成0,以下:
net.ipv4.tcp_timestamps = 0

六、net.ipv4.tcp_synack_retries #用於設置內核放棄TCP鏈接以前向客戶端發生SYN+ACK包的數量,網絡鏈接創建須要三次握手,客戶端首先向服務器發生一個鏈接請求,服務器收到後由內核回覆一個SYN+ACK的報文,這個值不能設置過多,會影響服務器的性能,還會引發syn攻擊:

net.ipv4.tcp_synack_retries = 5 #默認爲5,能夠改成1避免syn攻擊
net.ipv4.tcp_synack_retries = 1

七、net.ipv4.tcp_syn_retries  #與上一個功能相似,設置爲1便可:

net.ipv4.tcp_syn_retries = 5 #默認爲5,能夠改成1
net.ipv4.tcp_syn_retries = 1

 

:配置文件中針對CPU的2個優化參數:

一、woker_precess #設置Nginx 啓動多少個工做進程的數量
二、woker_cpu_affinit #固定Nginx 工做進程所運行的CPU核心

 

五:配置文件中與網絡相關的4個指令:

1、keepalived_timeout 60 50; #設置Nginx服務器與客戶端保持鏈接的時間是60秒,到60秒後服務器與客戶端斷開鏈接,50s是使用Keep-Alive消息頭與部分瀏覽器如 chrome等的鏈接事件,到50秒後瀏覽器主動與服務器斷開鏈接。
  keepalived_timeout 60 50;
2、sendtime_out  10s #Http核心模塊指令,指定了發送給客戶端應答後的超時時間,Timeout是指沒有進入完整established狀態,只完成了兩次握手,若是超過這個時間客戶端沒有任何響應,nginx將關閉與客戶端的鏈接。
  sendtime_out 10s;
3、client_header_timeout  #用於指定來自客戶端請求頭的headerbuffer大小,對於大多數請求,1kb的緩衝區大小已經足夠,若是自定義了消息頭部或有更大的cookie,能夠增長緩衝區大小。
  client_header_timeout 4k;
4、multi_accept  #設置是否容許,Nginx在已經獲得一個新鏈接的通知時,接收儘量更多的鏈接。
    multi_accept on;

 

六:配置文件中與驅動模型相關的8個指令: 

一、use; #用於指定Nginx 使用的事件驅動模型

二、woker_process; #指定Nginx啓動的工做進程的數量

三、woker_connections  65535; #指定Nginx 每一個工做進程的最大鏈接數,woker_connections  *  woker_process即爲Nginx的最大鏈接數量。

四、woker_rlimit_sigpending 65535  #Nginx每一個進程的事件信號隊列的上限長度,若是超出長度,Nginx則使用poll模型處理客戶的請求。

五、devpoll_changes 和 devpoll_events #用於設置Nginx 在/dev/poll 模型下Nginx服務器能夠與內核之間傳遞事件的數量,前一個設置傳遞給內核的事件數量,後一個設置從內核讀取的事件數量,默認爲512。

六、kqueue_changes 和 kqueue_events #設置在kqueue模型下Nginx服務器能夠與內核之間傳遞事件的數量,前一個設置傳遞給內核的事件數量,後一個設置從內核讀取的事件數量,默認爲512。

七、epoll_events #設置在epoll驅動模式下Nginx 服務器能夠與內核之間傳遞事件的數量,默認爲512。

八、rtsig_signo  #設置Nginx在rtsig 模式使用的兩個信號中的第一個,第二個信號是在第一個信號的編號上加1.

九、rtsig_overflow #這些參數指定如何處理rtsig隊列溢出。當溢出發生在nginx清空rtsig隊列時,它們將連續調用poll()和 rtsig.poll()來處理未完成的事件,直到rtsig被排空以防止新的溢出,當溢出處理完畢,nginx再次啓用rtsig模式,rtsig_overflow_events specifies指定通過poll()的事件數,默認爲16,rtsig_overflow_test指定poll()處理多少事件後nginx將排空rtsig隊列,默認值爲32,rtsig_overflow_threshold只能運行在Linux 2.4.x內核下,在排空rtsig隊列前nginx檢查內核以肯定隊列是怎樣被填滿的。默認值爲1/10,「rtsig_overflow_threshold 3」意爲1/3。

相關文章
相關標籤/搜索