碼上歡樂
相關內容    簡體    繁體

nginx作為web服務以及nginx.conf詳解

本文轉載自   查看原文   2017-10-17 17:45   11901    網站架構

Nginx系列文章：http://www.cnblogs.com/f-ck-need-u/p/7576137.html

1.nginx簡介

nginx是一個優秀的web服務程序、反向代理程序。它采用非阻塞異步的套接字，使用epoll方式實現事件驅動，同時采用一個master+N個worker進程(默認)的方式處理請求，這種架構使得它在並發的處理能力上極其出色，可以比較輕松地解決C10K問題。

2.nginx處理請求的過程簡單說明

master進程用於管理worker進程，例如接收外界信號、向worker進程發送信號、銷毀worker進程、啟動worker進程等等。

nginx之所以性能良好，完全是由它的架構決定的。每個worker進程是業務處理進程，負責監聽套接字、處理請求、響應請求、代理請求至后端服務器等。

作為web server處理靜態資源時每個worker進程的大致流程：

(1).監聽套接字。
(2).與客戶端建立連接。
(3).處理監聽到的連接請求(加載靜態文件)。
(4).響應數據。
(5).斷開連接。

這幾個過程是每個web server都具備的能力，但對於nginx來說，由於它的異步非阻塞，每個過程都不會阻塞(有些小過程必須阻塞的時候還是會阻塞)，使得並發處理能力很好。

從監聽套接字開始說。每個worker進程都是平等的，它們都可以去監聽套接字，正常情況下不可避免地會造成爭搶和"驚群問題"，而nginx采用"爭搶"accept互斥鎖的方式，只有持有accept互斥鎖的worker進程才有資格將連接請求接到自己的隊列中並完成TCP連接的建立。但每個進程是相互獨立而平等的，誰有資格去"爭搶"互斥鎖且有更大幾率爭搶成功？只要worker進程當前建立的連接數小於worker_connections指令指定的值(實際上源碼中設置的是該值的7/8)，就允許爭搶互斥鎖，因為連接數超過了該值的7/8表示已經非常繁忙。除了繁忙程度限制資格，還有epoll_wait的timeout的指標，等待越久的worker進程爭搶能力越強。總之，在某一時刻，一定只有一個worker進程監聽並accept新的連接請求。

當已經監聽到連接請求時，worker進程與它進行三次握手，並最終accpet到自己的內存池中，並和客戶端交互數據，處理客戶端發送的http請求並響應數據給客戶端。但是，nginx的高效就在於它的異步非阻塞，無論是在TCP連接進入ESTABLISHED之前，還是等待客戶端發送請求，亦或者是等待加載本地靜態資源的I/O，以及響應數據給客戶端的任意一個過程中，nginx都是非阻塞的，在任意等待發生時都可以去處理其它事情。當等待的某個資源已經准備成功時將產生事件通知worker進程，worker進程可隨后去處理。在此過程中，由於worker進程綁定在一個CPU核心上(推薦如此做)，所有的連接都放在內存池中，這使得上下文切換時是極其輕量的，極大地減輕了CPU消耗。從理論上來說，當每個worker綁定了一個CPU核心時，它的並發處理能力主要依賴於內存的大小。

實際上apache httpd的event MPM也是異步非阻塞的，也可以采用epoll，但它采用的是多線程方式，雖然異步，但它的異步似乎不體現在並發能力上，而僅僅只是一些具有特殊狀態的連接(如長連接)的異步處理，在處理過程中cpu還是不斷地需要在各線程之間大量切換，並發能力並不比worker MPM強多少，相比nginx更是遠遠不如。

3.nginx命令

[root@xuexi nginx]# nginx -h
nginx version: nginx/1.12.0
Usage: nginx [-?hvVtTq] [-s signal] [-c filename] [-p prefix] [-g directives]

Options:
  -?,-h         : this help
  -v            : 輸出版本號
  -V            : 輸出版本號以及編譯選項
  -t            : 檢查配置文件的語法
  -T            : 檢查配置文件的語法並輸出配置的內容
  -q            : 靜默模式，不輸出任何信息
  -s signal     : 向主進程發送信號：stop, quit, reopen, reload
  -p prefix     : 設置nginx的basedir(默認為編譯時的prefix)
  -c filename   : 指定配置文件
  -g directives : 提前設置全局指令

-V選項輸出編譯選項。

[root@xuexi nginx]# nginx -V
nginx version: nginx/1.12.0
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC) 
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled
configure arguments: --prefix=/usr/local/nginx-1.12.0 --pid-path=/var/run/nginx/nginx.pid --lock-path=/var/lock/subsys/nginx.lock --user=nginx --group=nginx --with-http_ssl_module --with-http_flv_module --with-http_stub_status_module --with-http_gzip_static_module --with-pcre

(1).使用默認配置文件直接啟動nginx和指定配置文件啟動nginx

nginx -c /usr/local/nginx/conf/nginx.conf

(2).運行時重載配置文件。當nginx主進程接收到重載配置文件的命令后，它會先檢查新配置文件語法，然后載入該配置文件到內存中並解析。然后，主進程fork一系列新的worker進程，並發送QUIT信號給舊的worker進程(graceful stop)。舊的工作進程接收到QUIT信號后，會停止接受新的連接請求，並繼續處理舊的連接直到請求處理完成后才退出。

nginx -s reload

(3).運行時快速關閉nginx。

nginx -s stop

(4).運行時優雅關閉nginx。所有的工作進程會停止接受新的連接，並繼續服務舊的連接請求直到所有的請求完成后才退出。

nginx -s quit

(5).運行時重新打開日志文件。

ngnix -s reopen

4.nginx模塊及http功能速覽

Nginx的代碼由一個核心和一系列的模塊組成。

核心(core functionality)主要用於提供全局應用的基本功能，創建必要的運行時環境及確保不同模塊之間平滑地進行交互等，對應於配置文件的main段和event段。核心涉及的指令官方文檔：http://nginx.org/en/docs/ngx_core_module.html。

還有很多功能都通過模塊實現，nginx是高度模塊化程序。如web相關的功能模塊有"ngx_http_*_module"，和mail相關的功能模塊有"ngx_mail_*_module"，和tcp代理、負載均衡相關的功能模塊有"ngx_stream_*_module"，這些類別的模塊中又分為很多類別的模塊，如http類別的模塊中有基本核心模塊、事件類模塊、緩存類模塊、SSL相關模塊、負載均衡類模塊upstream等等。

以下是http功能模塊類中常見的模塊。

http類模塊名 模塊功能說明
ngx_http_core_module http核心模塊，對應配置文件中的http段，包含很多指令，如location指令
ngx_http_access_module 訪問控制模塊，控制網站用戶對nginx的訪問，對應於配置文件中的allow和deny等指令
ngx_http_auth_basic_module 通過用戶名和密碼認證的訪問控制，如訪問站點時需要數據用戶名和密碼，指令包括auth_basic和auth_basic_user_file
ngx_http_charset_module 設置網頁顯示字符集。指令之一為charset，如charset utf-8
ngx_http_fastcgi_module fastcgi模塊，和動態應用相關。該模塊下有非常多的子模塊。
ngx_http_flv_module 支持flv視頻流的模塊，如邊下邊播
ngx_http_mp4_module 同flv模塊
ngx_http_gzip_module 壓縮模塊，用來壓縮nginx返回的響應報文。一般只壓縮純文本內容，因為壓縮比例非常大，而圖片等不會去壓縮
ngx_http_image_filter_module 和圖片裁剪、縮略圖相關模塊，需要安裝gd-devel才能編譯該模塊
ngx_http_index_module 定義將要被作為默認主頁的文件，對應指令為index。"index index.html,index.php"
ngx_http_autoindex_module 當index指令指定的主頁文件不存在時，交給autoindex指令，將自動列出目錄中的文件autoindex {on/off}  
ngx_http_log_module 和訪問日志相關的模塊，指令包括log_format和access_log
ngx_http_memcached_module 和memcached相關的模塊，用於從memcached服務器中獲取相應響應數據
ngx_http_proxy_module 和代理相關，允許傳送請求到其它服務器
ngx_http_realip_module 當nginx在反向代理的后端提供服務時，獲取到真正的客戶端地址，否則獲取的是反向代理的IP地址
ngx_http_referer_module 實現防盜鏈功能的模塊
ngx_http_rewrite_module 和URL地址重寫相關的模塊，需要安裝pcre-devel才能編譯安裝該模塊
ngx_http_scgi_module simple cgi，是cgi的替代品，和fastcgi類似，但更簡單
ngx_http_ssl_module 提供ssl功能的模塊，即實現HTTPS
ngx_http_stub_status_module 獲取nginx運行狀態信息
ngx_http_upstream 和負載均衡相關模塊

這些模塊共同組成了nginx的http功能。

5.nginx配置文件簡單說明

nginx的配置文件有很多個，如下。其中主配置文件為nginx.conf，其他配置文件在需要的時候使用include指令將其包含到主配置文件中。

[root@xuexi ~]# ls /usr/local/nginx/conf/
fastcgi.conf  fastcgi_params  koi-utf  mime.types  nginx.conf  scgi_params  uwsgi_params  win-utf
fastcgi.conf.default  fastcgi_params.default  koi-win  mime.types.default  nginx.conf.default  scgi_params.default  uwsgi_params.default

其中".default"后綴的是對應前綴配置文件的備份配置文件，".params"是對應前綴的參數文件。如fastcgi.conf是和fastcgi相關參數的配置文件，fastcgi.params是fastcgi的參數文件，fastcgi.conf.default是fastcgi.conf的備份文件。

關於主配置文件nginx.conf，由於Nginx高度模塊化，所以它是分段配置的，核心模塊為core，對應配置文件中的Main和Events段。此外還有其他一些模塊。配置文件中每一個指令必須以分號";"結束，否則語法錯誤。

5.1 main和events段

Main用於配置錯誤日志、進程及權限等相關的參數，Events用於配置IO模型，如epoll、kqueue、select或poll等，它們是必備模塊。如下配置：

#user nobody; # worker進程身份,默認使用編譯時指定值.語法為"user user_name [group_name]"
worker_processes  4;  # worker進程數量,該指令值依賴因素較多，例如是否CPU密集型、是否IO密集型。
                      # 在初始時設置為cpu的總核數是一個不錯的選擇。

#error_log logs/error.log; # 錯誤日志文件，禁用錯誤日志"error_log /dev/null LEVEL;"
#error_log logs/error.log notice; # 級別:debug|info|notice|warn|error|crit|alert|emerg，默認為error
#error_log logs/error.log info;

#pid logs/nginx.pid;
#lock_file logs/nginx.lock;

events {
    worker_connections  1024;   # 每個worker進程的最大連接數
    multi_accept on;            # 是否一次性將監聽到的連接全接收進來，默認為off，關閉時一次接收一條連接
    accept_mutex on             # 默認為on，開啟時表示以串行方式接入新連接，否則將通報給所有worker。
                                # 這可能會浪費資源並產生不可預計的后果，例如驚群問題
}

如果某個文件采用了相對路徑，則其相對的基准為basedir。例如編譯時--prefix指定為/usr/local/nginx，則指定pid為logs/nginx.pid時，其實際路徑為/usr/local/nginx/logs/nginx.pid。

worker_processes的值和work_connections的值決定了最大並發數量。例如上面的配置中，每個worker進程最大允許1024個連接，配置了4個worker進程，所以並發數量為1024*4=4096。但在反向代理場景中計算方法不同，因為nginx既要維持和客戶端的連接，又要維持和后端服務器的連接，因此處理一次連接要占用2個連接，所以最大並發數計算方式為：worker_processes*worker_connections/2。此外還需注意，除了和客戶端的連接、與后端服務器的連接，nginx可能還會打開其他的連接，這些都會占用文件描述符，從而影響並發數量的計算。最后還需注意，最大並發數量還受"允許打開的最大文件描述符數量"限制，可以使用"worker_rlimit_nofile"指令修改或直接修改操作系統的對應內核參數。

可以在main段使用worker_cpu_affinity指令綁定CPU核心。nginx通過位數識別CPU核心以及核心數，指定位數上占位符為1表示使用該核心，占位符為0表示不使用該核心。例如2核cpu的位數分別為01和10，4核的位數分別為1000,0100,0010以及0001，同理8核和16核。在結合worker_processes指令一起使用時，要注意worker進程和核心的對應方式，例如：

# 每個worker分別對應cpu0/cpu1/cpu2/cpu3
worker_processes    4;
worker_cpu_affinity 0001 0010 0100 1000;

# 有4核心，但只有兩worker，第一個worker對應cpu0/cpu2，第二個worker對應cpu1/cpu3
worker_processes    2;
worker_cpu_affinity 0101 1010;

在events段，可以使用"use"指令可以指定使用哪種I/O模型，Linux上默認是epoll，通常可以不用手動去設置，因為nginx默認會采用最佳配置。

以下是main段和events段的配置示例，大多數采用的默認值，需要修改的大致就是worker數量、每個worker最大連接數以及進程綁定cpu。

worker_processes  4;
events {
    worker_connections  1024;
}

5.2 http段

5.2.1 配置文件概覽

http段是由http相關模塊支持的。以下是默認配置項。注意，http根段下使用相對路徑是相對conf目錄的，如"include extra/.conf"表示的是conf/extra/.conf；非根段內的相對路徑如server段內使用相對路徑是相對於的安裝目錄<prefix>的，例如nginx安裝在/usr/local/nginx下，當location中的root設置為html時，它表示的路徑是/usr/local/nginx/html/。

http {
    include       mime.types;    # nginx支持的媒體文件類型。相對路徑為同目錄conf下的其他文件
    default_type  application/octet-stream;      # 默認的媒體類型

    #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 logs/access.log main;

    sendfile        on;   # 啟用sendfile傳輸模式，此模式是"零拷貝"
    #tcp_nopush on; # 只在sendfile on時有效。讓數據包擠滿到一定程度才發送出去，擠滿之前被阻塞

    #keepalive_timeout 0; # keepalive的超時時間
    keepalive_timeout  65;

    #gzip on; # 是否啟用gzip壓縮響應報文

    server {                    # 定義虛擬主機
        listen       80;        # 定義監聽套接字
        server_name  localhost; # 定義主機名加域名，即網站地址

        #charset koi8-r; # 默認字符集

        #access_log logs/host.access.log main; # 訪問日志路徑

        location / {                        # location容器，即URI的根
            root   html;                    # 站點根目錄，即DocumentRoot，相對路徑時為<prefix>/html
            index  index.html index.htm;    # 站點主頁文件
        }

        #error_page 404 /404.html; # 出現404 page not fount錯誤時，使用/404.html頁響應客戶端

        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;      # 出現50x錯誤時，使用/50x.html頁返回給客戶端
        location = /50x.html {                        # 定義手動輸入包含/50x.html時的location
            root   html;
        }

        # deny access to .htaccess files, if Apache's document root
        # concurs with nginx's one
        #
        #location ~ /\.ht {
        # deny all;
        #}
    }
    # another virtual host using mix of IP-, name-, and port-based configuration
    #
    #server {
    # listen 8000;
    # listen somename:8080;
    # server_name somename alias another.alias;

    # location / {
    # root html;
    # index index.html index.htm;
    # }
    #}
}

5.2.2 root指令和alias指令

root指令設置站點根目錄，即httpd的documentroot，但又有所不同，因為nginx可以在多個上下文位置處使用root指令，例如Location容器中。

如果配置如下：

location /i/ {
    root /data/w3;
}

那么nginx將使用文件/data/w3/i/top.gif響應請求"/i/top.gif"。

root指令僅僅只是將匹配的URI追加在root路徑后，如果要改變URI，應該使用alias指令，它會對URI進行替換。例如：

location /i/ {
    alias /data/w3/images/;
}

那么nginx將使用文件/data/w3/images/top.gif響應請求/i/top.gif。因此，如果alias指令的路徑最后一部分包含了URI，則最好使用root指令，而非alias指令，雖然它們都能成功響應。

location /images/ {
    alias /data/w3/images/;
}

location /images/ {
    root /data/w3/;
}

它們都能使用相對路徑，相對的是prefix。例如編譯路徑為/usr/local/nginx，則"root html"指的是"/usr/local/nginx/html"。

與root和alias指令相關的變量為$document_root、$realpath_root。其中$document_root的值即是root指令、alias指令的值，而$realpath_root的值是對root、alias指令進行絕對路徑換算后的值。

5.2.3 location容器

該指令對規范化后的URI進行匹配，並對匹配的路徑封裝一系列指令。 語法：

location [ = | ~ | ~* | ^~ ] uri { ... }

其中： location /uri/ {}：表示對/uri/目錄及其子目錄下的所有文件都匹配。所以"location / {}"的匹配范圍是最大的。
location = /uri/ {}：表示只對目錄或文件進行匹配，不對目錄中的文件和子目錄進行匹配。所以一般只用來做文件匹配
location ~ /uri/ {}：表示區分大小寫的正則匹配。
location ~* /uri/ {}：表示不區分大小寫的正則匹配。
location ^~ /uri/ {}：表示禁用正則匹配，即精確字符串匹配，此時正則中的元字符被解釋成普通字符。

它們的匹配優先級規則為：nginx先檢查URI的前綴路徑，在這些路徑中找到最精確匹配請求URI的路徑。然后nginx按在配置文件中的出現順序檢查正則表達式路徑，匹配上某個路徑后即停止匹配並使用該路徑的配置，否則使用最大前綴匹配的路徑的配置。

使用"="前綴可以定義URI和路徑的精確匹配。如果發現匹配，則終止路徑查找。例如請求"/"很頻繁，定義"location = /"可以提高這些請求的處理速度，因為查找過程在第一次比較以后即結束。

以下是一個優先級的示例。

location = / {
    [ configuration A ]
}

location / {
    [ configuration B ]
}

location /documents/ {
    [ configuration C ]
}

location ^~ /images/ {
    [ configuration D ]
}

location ~* \.(gif|jpg|jpeg)$ { 
    [ configuration E ] 
}

請求"/"能匹配A和B，但最精確匹配為A。
請求"/index.html"的前綴"/"能匹配A和B，但A只能匹配"/"自身，因此最終匹配配置B。(前綴也能匹配E，但文件名無法匹配)
請求"/documents/document.html"的前綴能匹配B和C，但C更精確，因此匹配配置C。(前綴也能匹配E，但文件名無法匹配)
請求"/images/1.gif"的前綴能匹配B、D和E，且D和E都是最長路徑匹配，但^~優先級更高，因此匹配配置D。
請求"/documents/1.jpg"的前綴能匹配B、C，同樣也能匹配E，且E比B的匹配更精確，因此最終匹配配置E。

大致可以將規則簡化為如下優先級：

(location = uri ) > (location ^~ uri) > (location *~|~ uri) > (location uri)

即等號優先級最高，非正則匹配次之，再之后是正則匹配，它們之間有位置的先后順序，優先級最低的是沒有使用任何符號的匹配。

由此也可以知道，"location / {}"這種方式是一種特殊的uri匹配，無論什么uri路徑，都能往這里面裝，可以認為它是默認匹配，當其它location都匹配不上時就會匹配它。

5.2.4 error_page指令

當出現對應狀態碼的錯誤時，指定返回的URI路徑。語法為：

error_page code ... [=[response]] uri;

配置文件中的error_page部分默認為：

location / {
    root   html;
    index  index.html index.htm;
}
#error_page 404 /404.html;
error_page   500 502 503 504  /50x.html;
location = /50x.html {
    root   html;
}

上面的配置文件中，假如取消了404錯誤的error_page行注釋，當出現404錯誤時，其uri為/404.html，然后會對其進行location的匹配，由於只有"location / {}"能匹配到，所以它的目錄為<prefix>/html/，即404.html文件路徑為<prefix>/html/404.html。對於50x的error_page，其uri為"/50x.html"，所以會對其進行location匹配，發現可以精確匹配到"location = /50x.html {}"，當然"location / {}"也能匹配到，但是它的優先級更低，所以當出現50x錯誤時，將從<prefix>/html目錄下尋找50x.html，這里正好和"location / {}"重復了，但它們的匹配過程是不一樣的。假如改為如下配置：

location / {                         
    root   html;                     
    index  index.html index.htm;     
}
#error_page 404 /404.html;
error_page   500 502 503 504  /50x.html;
location = /50x.html {
    root   /www/a.com/;
}

出現50x錯誤時，將返回/www/a.com/50x.html文件，而不再是<prefix>/html/50x.html。

5.2.5 allow和deny

這兩個指令由ngx_http_access_module模塊提供，用於允許或限制某些IP地址的客戶端訪問。nginx中的allow和deny規則很簡單，從上向下匹配，只要匹配到就停止。例如：

allow 10.0.0.8
allow 192.168.100.0/24
deny all

允許10.0.0.8和192.168.100網段的訪問，其他的都拒絕。

5.2.6 add_header添加相應首部字段

用於在響應首部中添加字段。例如：

server {
    add_header RealPath $realpath_root;
}

將添加一個名為RealPath的字段，值為變量realpath_root的值。

[root@xuexi ~]# curl -I http://localhost/
HTTP/1.1 200 OK
Server: nginx/1.12.1
Date: Tue, 17 Oct 2017 08:10:14 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 17 Oct 2017 03:20:10 GMT
Connection: keep-alive
ETag: "59e576ea-264"
RealPath: /usr/local/nginx-1.12.1/html   # 此為自定義添加字段
Accept-Ranges: bytes

5.3 虛擬主機和server_name指令

nginx使用server容器定義一個虛擬主機。在nginx中，沒有嚴格區分基於IP和基於名稱的虛擬主機，它們通過listen指令和server_name指令結合起來形成不同的虛擬主機。

例如：

# 基於IP地址的虛擬主機
server {
        listen 80;
        server_name 192.168.100.25;
        location / {
                root /www/longshuai/;
                index index.html index.htm;
        }
}
server {
        listen 80;
        server_name 192.168.100.26;
        location / {
                root /www/xiaofang/;
                index index.html index.htm;
        }
}

# 基於名稱的虛擬主機
server {
        listen 80;
        server_name www.longshuai.com;
        location / {
                root /www/longshuai/;
                index index.html index.htm;
        }
}
server {
        listen 80;
        server_name www.xiaofang.com;
        location / {
                root /www/xiaofang/;
                index index.html index.htm;
        }
}

# 基於端口的虛擬主機
server {
        listen 80;
        server_name 192.168.100.25;
        location / {
                root /www/longshuai/;
                index index.html index.htm;
        }
}
server {
        listen 8080;
        server_name 192.168.100.25;
        location / {
                root /www/xiaofang/;
                index index.html index.htm;
        }
}

其中server_name指令可以定義多個主機名，第一個名字為虛擬主機的首要主機名。例如：

server_name  example.com   www.example.com;

主機名中可以含有星號("*")，以替代名字的開始部分或結尾部分(只能是起始或結尾，如果要實現中間部分的通配，可以使用正則表達式)。例如"*.example.org"不僅匹配www.example.org，也匹配www.sub.example.org。下面兩條指令是等價的。

server_name    example.com   *.example.com   www.example.*;
server_name   .example.com   www.example.*;

也可以在主機名中使用正則表達式，就是在名字前面補一個波浪線("~")：

server_name   www.example.com   ~^www\d+\.example\.com$;

nginx允許定義空主機名：

server {
    listen       80;
    server_name  "";
    return       444;
}

這種主機名可以讓虛擬主機處理沒有"Host"首部的請求，而不是讓指定"地址:端口"的默認虛擬主機來處理，而這正是本指令的默認設置。即使用非默認的虛擬主機處理請求頭中不含"Host"字段的請求。一般這樣的請求處理方式是直接丟棄請求，並返回一個非標准的狀態碼來立即關閉連接，例如上面的444。

如果server塊中沒有定義server_name，nginx使用空名字作為虛擬主機名。

5.4 虛擬主機的匹配規則

通過名字查找虛擬主機時，如果一個名字可以匹配多個指定的配置，比如同時匹配上通配符和正則表達式，按下面優先級，使用先匹配上的虛擬主機：

  1. 確定的名稱；
  2. 最長的以星號起始的通配符名字，比如"*.example.com"；
  3. 最長的以星號結束的通配符名字，比如"mail.*"；
  4. 第一個匹配的正則表達式名字(按在配置文件中出現的順序)。

當開始接入請求時，(1)nginx首先判斷請求的套接字，即IP和端口號；(2)然后在listen套接字中選擇一個能匹配名稱的虛擬主機，如果沒有選出能匹配的名稱，則使用該套接字的默認虛擬主機。默認情況下，監聽套接字的默認虛擬主機為該套接字主機組中的第一個虛擬主機，但可以通過listen指令的default_server屬性手動指定。

例如下面定義了4個虛擬主機：前3個都監聽在192.168.100.1:80上，第四個監聽在192.168.1.2:80上。

server {
    listen      192.168.100.1:80;
    server_name example.org www.example.org;
    ...
}

server {
    listen      192.168.100.1:80 default_server;
    server_name example.net www.example.net;
    ...
}

server {
    listen      192.168.100.1:80;
    server_name example.com www.example.com;
    ...
}

server {
    listen      192.168.1.2:80;
    server_name example.com www.example.com;
    ...
}

(1).從192.168.100.1:80上請求www.example.com，能匹配虛擬主機3，於是使用虛擬主機3的配置進行響應；
(2).從192.168.100.1:80上請求www.longshuai.com時，無法匹配任何虛擬主機，於是使用默認虛擬主機2的配置進行響應。如果將listen的屬性default_server去掉，則使用虛擬主機1進行響應；
(3).從192.168.100.2:80上請求www.example.com時，使用虛擬主機4進行響應；
(4).從192.168.100.2:80上請求www.example.org時，由於無法匹配該套接字上的任何主機，於是使用默認虛擬主機響應，即虛擬主機4。

5.5 stub_status指令獲取nginx狀態信息

使用ngx_http_stub_status_module模塊提供的功能可以獲取nginx運行的狀態信息。對應的指令只有一個，即stub_status。

例如，在某一個server下加上如下配置獲取該server的狀態信息。

server {
    listen 80;
    server_name www.longshuai.com;
    location / {
        root /www/longshuai/;
        index index.html index.htm;
    }
    location /status {
        stub_status on;
    }
}

還可以明確指定訪問該信息不記錄日志，且提供訪問控制，不讓外界人隨意獲取信息。

location /status {
    stub_status on;
    access_log off;
    allow 192.168.100.0/24;
    deny all;
}

重載配置文件后，只需在瀏覽器中輸入"主機名/status"即可獲取信息。

Active connections: 291 
server accepts handled requests
 16630948 16630948 31070465 
Reading: 6 Writing: 179 Waiting: 106

狀態信息意義如下：

  • 第一行active connections:291表示當前處於活動狀態的客戶端連接數，包括正處於等待狀態的連接。
  • 第四行reading數量為6，表示nginx正在讀取請求首部的數量，即正在從socket recv buffer中讀取數據的數量；writing數量為179表示nginx正在將響應數據寫入socket send buffer以返回給客戶端的連接數量；waiting數量為106表示等待空閑客戶端發起請求的客戶端數量，包括長連接狀態的連接以及已接入但socket recv buffer還未產生可讀事件的連接，其值為active-reading-writing。
  • 第二行accepts的數量為16630948表示從服務啟動開始到現在已經接收進來的總的客戶端連接數；handled的數量為16630948表示從服務啟動以來已經處理過的連接數，一般handled的值和accepts的值相等，除非作出了連接數限定；requests的數量為服務啟動以來總的客戶端請求數。一個連接可以有多個請求，所以可以計算出平均每個連接發出多少個請求。
  • 以下是第二行幾個參數的官方原文： 
    accepts：The total number of accepted client connections.
handled：The total number of handled connections. Generally, the parameter value is the same as accepts unless some resource limits have been reached (for example, the worker_connections limit).
requests：The total number of client requests.

6.訪問日志access_log

  1. nginx的訪問日志相關功能由ngx_http_log_module模塊提供，指令包括log_format、access_log和open_log_file_cache。
  2. nginx的日志可以先緩沖到buffer中，一定時間后再寫入到日志文件中。從buffer刷盤到本地日志文件中時，可以進行壓縮。
  3. nginx的worker進程的運行身份需要有日志創建的權限，即對日志所在目錄有寫權限。
  4. 可以在多種上下文中定義是否開啟日志以及日志的格式。最常見的三個上下文是http,server,location。
  5. open_log_file_cache指令存在的意義是為了緩存日志文件描述符。之所以提供這個指令，是因為nginx每次日志的寫入(從緩存中刷盤到本地日志文件中)都會打開、關閉一次日志文件。對於日志寫入極其頻繁的機器可以使用該指令緩存日志文件描述符，使得在緩存有效期內都可以續寫到舊日志文件中。

6.1 log_format指令

log_format指定日志的格式，語法如下：log\_format name string...;。其中name指定日志格式名稱，配置文件中name名稱不能重復。

以下是默認提供的main格式。

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

在main后面的是一堆變量，除了這些變量之外還有其他很多變量可用，但如非特殊需求，默認的main格式就已經夠完美了。以下是變量的意義：

$remote_addr：客戶端的地址。如果nginx提供的web服務在后端，如前面有代理服務器或負載均衡等設備時，該變量只能獲取到前端的IP地址。此時要獲取到真正客戶端地址需要使用變量$http_x_forward_for，但要求前端服務器要開啟x_forward_for設置。
$http_x_forward_for：如上所述。
$remote_user：遠程客戶端用戶名稱。
$time_local：記錄訪問時間和時區信息。
$request：記錄用戶訪問時的url和http協議信息。如："GET /favicon.ico HTTP/1.1"。
$status：記錄客戶端請求時返回的狀態碼，如成功的狀態碼為200，page not found的狀態碼為404。
$body_bytes_sent：記錄服務器響應給客戶端的主體大小。
$http_referer：記錄此次請求是從哪個鏈接過來的，需要模塊ngx_http_referer_module支持，默認已裝，可以防止倒鏈問題。
$http_user_agent：記錄客戶端的瀏覽器信息。如使用什么瀏覽器發起的請求，是否是壓力測試工具在測試等。

例如，以下是默認格式的日志信息。

192.168.100.27 - - [23/Apr/2017:23:08:56 +0800] "GET /index.html HTTP/1.0" 200 17 "-" "ApacheBench/2.3"
192.168.100.27 - - [23/Apr/2017:23:08:56 +0800] "GET /index.html HTTP/1.0" 200 17 "-" "ApacheBench/2.3"
192.168.100.27 - - [23/Apr/2017:23:08:56 +0800] "GET /index.html HTTP/1.0" 200 17 "-" "ApacheBench/2.3"
192.168.100.27 - - [23/Apr/2017:23:08:56 +0800] "GET /index.html HTTP/1.0" 200 17 "-" "ApacheBench/2.3"
192.168.100.1 - - [23/Apr/2017:23:08:56 +0800] "GET /status HTTP/1.1" 200 109 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko"
192.168.100.1 - - [23/Apr/2017:23:08:56 +0800] "GET /status HTTP/1.1" 200 109 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko"
192.168.100.1 - - [23/Apr/2017:23:08:56 +0800] "GET /status HTTP/1.1" 200 109 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko"
192.168.100.27 - - [23/Apr/2017:23:08:57 +0800] "GET /index.html HTTP/1.0" 200 17 "-" "ApacheBench/2.3"
192.168.100.27 - - [23/Apr/2017:23:08:57 +0800] "GET /index.html HTTP/1.0" 200 17 "-" "ApacheBench/2.3"
192.168.100.27 - - [23/Apr/2017:23:08:57 +0800] "GET /index.html HTTP/1.0" 200 17 "-" "ApacheBench/2.3"

6.2 access_log指令

access_log主要用於定義使用什么格式的日志，日志存放路徑。語法如下：

access_log path [format [buffer=size] [gzip[=level]] [flush=time] [if=condition]];
access_log off;

path指定路徑，path里可以使用變量。format指定日志格式，不寫時或者配置文件中未配置access_log指令時，默認為combined。buffer=size指定日志緩沖區大小(默認64K)，flush=time指定日志刷盤的時間，if=condition指定某些條件，gzip=level指定日志刷盤前先壓縮的壓縮級別(默認gzip=1)。

當指定了buffer或者gzip任意一個時，都會使用buffer先緩沖日志，然后再刷盤。

例如

access_log /spool/logs/nginx-access.log gzip buffer=32k;

6.3 日志文件的分割

默認nginx不會自動分割日志，也不支持在配置文件中使用cronolog以及rotatelogs(apache支持，因為支持管道傳遞)。要實現nginx的日志分割，需要通過移動舊日志、生成新日志來實現。

mv old_log new_log
# 然后
nginx -s reload
# 或者
nginx -s reopen
# 或者
kill -s USR1 master_pid

pid可以通過pid文件獲得。

kill -s USR1 $(cat /var/run/nginx/nginx.pid)

要實現自動分割，需要使用腳本，並設置定時任務。

cat /usr/local/nginx/logs/cut_longhsuai.sh
#!/bin/bash 
# cut the access log for www.longshuai.com

basedir=/usr/local/nginx
old_log_path=$basedir/logs/access.log
log_save_path=$basedir/logs
save_log_name=access_$(date -d "yesterday" +"%Y%m%d").log

[ -f "$old_log_path" ] || exit 1
/bin/mv $old_log_path $log_save_path/$save_log_name
$basedir/sbin/nginx -s reopen

再添加定時任務計划。

chmod +x /usr/local/nginx/logs/cut_longshuai.sh

crontab -e
00 00 * * * /bin/sh /usr/local/nginx/logs/cut_longshuai.sh &>/dev/null

7.配置web身份認證

需要輸入用戶名和密碼才能訪問站點的功能為web身份認證功能。nginx中由ngx_http_auth_basic_module模塊提供該功能。指令包括auth_basic和auth_basic_user_file。這兩個指令可以在http根段、server段、location段使用。

auth_basic string | off
auth_basic_user_file path/to/user_passwd_file        # 密碼文件使用相對路徑時是相對conf目錄的

passwd_file的格式為:

user1:passwd1
user2:passwd2

需要注意的是，密碼文件不能使用明文密碼的方式。該類文件一般使用apache提供的工具htpasswd生成，該工具在httpd-tools包中，具體用法見htpasswd命令。也可以使用openssl passwd生成相關密碼然后復制到密碼文件中。以下是一個示例：

server {
    listen 80;
    server_name www.longshuai.com  www1.longshuai.com;
    location / {
        root /www/longshuai/;
        index index.html index.htm;
        auth_basic "Auth your name";
        auth_basic_user_file /usr/local/nginx/htpasswd;
    }
}

然后使用htpasswd生成密碼文件/usr/local/nginx/conf/htpasswd。

yum -y install httpd-tools htpasswd -b -c -m /usr/local/nginx/conf/htpasswd Jim 123456 htpasswd -b -m /usr/local/nginx/conf/htpasswd Tom 123456

-b選項是表示batch模式，不用交互輸入密碼。-c表示創建密碼文件，只能為第一個用戶使用該選項，否則后面使用會覆蓋前面已經創建過的。-m表示強制使用md5。Jim和Tom是需要驗證的用戶名，123456是密碼。查看生成的密碼文件。

[root@xuexi nginx]# cat htpasswd 
Jim:$apr1$URdS8lcY$GyghBlYInlqfkto0ndnH1.
Tom:$apr1$B/orDxHj$1jIWk1X5XabpH3hcFQzoN1

然后重載配置文件，在瀏覽器中測試。測試時最好不要用IE。

也可以使用openssl passwd生成，下面的"-apr1"(數值1而非字母L的小寫)選項是為apache密碼做相關支持的。

openssl passwd -apr1 123456
$apr1$rD/3/kFH$L8KYfzAWFtHO8mOiR9dci1
# 或者加點鹽
openssl passwd -apr1 -salt 'xyz' 123456
$apr1$xyz$j0n99G44SENB4NmJiwEfJ0

然后將得到的密碼復制到密碼文件中對應的用戶名后面即可。如將得到的"$apr1$xyz$j0n99G44SENB4NmJiwEfJ0"作為"Admin"用戶的驗證密碼。

Admin: $apr1$xyz$j0n99G44SENB4NmJiwEfJ0

8.配置https

https功能由ngx_http_ssl_module模塊提供。https連接的認證過程見SSL握手機制。簡單版的過程如下：

  1. 客戶端say hello，並發送一個隨機數給服務端。
  2. 服務端say hello，並回復一個隨機數給客戶端。
  3. 服務端發送數字證書給客戶端。
  4. 客戶端使用信任的CA公鑰解密數字證書得到服務端的公鑰。
  5. 客戶端使用服務端的公鑰加密一個預備主密鑰並發送給服務端。
  6. 服務端使用自己的私鑰解密預備主密鑰。
  7. 雙方都得到了2個隨機數加一個預備主密鑰。通過這3個隨機數形成一個會話主密鑰，即session key。至此ssl握手結束，連接的認證過程也完畢。

對於服務端而言，在配置https時，需要提供自己的數字證書用於發送給客戶端，還要提供自己的私鑰用於解密客戶端發送的預備主密鑰。當ssl連接建立完成后，后續連接要傳輸的數據都采用session key進行加密，但注意session key是對稱加密，客戶端和服務端是一樣的。

還需注意，在創建證書請求時，由於需要指定common name，這是需要使用https的站點，因此每個ssl證書只能為一個server_name提供https服務。不過，通過特殊的配置方法，也能讓一個ssl證書服務於整個域名或域名內的某些主機。例如，https://www.baidu.com使用的證書就是頒發給"baidu.com"的，而不是該域名下的某一台主機。如何實現這樣的功能，可以網上搜索下關鍵字"ssl SubjectAltName"，若有需要，我會另開一篇文章介紹實現方法。

以下是配置文件中默認的關於SSL相關的指令設置。

#server {
# listen 443 ssl;
# server_name localhost;

# ssl_certificate cert.pem;
# ssl_certificate_key cert.key;

# ssl_session_cache shared:SSL:1m;
# ssl_session_timeout 5m;

# ssl_ciphers HIGH:!aNULL:!MD5;
# ssl_prefer_server_ciphers on;

# location / {
# root html;
# index index.html index.htm;
# }
#}

以下是建立https的相關過程:

  1. 自建CA。 
    cd /etc/pki/CA
(umask 077;openssl genrsa -out private/cakey.pem 2048)
openssl req -new -x509 -key private/cakey.pem -out cacert.pem -days 3650
  2. 建立相關序列和索引文件。 
    touch index.txt
echo "01" > serial
  3. nginx端生成證書請求。 
    (umask 077;openssl genrsa -out /usr/local/nginx/longshuai.key 2048)
openssl req -new -key /usr/local/nginx/longshuai.key -out /usr/local/nginx/longshuai.csr
  4. CA為證書請求頒發證書。 
    openssl ca -in /usr/local/nginx/longshuai.csr -out longshuai.crt
  5. 將頒發的證書發送給nginx端。這里由於CA和nginx在同一主機上，所以直接移動即可。 
    mv longshuai.crt /usr/local/nginx/
    此時，在/usr/local/nginx/目錄下就有了nginx自己的私鑰文件和證書文件。 
    [root@xuexi nginx]# ls longshuai*
longshuai.crt  longshuai.csr  longshuai.key

  6. 修改配置文件，配置ssl相關選項。

    server {
listen       443 ssl;
server_name  www.longshuai.com;

ssl_certificate      /usr/local/nginx/longshuai.crt;
ssl_certificate_key  /usr/local/nginx/longshuai.key;

ssl_session_cache    shared:SSL:1m;
ssl_session_timeout  5m;

ssl_ciphers  HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers  on;

location / {
    root   html;
    index  index.html index.htm;
}
}
  7. 重載配置文件。
  8. 測試。在瀏覽器上輸入https://www.longshuai.com測試。將會提示證書安全存在問題，說明配置成功。以后只要在客戶端安裝證書即可正常訪問。測試時，建議使用IE瀏覽器或使用IE內核的瀏覽器測試，這樣比較直觀。使用firefox、chrome等瀏覽器可能會因為是自建的CA而出現一些問題。


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 nginx.conf詳解 nginx.conf 配置詳解 nginx.conf指令詳解 nginx.conf文件配置明細詳解 nginx中conf下的nginx.conf詳解 ubuntu 13.04 nginx.conf 配置詳解 Nginx.conf參數配置詳解 nginx.conf文件內容詳解 nginx.conf文件詳解及調優 nginx.conf配置
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM