1、nginx特性以及功能
2、nginx的架構及工作過程
3、nginx作爲web服務器的配置
一、nginx特性以及功能
Nginx是一款輕量級的Web 服務器/反向代理服務器及電子郵件（IMAP/POP3）代理服務器，並在一個BSD-like 協議下發行。由俄羅斯的程序設計師Igor Sysoev所開發，供俄國大型的入口網站及搜索引擎Rambler（俄文：Рамблер）使用。其特點是佔有內存少，併發能力強，事實上nginx的併發能力確實在同類型的網頁服務器中表現較好，中國大陸使用nginx網站用戶有：百度、京東、新浪、網易、騰訊、淘寶等。
nginx特性：
基本功能：
靜態資源的web服務器，能緩存打開的文件描述符；
反向代理服務器，緩存、負載均衡；
支持FastCGI
模塊化，非DSO機制，過濾器gzip，SSI和圖像大小調整等
支持SSL
擴展功能：
基於名稱和IP做虛擬主機
支持keepalive
支持平滑配置更新或程序版本升級
定製訪問日誌，支持使用日誌緩存以提高性能
支持url rewrite
支持路徑別名
支持基於IP及用戶的認證；
支持速率限制，併發限制等；
二、nginx的架構及工作過程（nginx爲什麼能輕量高效工作）
1、nginx的工作模型
nginx的基本架構：
一個master, 生成一個或多個worker
事件驅動：kqueue, epoll, /dev/poll
消息通知：select, poll, rt signals
支持sendfile, sendfile64
文件AIO
支持mmap
nginx是一個非阻塞、事件驅動、一個master多個worker，一個worker響應多個用戶請求的模型
2、nginx的進程處理過程
nginx在啓動後，在unix系統中會以daemon的方式在後臺運行，後臺進程包含一個master進程和多個worker進程。
master進程主要用來管理worker進程，包含：接收來自外界的信號，向各worker進程發送信號，監控worker進程的運行狀態，當worker進程退出後(異常情況下)，會自動重新啓動新的worker進程。
worker進程則是處理基本的網絡事件。多個worker進程之間是對等的，他們同等競爭來自客戶端的請求，各進程互相之間是獨立的。一個請求，只可能在一個worker進程中處理，一個worker進程，不可能處理其它進程的請求。
worker進程的個數是可以設置的，一般我們會設置與機器cpu核數一致。更多的worker數，只會導致進程來競爭cpu資源了，從而帶來不必要的上下文切換。而且，nginx爲了更好的利用多核特性，具有cpu綁定選項，我們可以將某一個進程綁定在某一個核上，這樣就不會因爲進程的切換帶來cache的失效。
3、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的個數，避免引起資源的競爭。
4、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性能高效的主要原因。
更多文章請關注 我的博客
三、nginx作爲web服務器的配置
1、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
2、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）：
正常運行的配置： 1、user username [groupname]; 指定運行worker進程的用戶和組 2、pid /path/to/pidfile_name; 指定nginx的pid文件 3、worker_rlimit_nofile #; 指定一個worker進程所能夠打開的最大文件句柄數； 4、worker_rlimit_sigpending #; 設定每個用戶能夠發往worker進程的信號的數量； 優化性能相關的配置： 1、worker_processes #; worker進程的個數；通常其數值應該爲CPU的物理核心數減1； 2、worker_cpu_affinity cpumask ...; 0000 0001 0010 0100 1000 0011：表示第一和第二顆 worker_processes 6; worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000; 3、ssl_engine device; 在存在ssl硬件加速器的服務器上，指定所使用的ssl硬件加速設備； 4、timer_resolution t; 每次內核事件調用返回時，都會使用gettimeofday()來更新nginx緩存時鐘；timer_resolution用於定義每隔多久纔會由gettimeofday()更新一次緩存時鐘；x86-64系統上，gettimeofday()代價已經很小，可以忽略此配置； 5、worker_priority nice; -20,19之間的值；
事件相關的配置
1、accept_mutex [on|off] 是否打開Ningx的負載均衡鎖；此鎖能夠讓多個worker進輪流地、序列化地與新的客戶端建立連接；而通常當一個worker進程的負載達到其上限的7/8，master就儘可能不再將請求調度此worker； 2、lock_file /path/to/lock_file; lock文件 3、accept_mutex_delay #ms; accept鎖模式中，一個worker進程爲取得accept鎖的等待時長；如果某worker進程在某次試圖取得鎖時失敗了，至少要等待#ms才能再一次請求鎖； 4、multi_accept on|off; 是否允許一次性地響應多個用戶請求；默認爲Off; 5、use [epoll|rtsig|select|poll]; 定義使用的事件模型，建議讓nginx自動選擇； 6、worker_connections #; 每個worker能夠併發響應最大請求數；
用於調試、定位問題: 只調試nginx時使用
1、daemon on|off; 是否讓ningx運行後臺；默認爲on，調試時可以設置爲off，使得所有信息去接輸出控制檯； 2、master_process on|off 是否以master/worker模式運行nginx；默認爲on；調試時可設置off以方便追蹤； 3、error_log /path/to/error_log level; 錯誤日誌文件及其級別；默認爲error級別；調試時可以使用debug級別，但要求在編譯時必須使用--with-debug啓用debug功能；
nginx的http web功能：
必須使用虛擬機來配置站點；每個虛擬主機使用一個server {}段配置；
server {
}
非虛擬主機的配置或公共配置，需要定義在server之外，http之內；
http {
directive value;
...
server {
}
server {
}
...
}虛擬主機相關的配置：
1、server {}
定義一個虛擬主機；nginx支持使用基於主機名或IP的虛擬主機；
2、listen
listen address[:port];
listen port
default_server：定義此server爲http中默認的server；如果所有的server中沒有任何一個listen使用此參數，那麼第一個server即爲默認server;
rcvbuf=SIZE: 接收緩衝大小；
sndbuf=SIZE: 發送緩衝大小；
ssl: https server；
3、server_name [...];
server_name可以跟多個主機名，名稱中可以使用通配符和正則表達式(通常以~開頭)；當nginx收到一個請求時，會取出其首部的server的值，而後跟衆server_name進行比較；
比較優先次序方式：
(1) 先做精確匹配；www.magedu.com
(2) 左側通配符匹配；*.magedu.com
(3) 右側通配符匹配；www.abc.com, www.*
(4) 正則表達式匹配: ~^.*\.magedu\.com$
4、server_name_hash_bucket_size 32|64|128;
爲了實現快速主機查找，nginx使用hash表來保存主機名；
5、(1)location [ = | ~ | ~* | ^~ ] uri { ... }
(2)location @name { ... }
功能：允許根據用戶請求的URI來匹配指定的各location以進行訪問配置；匹配到時，將被location塊中的配置所處理
=：精確匹配；
~：正則表達式模式匹配，匹配時區分字符大小寫
~*：正則表達式模式匹配，匹配時忽略字符大小寫
^~: URI前半部分匹配，匹配時忽略字符大小寫。不檢查正則表達式
匹配優先級：
= (大於) ^~ (大於) ~ (大於) 不帶符號
location / :表示以/開頭的URL都可以匹配文件路徑定義：
1、root path
設置web資源路徑；用於指定請求的根文檔目錄；
location / {
root /www/htdocs;（本機的文件路徑）
}
location ^~ /images/ {
root /web;
}
root: root/URI/
2、alias path
只能用於location中，用於路徑別名；
location / {
root /www/htdocs;
}
location ^~ /images/ {
alias /web;
}
3、index file ...;
定義默認頁面，可參跟多個值；
4、error_page code ... [=[response]] uri;
錯誤頁重定向：當對於某個請求返回錯誤時，如果匹配上了error_page指令中設定的code，則重定向到新的URI中。
錯誤頁面重定向；
例：error_page 404 /404.html;當用戶請求一個不存在的資源是，會自動跳轉到自定義的404.html頁面。
注意跳轉的狀態碼還是原來的狀態碼，即使是跳轉成功！
5、try_files path1 [path2 ...] uri;
自左至右嘗試讀取由path所指定路徑，在第一次找到即停止並返回；如果所有path均不存在，則返回最後一個uri;
location ~* ^/documents/(.*)$ {
root /www/htdocs;
try_files $uri /docu/$1 /temp.html;
}網絡連接相關的設置：
1、keepalive_timeout time; 保持連接的超時時長；默認爲75秒,0表示禁止長連接； 2、keepalive_requests n; 在一次長連接上允許承載的最大請求數； 3、keepalive_disable [msie6 | safari | none ] 對指定的瀏覽器禁止使用長連接； 4、tcp_nodelay on|off 對keepalive連接是否使用TCP_NODELAY選項；啓用該選項表示即使請求的數據很小也會發送，不用等湊數才發送。 5、client_header_timeout time; 讀取http請求首部的超時時長； 6、client_body_timeout time; 讀取http請求包體的超時時長； 7、send_timeout time; 發送響應報文的超時時長；
對客戶端請求的限制：
1、limit_except method ... { ... }
指定對範圍之外的其它方法的訪問控制；
limit_except GET {
allow 172.16.0.0/16;
deny all;
}
2、client_max_body_size SIZE;
http請求包體的最大值；常用於限定客戶所能夠請求的最大包體；根據請求首部中的Content-Length來檢測，以避免無用的傳輸；
3、limit_rate speed;
限制客戶端每秒鐘傳輸的字節數；默認爲0，表示沒有限制；
4、limit_rate_after time;
nginx向客戶發送響應報文時，如果時長超出了此處指定的時長，則後續的發送過程開始限速；
5、用戶認證示例
location /admin/ {
root /www/b.org;
auth_basic "admin area";
auth_basic_user_file /etc/nginx/.htpasswd;
}文件操作的優化：
1、sendfile on|off 是否啓用sendfile功能； 2、aio on|off 是否啓用aio功能； 3、open_file_cache max=N [inactive=time]|off 是否打開文件緩存功能； max: 緩存條目的最大值；當滿了以後將根據LRU算法進行置換； inactive: 某緩存條目在指定時長時沒有被訪問過時，將自動被刪除；默認爲60s; 緩存的信息包括： 文件句柄、文件大小和上次修改時間； 已經打開的目錄結構； 沒有找到或沒有訪問權限的信息； 4、open_file_cache_errors on|off 是否緩存文件找不到或沒有權限訪問等相關信息； 5、open_file_cache_valid time; 多長時間檢查一次緩存中的條目是否超出非活動時長，默認爲60s; 6、open_file_cache_min_use #; 在inactive指定的時長內被訪問超此處指定的次數地，纔不會被刪除；
對客戶端請求的特殊處理：
1、ignore_invalid_headers on|off 是否忽略不合法的http首部；默認爲on; off意味着請求首部中出現不合規的首部將拒絕響應；只能用於server和http; 2、log_not_found on|off 是否將文件找不到的信息也記錄進錯誤日誌中； 3、resolver address; 指定nginx使用的dns服務器地址； 4、resover_timeout time; 指定DNS解析超時時長，默認爲30s; 5、server_tokens on|off; 是否在錯誤頁面中顯示nginx的版本號；
內存及磁盤資源分配：
1、client_body_in_file_only on|clean|off HTTP的包體是否存儲在磁盤文件中；非off表示存儲，即使包體大小爲0也會創建一個磁盤文件；on表示請求結束後包體文件不會被刪除，clean表示會被刪除； 2、client_body_in_single_buffer on|off; HTTP的包體是否存儲在內存buffer當中；默認爲off； 3、cleint_body_buffer_size size; nginx接收HTTP包體的內存緩衝區大小(默認是16K)； 4、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的小區域來進行存儲緩存的文件 5、client_header_buffer_size size; 正常情況下接收用戶請求的http報文header部分時分配的buffer大小；默認爲1k; 6、large_client_header_buffers number size; 存儲超大Http請求首部的內存buffer大小及個數； 7、connection_pool_size size; nginx對於每個建立成功的tcp連接都會預先分配一個內存池，此處即用於設定此內存池的初始大小；默認爲256； 8、request_pool_size size; nginx在處理每個http請求時會預先分配一個內存池，此處即用於設定此內存池的初始大小；默認爲4k;
日誌模塊
1、log_format name string ...; string可以使用nginx核心模塊及其它模塊內嵌的變量； 2、access_log path [format [buffer=size] [gzip[=level]] [flush=time] [if=condition]]; access_log off; 訪問日誌文件路徑，格式及相關的緩衝的配置； buffer=size flush=time 3、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、防盜鏈
(1) 定義合規的引用
valid_referers none | blocked | server_names | string ...;
(2) 拒絕不合規的引用
if ($invalid_referer) {
rewrite ^/.*$ http://www.b.org/403.html
}
2、URL rewrite
rewrite regex replacement [flag];
eg.
location / {
root /www/b.org;
rewrite ^/images/(.*)$ /imgs/$1 last;
rewirte ^/imgs/(.*)$ /images/$1;
}
http://www.b.org/images/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等；文件壓縮：
1、gzip on | off; 是否開啓壓縮功能，只有ON時，下面的選項才起效果，一般的生產環境都是啓動壓縮 2、gzip_comp_level level; 文件的壓縮等級 3、gzip_disable regex ...; 定義來自某類瀏覽器的文件不進行壓縮 4、gzip_min_length length; 啓用壓縮功能的響應報文大小閾值； 5、gzip_buffers number size; 支持實現壓縮功能時爲其配置的緩衝區數量及每個緩存區的大小； 6、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的值爲此三者中任何一個，則啓用壓縮功能； 7、gzip_types mime-type ...; 壓縮過濾器，僅對此處設定的MIME類型的內容啓用壓縮功能；
fcgi相關：
1、fastcgi_pass address;
address爲fastcgi server的地址；location, if in location；
2、fastcgi_index name;
fastcgi默認的主頁資源;
3、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;
}
4、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
磁盤上用於緩存數據的緩存空間上限
5、fastcgi_cache zone | off;
調用指定的緩存空間來緩存數據；http, server, location
6、fastcgi_cache_key string;
定義用作緩存項的key的字符串；
7、fastcgi_cache_methods GET | HEAD | POST ...;
爲哪些請求方法使用緩存；
8、fastcgi_cache_min_uses number;
緩存空間中的緩存項在inactive定義的非活動時間內至少要被訪問到此處所指定的次數方可被認作活動項；
9、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相關的設置
1、ssl on | off;
Enables the HTTPS protocol for the given virtual server.
2、ssl_certificate file;
當前虛擬主機使用PEM格式的證書文件；
3、ssl_certificate_key file;
當前虛擬主機上與其證書匹配的私鑰文件；
4、ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2];
支持ssl協議版本，默認爲後三個；
5、ssl_session_cache off | none | [builtin[:size]] [shared:name:size];
builtin[:size]：使用OpenSSL內建的緩存，此緩存爲每worker進程私有；
[shared:name:size]：在各worker之間使用一個共享的緩存；
6、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，更多文章請關注我的博客。