第一部分：HTTP基礎知識
在介紹nginx常用模塊中的指令時，先來回顧一下http的相關知識：
1、http的工作原理
http的工作原理大致是這樣的：
a)、客戶端與服務器先建立一個TCP連接；
b)、客戶端通過已建立的TCP連接向服務端發送一個http請求報文；
c)、服務器收到請求報文後開始解析報文、定位所請求的資源，讀取資源並封裝成響應報文後發送給客戶端；
d)、如果沒有啓用持久連接，服務器端主動斷開tcp連接，客戶端被動關閉；如果啓用了持久連接，那該tcp連接保持一段時間後，在該時間內客戶端可利用此tcp連接斷續請求資源；
f)、客戶端接收到響應報文後解析此報文（html文檔），並在瀏覽器上給予顯示。
2、http的兩個重要特性
a)、http的無狀態性：同一個客戶端兩次連續的訪問服務器端，服務器不會知道這兩個請求是來自同一個客戶端，服務器不會意識到這個客戶端在前不久已訪問過，服務器端也無法識別不同的客戶端。http的這種無狀態性讓http的設計更爲簡單高效，更能讓服務器能承載高併發的http請求。
b)、http的持久連接：在http1.0時不支持持久連接，意味着每一個請求客戶端與服務端都需要建立一個新的tcp連接，而tcp是一種可靠的連接，每一次連接都需要經過三次握手，每一次斷開都需要經過四次斷開，而當今互聯網環境下，一個頁面上的資源多達數十個，那打開一個頁面速度會很慢，這種短連接的方式也加重了網絡的負擔。http1.1開始支持keepalive持久連接，允許客戶端與服務端的TCP連接建立後保持一段時間，在接下來的請求中可以利用此TCP連接進行資源的請求與響應。而http1.1的持久連接也有兩種模式：一種叫非流水線的持久連接，這種持久連接表示客戶端在沒有接收到上一次請求的響應報文時不能再發送第二次的請求報文；另一種叫做流水線的持久連接，這種持久連接表示客戶端在沒有接收到上一次請求的響應報文時依然可能發送第二次請求報文。
3、http協議請求報文與響應報文格式
請求報文格式如下圖（圖片來自網絡）：
請求報文包括請求行、請求頭部和請求包體三部分，如上圖所示。
響應報文格式如下圖（圖片來自網絡）：
響應報文包括狀態行、響應頭部和響應包體三部分，如上圖所示。
4、http的響應碼
1XX：純屬狀態信息碼，表示請求收到，斷續處理
2XX：成功響應碼，行爲被成功接受、理解與採納
3XX：重定向類，爲了完成請求，必須進一步執行動作
4XX：客戶端錯誤，請求包含語法錯誤或者請求的資源不存在
5XX：服務器錯誤，服務器不能實現一種明顯無效的請求
第二部分：nginx的常用配置
nginx是一個高度模塊化的架構，它分爲以下幾類模塊：“nginx core module”(nginx核心模塊)、“standard http modules”(標準模塊)、“optional http modules”(可選模塊)、“mail modules”(郵件相關的模塊)、“third party modules”(第三方模塊)。此博文只對nginx核心模塊和HTTP核心模塊中常用的指令用法作介紹，在nginx核心模塊中的指令中，根據指令的功能不同，也可把這些指令歸成幾個類別，下邊就慢慢道來。
nginx核心模塊的指令用於配置在nginx.conf的main段，作用於nginx自身啓動的特性設置，作用域是main、envents、http、server、mail各段，nginx核心模塊中保證nginx正常啓動必備的幾個指令：
1、user USER [GROUP];
指定運行worker進程的用戶和組，組可省略，那就表示使用user所在的組作爲worker進程的組。
2、pid FILE;
指定nginx的pid文件。
3、worker_rlimit_sigpending LIMIT;
設定每個用戶能夠發往worker進程的信號數量，即指定信號隊列的大小，這個指令現在已被nginx官方刪除，不再支持此指令。
與優化相關的指令(main配置段)
1、worker_processes NUMBER | AUTO;
指定nginx啓動時啓動worker進程的個數，以cpu的核心爲基準，其值一般爲cpu的物理核心數減去1或2，留下1到2個核心讓系統本身使用，默認值是1。
2、worker_cpu_affinity CPUMASK;
讓worker進程綁定在指定的cpu核心上，這個指令只能用於Linx和FreeBSD的系統上。比如：
worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;
表示啓動4個worker進程並分別綁定在了cpu0、cpu1、cpu2、cpu3上。
如果cpu已開啓了超線程技術，那建議如下的配置：
worker_processes 2;
worker_cpu_affinity 0101 1010;
表示啓動兩個worker進程，把第一個進程綁定在cpu0和cpu2上，把第二個進程綁定在cpu1和cpu3上。
3、ssl_engine DEVICE;
在擁有ssl硬件加速的服務器上指定硬件ssl設備，讓硬件設備來維持ssl會話
4、timer_resolution INTERVAL;
每次內核的事件調用（假如epool）返回時，都會使用gettimeofday()來更新nginx的緩存時鐘，此值用於定義多長時間才由gettimeofday()更新一次緩存時鐘，單位爲“ms”，在x86的服務器上，gettimeofday()的代價極低，可忽略些指令的設定
5、worker_priority NUMBER；
NUMBER的範圍(-20,19)，指定worker進程的優先級別，值越小優先級越高，默認是0
6、worker_rlimit_nofile SIZE;
指定一個worker進程能夠打開的最大文件句柄數，設置此值可以在突破系統的限制而不重新啓動主進程。默認時一般是1024個，在高併發環境下需要加大此值，一般設置爲51200。
與事件相關的配置（events{}）
1、accep_mutex on | off;
默認已開啓， 是否打開nginx的負載均衡鎖，因nginx是以master-worker進程模型工作，worker的接收請求是由master進程來分配，設置此選項爲“on”，master進程會逐個分配新的請求給各worker進程，否則（設置爲off）每個worker進程都會收到有新請求的通知，在少量請求的環境下，一些worker進程可能只是在浪費資源而已。當worker進程的負載達到其上限的7/8時，master就儘可能不再將請求分配給此worker。
2、lock_file FILE;
nginx利用鎖定機制來實現accep_mutex和序列化對共享內存的訪問，此值設定鎖文件的存放路徑，默認在“lock_file logs/nginx.lock;”。
3、accept_mutex_delay TIME;
假如accept_mutex設置爲on，這裏的TIME表示如果一個worker進程正在處理一個新連接，而另一個進程又想取得accept鎖來處理新請求這期間，worker進程需要等待的最大時長，默認是500ms。
4、multi_accept on | off;
假如設置爲off，worker進程一次將接受一個新的連接請求，否則worker進程將一次所有的新連接請求，默認是off。
5、use [epoll|rtsig|select|poll];
定義nginx連接處理事件的方法，方法有“select、poll、kqueue、epoll”，nginx將默認使用最有效的方法來處理事件，所以此指令不用顯式的定義。
6、worker_connections NUM;
定義一個worker進程能夠併發處理的最大連接數,默認是512。
用於調試、定位問題的配置（main段）
1、daemon on | off;
是否讓nginx運行於後臺，默認是"on"，在調試時應該設置爲“off”，使所有信息輸出到標準輸出，主要是開發者使用。
2、master_process on | off;
是否以master-worker模型運行，默認是“on”，調試時可設置爲“off”，主要是開發者使用。
3、error_log /path/to/error_log LEVEL;
設置錯誤日誌文件及其級別，調試時把level設置爲debug，默認是error級別，但在編譯安裝時需要“--with-debug”開啓此功能。
與http(web)服務相關的配置
nginx必須使用虛擬主機來提供站點，每個虛擬主機需要一個"server{}"段來配置，非虛擬主機或公共配置，需要放在server{}之外，http{}之內。
1、server{}
定義一個虛擬主機，支持基於主機名、基於IP、基於端口的虛擬主機
2、listen IPADDRESS[:PORT];
listen中的各子指令：
default_server：定義此server爲http中默認的server，如果所有的server{}中沒有一個使用此參數，那第一個server{}就是默認
rcvbuf=SIZE：設置接收監聽在套接字的接收緩衝大小
sndbuf=SIZE：設置接收監聽在套接字的發送緩衝大小
ssl：表示這是一個https server
3、server_name SERVER_NAME;
可以跟多個主機名，名稱中可以使用通配符（以"~"開頭），當nginx收到一個請求時，會取出"Host"首部，然後跟所有的server_name進行比較。比較方式爲：
a、先做精確匹配：
b、左側通配符匹配：
c、右側通配符匹配：
d、正則表達式匹配：
4、server_name_hash_bucket_size 32|64|128
爲了實現快速主機查找，nginx使用hash表來保存主機名，此指令用來設置存放hash table的大小。
5、location，有兩種模式，第一種：“location [ = | ~ | ~* | ^~ ] uri { ... } ”，第二種：“ location @name { ... }”
功能：根據用戶請求的URI來匹配各個location，匹配到時將被location的控制策略所處理。
location後的操作符的意義：
=：精確匹配
~：正則表達式模式匹配，匹配時區分字符大小寫
~*：正則表達式模式匹配，匹配時忽略字符大小寫
^~：對URI的前半部分匹配，不檢查正則表達式
匹配優先級：
先字符精確匹配，再正則表達式（多個正則表達都能匹配，那由第一個匹配到的處理），再按字符匹配
在location中與文件路徑相關的指令：
a)、root PATH
設置web資源的存放路徑，
舉例：
location ^~/p_w_picpath/ {
root /photo;
}
如果訪問的URL爲“http://www.test.com/p_w_picpath/a.jpg"，那此資源的存放路徑爲“/photo/p_w_picpath/a.jpg”，“p_w_picpath”是在"root /photo"定義的路徑後的一個真實路徑。
b)、alias PATH
設置路徑別名
location ^~/p_w_picpath/ {
alias /photo;
}
如果訪問的URL爲“http://www.test.com/p_w_picpath/a.jpg"，那此資源的存放路徑爲"/photo/a.jpg"，"p_w_picpath"就是一個虛擬的路徑，在存儲資源的路徑中根本就沒有，是一個虛假的訪問路徑，被匹配到時，被alias替換成了它定義的真實路徑。
c)、index FILE ...;
定義默認主頁，可跟多個值
d)、error page code ... [=[response]] uri;
當對某個請求返回錯誤時，如果匹配上了error_page指令中設定的code，則重定向到新的URI中，用來定義錯誤頁面重定向，利用"=response"（response爲響應碼）可以定義返回給用戶端的響應碼成爲自己定義的值。
f)、 try_files file ... uri;
依次去請求try_files後跟的文件，如果能請求到則返回給用戶，如果後邊接的file全部都嘗試過了還是沒有所請求的資源，則用定義的uri作爲響應給用戶。常用於錯誤文件的重定向。
例如：
location /documents/ {
root /www/htdocs;
try_files $uri /temp.html
}
這樣定義表示當用戶請求的uri中匹配到“/documents/”時，那就嘗試去取得用戶所請求的資源，如果用戶所請求的資源不存在，剛用"/www/htdocs/temp.html"這個資源響應給用戶。"$uri"表示把用戶請求的每一個資源都賦予給這個變量進行查找相應資源的URI。
try_files file ... =code;
如果後邊跟上一個“=code”，“code”是一個響應代碼，那麼在響應報文中會帶上這個指定的響應碼，例如：
location / {
try_files $uri $uri/index.html $uri.html =404;
}
這個例子表示用戶訪問網站根時，假設網站爲
http://www.test.com，當用戶訪問http://www.test.com時，依次嘗試訪問http://www.test.com，http://www.test.com/index.html，http://www.test.com.html，如果都無法得到資源，那就把響應碼設置成404。
與網絡連接相關的設置
1、keepalive_timeout TIME;
定義保持連接的超時時間，默認是75秒，
2、keepalive_requests NUM;
定義在一個長連接上能夠承載的最大請求數，即使沒有達到keepalive_timeout定義的時間，只要達到最大請求數，那連接也將斷開，默認是100。
3、keepalive_disable [msie6 | safari | none];
對指定的瀏覽器禁用長連接
4、tcp_nodelay on | off;
對keepalive連接是否使用tcp_nodelay選項，默認爲“on”，在tcp中把數據送達到對方時，對方會給予一個確認數據收到的確認報文，delay就是表示延遲響應這個確認報文，把多個確認報文一起發給對方，tcp的性能能得到提升。但延遲響應在keepalive中會導致瀏覽器可能會錯誤認爲對方沒有收到已正確發送給對方的數據，因爲在一定時間內沒有收到確認報文，所以在keepalive的場景因關閉延遲確認，即“tcp_nodelay on”。
5、client_header_timeout TIME;
讀取http請求首部的超時時間，單位爲秒，默認是60秒
6、client_body_timeout TIME;
讀取http請求的包體的超時時長，默認是60秒鐘
7、send_timeout TIME;
發送http響應報文的超時時長，默認是60秒
對客戶端請求的限制參數
1、limit_except method ... { ... }
限定指定範圍之外方法的訪問控制，例如：
limit_except GET {
allow 192.168.1.0/24;
deny all;
}
表示除了“GET”(或“HEAD”)方法之外的方法只有192.168.1.0網段才能使用
2、client_max_body_size SIZE;
限定http請求包體的最大值，默認是1M，常用於限定客戶端所能夠請求的最大包體，根據請求首部中的content_length來檢測，以免無用的傳輸。
3、limit_rate SPEED;
限制客戶端每秒傳輸的字節數，默認爲0，表示沒有限制
4、limit_rate_after SIZE;
nginx服務器端向客戶端發送響應報文時，如果報文大小超出此處指定的大小後，則後續的發送過程開始使用limit_rate來限速。例如：
location /flv/ {
flv;
limit_rate_after 500k;
limit_rate 50k;
}
表示當用戶訪問的URI中匹配到“/flv/”後，且響應報文大於500k後，則後續的響應速度限制爲50k/s
對文件操作的優化配置
1、sendfile on | off;
是否啓用sendfile功能，建議啓用
2、aio on | off;
是否啓用aio功能，建議啓用
3、open_file_cache off;
open_file_cache max=N [inactive=time];
是否打開文件緩存功能，max定義緩存元素的最大數量，當緩存填充滿後根據LRU算法進行置換；inactive表示一個緩存條目在設置的時長沒有被訪問則自動被清理，默認時長爲60秒。這裏緩存的信息包括：文件句柄、文件大小、上次修改的時間，已經打開的目錄結構，沒有找到或沒有訪問權限的信息（這是由"open_file_cache_errors on | off"來控制是否緩存）。
4、open_file_cache_errors on | off;
在緩存時是否緩存因文件找不到或沒有權限訪問的相關信息。
5、open_file_cache_valid TIME;
多長時間檢查一次緩存中的條目是否超出非活動時長，默認60秒，這個值應該與大於等於open_file_cache中的inactive=TIME中的值。
6、open_file_cache_min_uses NUM;
在open_file_cache中的inactive指定的時長內，被訪問的次數超過這個指定的NUM值地，緩存條目纔不會被刪除，不然緩存條目在inactive指定的時長內被訪問，但沒有達到NUM值，依然會被清除。
對客戶端請求的特殊處理
1、ignore_invalid_headers on | off;
是否忽略不合法的http首部請求，默認爲on，off意味着請求中存在不合法的首部時不予響應。
2、log_not_found on | off;
用戶請求的資源不存在時是否將這些資源找不到的相關信息也記錄到錯誤日誌中，
3、resolver_address;
指定nginx使用的dns服務器地址，用於解析upstream server的ip地址
4、resolver_timeout TIME;
指定dns解析的超時時間，默認爲30秒
5、server_tokens on | off;
是否開啓在響應報文“Server”字段中的信息和在服務器出錯時的提示信息中是否包含nginx版本信息。
http核心模塊的內置變量:
$uri
客戶端請求的uri，不帶參數部分
$request_uri
客戶端請求的uri，帶完整的參數部分
$host
http請求報文中的host首部，如果請求中沒有host首部，則由處理此請求的虛擬主機的主機名代替。
$hostname
nginx服務運行在的主機的主機名
$remote_addr
客戶端的IP
$remote_port
客戶端的端口
$remote_user
使用用戶認證時，客戶端輸入的用戶名
$request_filename
指用戶請求中的uri經過本地root或alias轉換後映射的本地路徑，即存放在本地磁盤的真實路徑
$request_method
用戶的請求方法
$server_addr
服務器地址IP
$server_name
nginx中配置的server_name的名稱
$server_port
服務器端口，默認就是80
$server_protocol
服務器向客戶端發送響應時的協議版本，如http/1.1
$scheme
在請求中使用的scheme，如https://www.test.com中的htts，即使用的協議
$http_HEADER
匹配請求報文中指定的HEADER,如: $http_host匹配請求報文中的host首部
$sent_http_HEADER
匹配響應報文中指定的HEADER，例如：$sent_http_content_type匹配響應報文中的content_type首部
$document_root
當前請求映射到的root指令配置的路徑