初探nginx架構以及配置

時間 2020-02-18

標籤初探 nginx 架構以及配置欄目 Nginx 简体版

原文原文鏈接

一、nginx特性以及功能php

二、nginx的架構及工做過程html

三、nginx做爲web服務器的配置node

1、nginx特性以及功能nginx

Nginx是一款輕量級的Web 服務器/反向代理服務器及電子郵件（IMAP/POP3）代理服務器，並在一個BSD-like 協議下發行。由俄羅斯的程序設計師Igor Sysoev所開發，供俄國大型的入口網站及搜索引擎Rambler（俄文：Рамблер）使用。其特色是佔有內存少，併發能力強，事實上nginx的併發能力確實在同類型的網頁服務器中表現較好，中國大陸使用nginx網站用戶有：百度、京東、新浪、網易、騰訊、淘寶等。web

nginx特性：正則表達式

基本功能：算法

靜態資源的web服務器，能緩存打開的文件描述符；apache

反向代理服務器，緩存、負載均衡；編程

支持FastCGIc#

模塊化，非DSO機制，過濾器gzip，SSI和圖像大小調整等

支持SSL

擴展功能：

基於名稱和IP作虛擬主機

支持keepalive

支持平滑配置更新或程序版本升級

定製訪問日誌，支持使用日誌緩存以提升性能

支持url rewrite

支持路徑別名

支持基於IP及用戶的認證；

支持速率限制，併發限制等；

2、nginx的架構及工做過程（nginx爲何能輕量高效工做）

一、nginx的工做模型

nginx的基本架構：

一個master, 生成一個或多個worker

事件驅動：kqueue, epoll, /dev/poll

消息通知：select, poll, rt signals

支持sendfile, sendfile64

文件AIO

支持mmap

nginx是一個非阻塞、事件驅動、一個master多個worker，一個worker響應多個用戶請求的模型

二、nginx的進程處理過程

nginx在啓動後，在unix系統中會以daemon的方式在後臺運行，後臺進程包含一個master進程和多個worker進程。

master進程主要用來管理worker進程，包含：接收來自外界的信號，向各worker進程發送信號，監控worker進程的運行狀態，當worker進程退出後(異常狀況下)，會自動從新啓動新的worker進程。

　　worker進程則是處理基本的網絡事件。多個worker進程之間是對等的，他們同等競爭來自客戶端的請求，各進程互相之間是獨立的。一個請求，只可能在一個worker進程中處理，一個worker進程，不可能處理其它進程的請求。

　　worker進程的個數是能夠設置的，通常咱們會設置與機器cpu核數一致。更多的worker數，只會致使進程來競爭cpu資源了，從而帶來沒必要要的上下文切換。並且，nginx爲了更好的利用多核特性，具備cpu綁定選項，咱們能夠將某一個進程綁定在某一個核上，這樣就不會由於進程的切換帶來cache的失效。

三、nginx如何避免驚羣效應

驚羣現象：

　　每一個worker進程都是從master進程fork過來。在master進程裏面，先創建好須要listen的socket以後，而後再fork出多個worker進程，這樣每一個worker進程均可以去accept這個socket(固然不是同一個socket，只是每一個進程的這個socket會監控在同一個ip地址與端口，這個在網絡協議裏面是容許的)。通常來講，當一個鏈接進來後，全部在accept在這個socket上面的進程，都會收到通知，而只有一個進程能夠accept這個鏈接，其它的則accept失敗。

nginx如何避免驚羣效應：

nginx提供了accept_mutex，從名字上，咱們能夠看這是一個加在accept上的一把共享鎖。有了這把鎖以後，同一時刻，就只會有一個進程在accpet鏈接，這樣就不會有驚羣問題了。accept_mutex是一個可控選項，咱們能夠顯式地關掉，默認是打開的。當一個worker進程在accept這個鏈接以後，就開始讀取請求，解析請求，處理請求，產生數據後，再返回給客戶端，最後才斷開鏈接，這樣一個完整的請求就是這樣的了。咱們能夠看到，一個請求，徹底由worker進程來處理，並且只在一個worker進程中處理。

那麼，nginx採用這種進程模型有什麼好處呢？固然，好處確定會不少了。首先，對於每一個worker進程來講，獨立的進程，不須要加鎖，因此省掉了鎖帶來的開銷，同時在編程以及問題查找時，也會方便不少。其次，採用獨立的進程，可讓互相之間不會影響，一個進程退出後，其它進程還在工做，服務不會中斷，master進程則很快從新啓動新的worker進程。

所以啓動work的個數應該小於或等於CPU的個數，避免引發資源的競爭。

四、nginx的異步非阻塞工做機制

傳統的基於進程和線程的模型在處理併發鏈接的時候針對每一個鏈接會調用一個獨立的進程或線程，而且阻塞在網絡或I/O操做上面。根據應用程序的不一樣，它們對內存和CPU的使用效率很是低。產生一個新的進程或線程須要一個新的運行時環境，包括堆和棧的分配，以及運行時的上下文。所以須要額外的CPU開銷來建立這些環境，過多的線程以及上下文切換最終會致使性能的降低。全部這些情況在Apache上均可以見到。

Nginx從一開始就旨在成爲一個專門的工具來提升服務器的性能，密度和以及資源利用率，同時保證網站的動態增加，所以Nginx採起了不一樣的模型。它的設計靈感來自於各類各樣的操做系統中不斷髮展的基於事件的機制。所以，模塊化，事件驅動，異步，單線程，非阻塞的架構成爲了nginx的基石。

Nginx大量使用多路複用和事件通知，並將特定任務分配到獨立的進程。Nginx經過一個高效率的、數量有限的單線程進程的運行環(worker)來處理鏈接。正是在內部有這些worker，Nginx才能處理每秒成千上萬的併發鏈接。

nginx採用了異步非阻塞的方式來處理請求，也就是說，nginx是能夠同時處理成千上萬個請求的。想一想apache的經常使用工做方式（apache也有異步非阻塞版本，但因其與自帶某些模塊衝突，因此不經常使用），每一個請求會獨佔一個工做線程，當併發數上到幾千時，就同時有幾千的線程在處理請求了。這對操做系統來講，是個不小的挑戰，線程帶來的內存佔用很是大，線程的上下文切換帶來的cpu開銷很大，天然性能就上不去了，而這些開銷徹底是沒有意義的。

爲何nginx能夠採用異步非阻塞的方式來處理呢，或者異步非阻塞究竟是怎麼回事呢？咱們先回到原點，看看一個請求的完整過程。首先，請求過來，要創建鏈接，而後再接收數據，接收數據後，再發送數據。具體到系統底層，就是讀寫事件，而當讀寫事件沒有準備好時，必然不可操做，若是不用非阻塞的方式來調用，那就得阻塞調用了，事件沒有準備好，那就只能等了，等事件準備好了，你再繼續吧。阻塞調用會進入內核等待，cpu就會讓出去給別人用了，對單線程的worker來講，顯然不合適，當網絡事件越多時，你們都在等待呢，cpu空閒下來沒人用，cpu利用率天然上不去了，更別談高併發了。

好吧，你說加進程數，這跟apache的線程模型有什麼區別，注意，別增長無謂的上下文切換？因此，在nginx裏面，最忌諱阻塞的系統調用了。不要阻塞，那就非阻塞嘍。非阻塞就是，事件沒有準備好，立刻返回EAGAIN，告訴你，事件還沒準備好呢，你慌什麼，過會再來吧。好吧，你過一會，再來檢查一下事件，直到事件準備好了爲止，在這期間，你就能夠先去作其它事情，而後再來看看事件好了沒。雖然不阻塞了，但你得不時地過來檢查一下事件的狀態，你能夠作更多的事情了，但帶來的開銷也是不小的。因此，纔會有了異步非阻塞的事件處理機制，具體到系統調用就是像select/poll/epoll/kqueue這樣的系統調用。

它們提供了一種機制，讓你能夠同時監控多個事件，調用他們是阻塞的，但能夠設置超時時間，在超時時間以內，若是有事件準備好了，就返回。這種機制正好解決了咱們上面的兩個問題，拿epoll爲例(在後面的例子中，咱們多以epoll爲例子，以表明這一類函數)，當事件沒準備好時，放到epoll裏面，事件準備好了，咱們就去讀寫，當讀寫返回EAGAIN時，咱們將它再次加入到epoll裏面。這樣，只要有事件準備好了，咱們就去處理它，只有當全部事件都沒準備好時，纔在epoll裏面等着。這樣，咱們就能夠併發處理大量的併發了，固然，這裏的併發請求，是指未處理完的請求，線程只有一個，因此同時能處理的請求固然只有一個了，

只是在請求間進行不斷地切換而已，切換也是由於異步事件未準備好，而主動讓出的。這裏的切換是沒有任何代價，你能夠理解爲循環處理多個準備好的事件，事實上就是這樣的。與多線程相比，這種事件處理方式是有很大的優點的，不須要建立線程，每一個請求佔用的內存也不多，沒有上下文切換，事件處理很是的輕量級。併發數再多也不會致使無謂的資源浪費（上下文切換）。更多的併發數，只是會佔用更多的內存而已。我以前有對鏈接數進行過測試，在24G內存的機器上，處理的併發請求數達到過200萬。如今的網絡服務器基本都採用這種方式，這也是nginx性能高效的主要緣由。

更多文章請關注個人博客

3、nginx做爲web服務器的配置

一、nginx的安裝

默認base源中並無nginx的安裝文件，epel源纔有，可使用官方提供的預編譯的rpm直接安裝，也能夠編譯安裝

nginx的安裝配置：

官方的預製包：

http://nginx.org/packages/centos/7/x86_64/RPMS/

編譯安裝：

# yum install pcre-devel openssl-devel zlib-devel

# useradd -r nginx

#  ./configure --prefix=/usr/local/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --user=nginx --group=nginx --with-http_ssl_module --with-http_v2_module --with-http_dav_module --with-http_stub_status_module --with-threads --with-file-aio

# make && make install

二、nginx的配置

配置文件的組成部分：

主配置文件：nginx.conf

include conf.d/*.conf

fastcgi， uwsgi，scgi等協議相關的配置文件

mime.types：支持的mime類型

注意：

(1) 指令必須以分號結尾；

(2) 支持使用配置變量；

內建變量：由Nginx模塊引入，可直接引用；

自定義變量：由用戶使用set命令定義；

set variable_name value;

引用變量：$variable_name

主配置文件結構：

main block：主配置段，也即全局配置段；

event {

...

}：事件驅動相關的配置；

http {

...

}：http/https 協議相關的配置段；

[root@localhost ~]# grep -v "^[[:space:]]*#" /etc/nginx/nginx.conf |grep -v '^$'
worker_processes  1;  #main段
events {#event段
    worker_connections  1024;
}
http {     #http段
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    server {
        listen       80;
        server_name  localhost;
        location / {
            root   html;
            index  index.html index.htm;
        }
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }
}

下面來對配置按照已得的功能來進行分類概括：

nginx的配置（main）：

正常運行的配置：
一、user username [groupname];
    指定運行worker進程的用戶和組
二、pid /path/to/pidfile_name;
    指定nginx的pid文件
三、worker_rlimit_nofile #;
    指定一個worker進程所可以打開的最大文件句柄數；
四、worker_rlimit_sigpending #;
    設定每一個用戶可以發往worker進程的信號的數量；
優化性能相關的配置：
一、worker_processes #;
    worker進程的個數；一般其數值應該爲CPU的物理核心數減1；
二、worker_cpu_affinity cpumask ...;
0000
0001
0010
0100
1000
0011：表示第一和第二顆 
worker_processes 6; 
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000; 
三、ssl_engine device;
    在存在ssl硬件加速器的服務器上，指定所使用的ssl硬件加速設備；
四、timer_resolution t;
    每次內核事件調用返回時，都會使用gettimeofday()來更新nginx緩存時鐘；timer_resolution用於定義每隔多久纔會由gettimeofday()更新一次緩存時鐘；x86-64系統上，gettimeofday()代價已經很小，能夠忽略此配置；
五、worker_priority nice;
    -20,19之間的值；

事件相關的配置

一、accept_mutex [on|off]
    是否打開Ningx的負載均衡鎖；此鎖可以讓多個worker進輪流地、序列化地與新的客戶端創建鏈接；而一般當一個worker進程的負載達到其上限的7/8，master就儘量再也不將請求調度此worker；
二、lock_file /path/to/lock_file; 
    lock文件
三、accept_mutex_delay #ms;
    accept鎖模式中，一個worker進程爲取得accept鎖的等待時長；若是某worker進程在某次試圖取得鎖時失敗了，至少要等待#ms才能再一次請求鎖；
四、multi_accept on|off;
    是否容許一次性地響應多個用戶請求；默認爲Off; 
五、use [epoll|rtsig|select|poll];
    定義使用的事件模型，建議讓nginx自動選擇；
六、worker_connections #;
    每一個worker可以併發響應最大請求數；

用於調試、定位問題: 只調試nginx時使用

一、daemon on|off;
    是否讓ningx運行後臺；默認爲on，調試時能夠設置爲off，使得全部信息去接輸出控制檯；
二、master_process on|off
    是否以master/worker模式運行nginx；默認爲on；調試時可設置off以方便追蹤；
三、error_log /path/to/error_log level;
    錯誤日誌文件及其級別；默認爲error級別；調試時可使用debug級別，但要求在編譯時必須使用--with-debug啓用debug功能；

nginx的http web功能：

必須使用虛擬機來配置站點；每一個虛擬主機使用一個server {}段配置；
server {
}
    非虛擬主機的配置或公共配置，須要定義在server以外，http以內；
http {
directive value;
...
    server {
    }
    server {
    }
...
}

虛擬主機相關的配置：

一、server {}
    定義一個虛擬主機；nginx支持使用基於主機名或IP的虛擬主機；
二、listen 
    listen address[:port];
    listen port 
    default_server：定義此server爲http中默認的server；若是全部的server中沒有任何一個listen使用此參數，那麼第一個server即爲默認server; 
    rcvbuf=SIZE: 接收緩衝大小；
    sndbuf=SIZE: 發送緩衝大小；
    ssl: https server；
三、server_name [...];
    server_name能夠跟多個主機名，名稱中可使用通配符和正則表達式(一般以~開頭)；當nginx收到一個請求時，會取出其首部的server的值，然後跟衆server_name進行比較；
    比較優先次序方式：
    (1) 先作精確匹配；www.magedu.com 
    (2) 左側通配符匹配；*.magedu.com
    (3) 右側通配符匹配；www.abc.com, www.*
    (4) 正則表達式匹配: ~^.*\.magedu\.com$
四、server_name_hash_bucket_size 32|64|128;
    爲了實現快速主機查找，nginx使用hash表來保存主機名；
五、(1)location [ = | ~ | ~* | ^~ ] uri { ... }
   (2)location @name { ... }
   功能：容許根據用戶請求的URI來匹配指定的各location以進行訪問配置；匹配到時，將被location塊中的配置所處理
   =：精確匹配；
   ~：正則表達式模式匹配，匹配時區分字符大小寫
   ~*：正則表達式模式匹配，匹配時忽略字符大小寫
   ^~: URI前半部分匹配，匹配時忽略字符大小寫。不檢查正則表達式
   
匹配優先級：
     = (大於) ^~ (大於) ~ (大於) 不帶符號
     
location / :表示以/開頭的URL均可以匹配

文件路徑定義：

一、root path
    設置web資源路徑；用於指定請求的根文檔目錄；
location / {
root /www/htdocs;（本機的文件路徑）
}
location ^~ /p_w_picpaths/ {
root /web;
}
root: root/URI/

二、alias path
    只能用於location中，用於路徑別名；
location / {
root /www/htdocs;
}
location ^~ /p_w_picpaths/ {
    alias /web;
}

三、index file ...;
    定義默認頁面，可參跟多個值；
    
四、error_page code ... [=[response]] uri;
    錯誤頁重定向：當對於某個請求返回錯誤時，若是匹配上了error_page指令中設定的code，則重定向到新的URI中。
錯誤頁面重定向；
    例：error_page   404  /404.html;當用戶請求一個不存在的資源是，會自動跳轉到自定義的404.html頁面。
注意跳轉的狀態碼仍是原來的狀態碼，即便是跳轉成功！

五、try_files path1 [path2 ...] uri;
    自左至右嘗試讀取由path所指定路徑，在第一次找到即中止並返回；若是全部path均不存在，則返回最後一個uri; 
       location ~* ^/documents/(.*)$ {
           root /www/htdocs;
           try_files $uri /docu/$1 /temp.html;
       }

網絡鏈接相關的設置：

一、keepalive_timeout time;
    保持鏈接的超時時長；默認爲75秒,0表示禁止長鏈接；
二、keepalive_requests n;
    在一次長鏈接上容許承載的最大請求數；
三、keepalive_disable [msie6 | safari | none ]
    對指定的瀏覽器禁止使用長鏈接；
四、tcp_nodelay on|off
    對keepalive鏈接是否使用TCP_NODELAY選項；啓用該選項表示即便請求的數據很小也會發送，不用等湊數才發送。
五、client_header_timeout time; 
    讀取http請求首部的超時時長；
六、client_body_timeout time;
    讀取http請求包體的超時時長；
七、send_timeout time;
    發送響應報文的超時時長；

對客戶端請求的限制：

一、limit_except method ... { ... }
    指定對範圍以外的其它方法的訪問控制；
limit_except GET {
    allow 172.16.0.0/16;
    deny all; 
}
二、client_max_body_size SIZE;
    http請求包體的最大值；經常使用於限定客戶所可以請求的最大包體；根據請求首部中的Content-Length來檢測，以免無用的傳輸；
三、limit_rate speed;
    限制客戶端每秒鐘傳輸的字節數；默認爲0，表示沒有限制；
四、limit_rate_after time;
    nginx向客戶發送響應報文時，若是時長超出了此處指定的時長，則後續的發送過程開始限速；
五、用戶認證示例
location /admin/ {
            root /www/b.org;
            auth_basic "admin area";
            auth_basic_user_file /etc/nginx/.htpasswd;
        }

文件操做的優化：

一、sendfile on|off
    是否啓用sendfile功能；
二、aio on|off
    是否啓用aio功能；
三、open_file_cache max=N [inactive=time]|off
    是否打開文件緩存功能；
    max: 緩存條目的最大值；當滿了之後將根據LRU算法進行置換；
    inactive: 某緩存條目在指定時長時沒有被訪問過期，將自動被刪除；默認爲60s;
     
緩存的信息包括：
    文件句柄、文件大小和上次修改時間；
    已經打開的目錄結構；
    沒有找到或沒有訪問權限的信息；
四、open_file_cache_errors on|off
    是否緩存文件找不到或沒有權限訪問等相關信息；
五、open_file_cache_valid time;
    多長時間檢查一次緩存中的條目是否超出非活動時長，默認爲60s; 
六、open_file_cache_min_use #;
    在inactive指定的時長內被訪問超此處指定的次數地，纔不會被刪除；

對客戶端請求的特殊處理：

一、ignore_invalid_headers on|off
    是否忽略不合法的http首部；默認爲on; off意味着請求首部中出現不合規的首部將拒絕響應；只能用於server和http; 
二、log_not_found on|off
    是否將文件找不到的信息也記錄進錯誤日誌中；
三、resolver address;
    指定nginx使用的dns服務器地址；
四、resover_timeout time;
    指定DNS解析超時時長，默認爲30s; 
五、server_tokens on|off;
    是否在錯誤頁面中顯示nginx的版本號；

內存及磁盤資源分配：

一、client_body_in_file_only on|clean|off
    HTTP的包體是否存儲在磁盤文件中；非off表示存儲，即便包體大小爲0也會建立一個磁盤文件；on表示請求結束後包體文件不會被刪除，clean表示會被刪除；
二、client_body_in_single_buffer on|off;
    HTTP的包體是否存儲在內存buffer當中；默認爲off；
三、cleint_body_buffer_size size;
    nginx接收HTTP包體的內存緩衝區大小(默認是16K)；
四、client_body_temp_path dir-path [level1 [level2 [level3]]];
    HTTP包體存放的臨時目錄(若是body_buffer緩衝區已滿時生效)；
    例：client_body_temp_path /var/tmp/client/  1 2 2
    表示16*256*256的小區域來進行存儲緩存的文件
五、client_header_buffer_size size;
    正常狀況下接收用戶請求的http報文header部分時分配的buffer大小；默認爲1k;
六、large_client_header_buffers number size; 
    存儲超大Http請求首部的內存buffer大小及個數；
七、connection_pool_size size;
    nginx對於每一個創建成功的tcp鏈接都會預先分配一個內存池，此處即用於設定此內存池的初始大小；默認爲256；
八、request_pool_size size;
    nginx在處理每一個http請求時會預先分配一個內存池，此處即用於設定此內存池的初始大小；默認爲4k;

日誌模塊

一、log_format name string ...;
    string可使用nginx核心模塊及其它模塊內嵌的變量；
二、access_log path [format [buffer=size] [gzip[=level]] [flush=time] [if=condition]];
    access_log off;
    訪問日誌文件路徑，格式及相關的緩衝的配置；
    buffer=size
    flush=time 
三、open_log_file_cache max=N [inactive=time] [min_uses=N] [valid=time];
    open_log_file_cache off;
    緩存各日誌文件相關的元數據信息；
    max：緩存的最大文件描述符數量；
    min_users：在inactive指定的時長內訪問大於等於此值方可被看成活動項；
    inactive：非活動時長；
    valid：驗正緩存中各緩存項是否爲活動項的時間間隔；

URL重寫和防盜鏈

一、防盜鏈
    (1) 定義合規的引用
    valid_referers none | blocked | server_names | string ...;
    (2) 拒毫不合規的引用
    if  ($invalid_referer) {
    rewrite ^/.*$ http://www.b.org/403.html 
    } 
    二、URL rewrite
    rewrite regex replacement [flag];
eg.
   location / {
   root /www/b.org;
   rewrite ^/p_w_picpaths/(.*)$ /imgs/$1 last; 
   rewirte ^/imgs/(.*)$ /p_w_picpaths/$1;
   }
   http://www.b.org/p_w_picpaths/a.jpg --> http://www.b.org/imgs/a.jpg
   last: 一旦被當前規則匹配並重寫後當即中止檢查後續的其它rewrite的規則，然後經過重寫後的規則從新發起請求；
   break: 一旦被當前規則匹配並重寫後當即中止後續的其它rewrite的規則，然後繼續由nginx進行後續操做；
   redirect: 返回302臨時重定向；
   permanent: 返回301永久重定向；
   location /download/ {
   rewrite ^(/download/.*)/media/(.*)\..*$ $1/media/$2.mp3 break;
   }
   nginx最多循環10次，超出以後會返回500錯誤；
   注意：通常將rewrite寫在location中時都使用break標誌，或者將rewrite寫在if上下文中；
   rewrite_log on|off
   是否把重寫過程記錄在錯誤日誌中；默認爲notice級別；默認爲off；
   return code: 
   用於結束rewrite規則，而且爲客戶返回狀態碼；可使用的狀態碼有204, 400, 402-406, 500-504等；

文件壓縮：

一、gzip on | off;
    是否開啓壓縮功能，只有ON時，下面的選項才起效果，通常的生產環境都是啓動壓縮
二、gzip_comp_level level;
    文件的壓縮等級
三、gzip_disable regex ...;
    定義來自某類瀏覽器的文件不進行壓縮
四、gzip_min_length length;
    啓用壓縮功能的響應報文大小閾值； 
五、gzip_buffers number size;
    支持實現壓縮功能時爲其配置的緩衝區數量及每一個緩存區的大小；
六、gzip_proxied off | expired | no-cache | no-store | private | no_last_mo    dified | no_etag | auth | any ...;
    nginx做爲代理服務器接收到從被代理服務器發送的響應報文後，在何種條件下啓用壓縮功能的；
    off：對代理的請求不啓用
    no-cache, no-store，private：表示從被代理服務器收到的響應報文首部的Cache-Control的值爲此三者中任何一個，則啓用壓縮功能；
七、gzip_types mime-type ...;
    壓縮過濾器，僅對此處設定的MIME類型的內容啓用壓縮功能；

fcgi相關：

一、fastcgi_pass address;
    address爲fastcgi server的地址；location, if in location；
二、fastcgi_index name;
    fastcgi默認的主頁資源; 
三、fastcgi_param parameter value [if_not_empty];
    Sets a parameter that should be passed to the FastCGI server. The value can contain text, variables, and their combination.
    配置示例1：
    前提：配置好fpm server和mariadb-server服務；
    location ~* \.php$ {
    root           /usr/share/nginx/html;
    fastcgi_pass   127.0.0.1:9000;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  /usr/share/nginx/html$fastcgi_script_name; #注意script_filename的目錄位置
    include        fastcgi_params;
}

    配置示例2：經過/pm_status和/ping來獲取fpm server狀態信息；
    location ~* ^/(pm_status|ping)$ {
    include        fastcgi_params;
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_param  SCRIPT_FILENAME  $fastcgi_script_name;
}

四、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=ti
    定義fastcgi的緩存；緩存位置爲磁盤上的文件系統，由path所指定路徑來定義；
    levels=levels：緩存目錄的層級數量，以及每一級的目錄數量；levels=ONE:TWO:THREE
    leves=1:2:2
    keys_zone=name:size
    k/v映射的內存空間的名稱及大小
    inactive=time
    非活動時長
    max_size=size
    磁盤上用於緩存數據的緩存空間上限
五、fastcgi_cache zone | off;
    調用指定的緩存空間來緩存數據；http, server, location
六、fastcgi_cache_key string;
    定義用做緩存項的key的字符串；
七、fastcgi_cache_methods GET | HEAD | POST ...;
    爲哪些請求方法使用緩存；
八、fastcgi_cache_min_uses number;
    緩存空間中的緩存項在inactive定義的非活動時間內至少要被訪問到此處所指定的次數方可被認做活動項；
九、fastcgi_cache_valid [code ...] time;
    不一樣的響應碼各自的緩存時長；
示例：
http {
...
fastcgi_cache_path /var/cache/nginx/fastcgi_cache levels=1:2:1 keys_zone=fcgi:20m inactive=120s;
...
server {
...
location ~* \.php$ {
...
fastcgi_cache fcgi;
fastcgi_cache_key $request_uri;
fastcgi_cache_valid 200 302 10m;
fastcgi_cache_valid 301 1h;
fastcgi_cache_valid any 1m;
...
    }
...
    }
...
}

ssl相關的設置

一、ssl on | off;
    Enables the HTTPS protocol for the given virtual server.
二、ssl_certificate file;
    當前虛擬主機使用PEM格式的證書文件；
三、ssl_certificate_key file;
    當前虛擬主機上與其證書匹配的私鑰文件；
四、ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2];
    支持ssl協議版本，默認爲後三個；
五、ssl_session_cache off | none | [builtin[:size]] [shared:name:size];
builtin[:size]：使用OpenSSL內建的緩存，此緩存爲每worker進程私有；
[shared:name:size]：在各worker之間使用一個共享的緩存；
六、ssl_session_timeout time;
    客戶端一側的鏈接能夠複用ssl session cache中緩存 的ssl參數的有效時長；
配置示例：
server {
    listen 443 ssl;
    server_name www.domain.com;
    root /vhosts/ssl/htdocs;
    ssl on;
    ssl_certificate /etc/nginx/ssl/nginx.crt;  #導入的證書位置
    ssl_certificate_key /etc/nginx/ssl/nginx.key; #私鑰位置
    ssl_session_cache shared:sslcache:20m;
}

全部的配置和實例官方網站都有說明，能夠直接參考：http://nginx.org/en/docs/

瞭解nginx的基本配置後，接下來能夠進行nginx的實驗測試。

OK，更多文章請關注個人博客。