Nginx 基礎概念
Nginx 基礎概念
日期:20181117
個人小站: www.winthcloud.top
目錄
http協議基本概念
資源加速
http MPM (Multiple Process Module)
I/O型別(synchronous, asyncronous, blocking, nonblocking)
I/O模型(重點)
同步阻塞IO模型
同步非阻塞IO模型
I/O多路複用模型
訊號驅動IO模型 signal-driven
非同步IO
I/O模型的具體實現
select/poll/epoll
Nginx介紹
nginx的程式架構
nginx模組
nginx的功用
nginx配置
正常執行必備的配置
效能優化相關的配置
事件驅動相關的配置
除錯和定位問題log,daemon
ngx_http_core_module模組相關配置
與套接字相關的配置:
server
listen
server_name
tcp_nodelay
sendfile
server_token
定義路徑相關的配置:
location
root
index
error_page
try_files
定義客戶端請求的相關配置:
keepalive_{timeout,requests,disable},
send_timeout
client_body_buffer_size
client_body_temp_path
對客戶端進行限制的相關配置:
limit_rate
limit_except
檔案操作優化的配置:
aio
directio
open_file_cache
open_file_cache_errors
open_file_cache_min_uses
open_file_cache_valid
Nginx (web server, web reverse proxy)http協議基本概念
http protocal: 80/tcp, HyperText Transfer Protocal
html: HyperText Mark Language
文字: HTTP:/1.1, MIME
MIME Multipurpose Internet Mail Extension
major/minor
text/plain
image/jpeg
URI Uniform Resorce Identifier
URL Uniform Resource Locator
URL scheme://server[:port]/path/source
http事務 request <--> response
request:
<method> <URL> <version>
<HEAD>
<BODY>
response:
<version> <status> <reason phrase>
<HEADERS>
<BODY>
協議格式: 文字，二進位制
method:
GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS
status:
1XX 資訊類
2XX 成功類200
3XX 重定向類
4XX 客戶端錯誤
5XX 服務端錯誤
HEADER
通用首部
請求首部
響應首部
實體首部
擴充套件首部
PV: page view
UV: user view
資源加速
瀏覽器限制開啟的執行緒是基於單個域名的，如某瀏覽器對域名可請求的執行緒數限制是4，如果請求
某個單個頁面時，該頁面裡如果2個其它域名它可以同時啟動12個執行緒去載入頁面
http MPM (Multiple Process Module)
prefork, worker, event
prefork: 主程序，生成多個子程序，每個子程序處理一個請求
worker: 主程序，生成多個子程序，每個子程序生成多個執行緒，每個執行緒響應一個請求
event: 主程序，生成多個子程序，每個子程序響應多個請求
I/O型別(synchronous, asyncronous)
同步和非同步synchronous, asyncronous
關注的是訊息通知機制
同步:呼叫發出之後不會立即返回，但一旦返回，則返回即是最終結果
非同步:呼叫發出之後，被呼叫方立即返回訊息，但返回的並非最終結果，被呼叫者通過
狀態、通知機制來通知呼叫者，或通過回撥函式來處理結果
阻塞和非阻塞 block, nonblock
關注的是呼叫者等待被呼叫者返回呼叫結果時的狀態
阻塞:呼叫結果返回之前，呼叫者會被掛起，呼叫者只有在得到返回結果之後才能繼續操作
非阻塞: 呼叫者在結果返回之前，不會被掛起，即呼叫不會阻塞呼叫者的其它操作
I/O模型(重點)
blocking IO
nonblocking IO
IO multiplexing 複用
程序將IO呼叫交由以下的系統呼叫來完成從磁碟載入檔案至核心
select()
poll()
有限制最多同時接受1024個併發呼叫
prefork和worker就是使用此種模型，如果阻塞型程序則阻塞在呼叫select()之上
但是其第二段將資料由核心空間複製到核心空間的階段還是阻塞的
雖然看似阻塞但是select()由於是個代理幫程序去呼叫真正處理將硬碟檔案載入至核心
空間的系統呼叫，在此期間它還可以接收其它程序的io呼叫請求
signal driven
sigIO
此種IO模型在其第一段將IO請求的資料由磁碟載入至核心空間的這段時間裡，程序
可以再次接收其它請求，但在第二段由核心空間複製資料至程序空間時，此段是阻塞
的無法再處理其它請求
通知
水平觸發 多次通知程序取資料
邊緣觸發 只通知一次
asynchronous IO
sigIO的升級，兩個階段都解放，即程序傳送IO請求後就可以再次接收其它請求，兩個階
段的處理完成後會給程序傳送訊號，程序直接可以去指定的記憶體空間取資料進行操作
模型由上至下，其程式設計的難度逐步增強
Nginx最被設計時用的就是事件驅動式IO，而且使用邊緣觸發機制，並且還支援非同步
IO，和mmaping機制，設計之初就是做高併發的處理能力的web應用伺服器程式
同步/非同步：關注的是訊息通訊機制
同步：synchronous，呼叫者等待被呼叫者返回訊息，才能繼續執行
非同步：asynchronous，被呼叫者通過狀態、通知或回撥機制主動通知呼叫者被呼叫者
的執行狀態
阻塞/非阻塞：關注呼叫者在等待結果返回之前所處的狀態
阻塞：blocking，指IO操作需要徹底完成後才返回到使用者空間，呼叫結果返回之前，
呼叫者被掛起
非阻塞：nonblocking，指IO操作被呼叫後立即返回給使用者一個狀態值，無需等到IO操
作徹底完成，最終的呼叫結果返回之前，呼叫者不會被掛起
I/O模型：
阻塞型、非阻塞型、複用型、訊號驅動型、非同步
同步阻塞IO模型
同步阻塞IO模型是最簡單的IO模型，使用者執行緒在核心進行IO操作時被阻塞
使用者執行緒通過系統呼叫read發起IO讀操作，由使用者空間轉到核心空間。核心等到資料包
到達後，然後將接收的資料拷貝到使用者空間，完成read操作
使用者需要等待read將資料讀取到buffer後，才繼續處理接收的資料。整個IO請求的過
程中，使用者執行緒是被阻塞的，這導致使用者在發起IO請求時，不能做任何事情，對CPU的
資源利用率不夠
同步非阻塞IO模型
使用者執行緒發起IO請求時立即返回。但並未讀取到任何資料，使用者執行緒需要不斷地發起IO
請求，直到資料到達後，才真正讀取到資料，繼續執行。即 “輪詢”機制
整個IO請求的過程中，雖然使用者執行緒每次發起IO請求後可以立即返回，但是為了等到數
據，仍需要不斷地輪詢、重複請求，消耗了大量的CPU的資源
是比較浪費CPU的方式，一般很少直接使用這種模型，而是在其他IO模型中使用非阻
塞IO這一特性
I/O多路複用模型
IO多路複用是指核心一旦發現程序指定的一個或者多個IO條件準備讀取，就通知該程序
多個連線共用一個等待機制，本模型會阻塞程序，但是程序是阻塞在select或者poll這
兩個系統呼叫上，而不是阻塞在真正的IO操作上
使用者首先將需要進行IO操作新增到select中，繼續執行做其他的工作（非同步），同時等
待select系統呼叫返回。當資料到達時，IO被啟用，select函式返回。使用者執行緒正式發
起read請求，讀取資料並繼續執行
從流程上來看，使用select函式進行IO請求和同步阻塞模型沒有太大的區別，甚至還多了
新增監視IO，以及呼叫select函式的額外操作，效率更差。並且阻塞了兩次，但是第一次
阻塞在select上時，select可以監控多個IO上是否已有IO操作準備就緒，即可達到在同
一個執行緒內同時處理多個IO請求的目的。而不像阻塞IO那種，一次只能監控一個IO
雖然上述方式允許單執行緒內處理多個IO請求，但是每個IO請求的過程還是阻塞的（在select
函式上阻塞），平均時間甚至比同步阻塞IO模型還要長。如果使用者執行緒只是註冊自己需要的
IO請求，然後去做自己的事情，等到資料到來時再進行處理，則可以提高CPU的利用率
IO多路複用是最常使用的IO模型，但是其非同步程度還不夠“徹底”，因它使用了會阻塞執行緒
的select系統呼叫。因此IO多路複用只能稱為非同步阻塞IO模型，而非真正的非同步IO
訊號驅動IO模型
訊號驅動IO：signal-driven I/O
使用者程序可以通過sigaction系統呼叫註冊一個訊號處理程式，然後主程式可以繼續向下
執行，當有IO操作準備就緒時，由核心通知觸發一個SIGIO訊號處理程式執行，然後將用
戶程序所需要的資料從核心空間拷貝到使用者空間
此模型的優勢在於等待資料報到達期間程序不被阻塞。使用者主程式可以繼續執行，只要等待
來自訊號處理函式的通知
非同步IO模型
非同步IO與訊號驅動IO最主要的區別是訊號驅動IO是由核心通知何時可以進行IO操作，而
非同步IO則是由核心告訴使用者執行緒IO操作何時完成。訊號驅動IO當核心通知觸發訊號處理
程式時，訊號處理程式還需要阻塞在從核心空間緩衝區拷貝資料到使用者空間緩衝區這個
階段，而非同步IO直接是在第二個階段完成後，核心直接通知使用者執行緒可以進行後續操作了
相比於IO多路複用模型，非同步IO並不十分常用，不少高效能併發服務程式使用IO多路複用
模型+多執行緒任務處理的架構基本可以滿足需求。目前作業系統對非同步IO的支援並非特別完
善，更多的是採用IO多路複用模型模擬非同步IO的方式（IO事件觸發時不直接通知使用者執行緒，
而是將資料讀寫完畢後放到使用者指定的緩衝區中）
I/O模型的具體實現
主要實現方式有以下幾種：
Select：Linux實現對應，I/O複用模型，
BSD4.2最早實現，POSIX標準，一般作業系統均有實現
Poll：Linux實現，對應I/O複用模型，System V unix最早實現
Epoll：Linux特有，對應I/O複用模型，具有訊號驅動I/O模型的某些特性
Kqueue：FreeBSD實現，對應I/O複用模型，具有訊號驅動I/O模型某些特性
/dev/poll：SUN的Solaris實現，對應I/O複用模型，具有訊號驅動I/O模型的某些特性
Iocp Windows實現，對應第5種（非同步I/O）模型
select/poll/epoll
Select：POSIX所規定，目前幾乎在所有的平臺上支援，其良好跨平臺支援也是它的一個優
點，本質上是通過設定或者檢查存放fd標誌位的資料結構來進行下一步處理
缺點
單個程序能夠監視的檔案描述符的數量存在最大限制，在Linux上一般為1024，
可以通過修改巨集定義FD_SETSIZE，再重新編譯核心實現，但是這樣也會造成效率的降低
單個程序可監視的fd數量被限制，預設是1024，修改此值需要重新編譯核心
對socket是線性掃描，即採用輪詢的方法，效率較低
select 採取了記憶體拷貝方法來實現核心將 FD 訊息通知給使用者空間，這樣一個用
來存放大量fd的資料結構，這樣會使得使用者空間和核心空間在傳遞該結構時複製開銷大
poll
本質上和select沒有區別，它將使用者傳入的陣列拷貝到核心空間，然後查詢每個fd對應的
裝置狀態
其沒有最大連線數的限制，原因是它是基於連結串列來儲存的
大量的fd的陣列被整體複製於使用者態和核心地址空間之間，而不管這樣的複製是不是有意義
poll特點是“水平觸發”，如果報告了fd後，沒有被處理，那麼下次poll時會再次報告該fd
邊緣觸發：只通知一次
epoll：在Linux 2.6核心中提出的select和poll的增強版本
支援水平觸發LT和邊緣觸發ET，最大的特點在於邊緣觸發，它只告訴程序哪些fd剛剛變為
就需態，並且只會通知一次
使用“事件”的就緒通知方式，通過epoll_ctl註冊fd，一旦該fd就緒，核心就會採用類似
callback的回撥機制來啟用該fd，epoll_wait便可以收到通知
優點:
沒有最大併發連線的限制：能開啟的FD的上限遠大於1024(1G的記憶體能監聽約10萬個
埠)，具體檢視/proc/sys/fs/file-max，此值和系統記憶體大小相關
效率提升：非輪詢的方式，不會隨著FD數目的增加而效率下降；只有活躍可用的FD才
會呼叫callback函式，即epoll最大的優點就在於它只管理“活躍”的連線，而跟連線
總數無關
記憶體拷貝，利用mmap(Memory Mapping)
加速與核心空間的訊息傳遞；即epoll使用mmap減少複製開銷
Nginx介紹
Nginx：engine X ，2002年，開源，商業版
NGINX是免費，開源，高效能的HTTP和反向代理伺服器，郵件代理伺服器，通用
TCP/UDP代理伺服器
解決C10K問題（10K Connections）
官網：http://nginx.org
二次開發版：
Tengine
OpenResty（章亦春）
特性：
模組化設計，較好的擴充套件性
高可靠性
支援熱部署：不停機更新配置檔案，升級版本，更換日誌檔案
低記憶體消耗：10000個keep-alive連線模式下的非活動連線，僅需2.5M記憶體
event-driven,aio, mmap，sendfile
基本功能：
靜態資源的web伺服器
http協議反向代理伺服器
pop3/imap4協議反向代理伺服器
FastCGI(LNMP),uWSGI(python)等協議
模組化（非DSO），如zip，SSL模組
nginx的程式架構
web服務相關的功能：
虛擬主機（server）
支援 keep-alive 和管道連線
訪問日誌（支援基於日誌緩衝提高其效能）
url rewirte
路徑別名
基於IP及使用者的訪問控制
支援速率限制及併發數限制
重新配置和線上升級而無須中斷客戶的工作程序
Memcached 的 GET 介面
master/worker結構
一個master程序：
負載載入和分析配置檔案、管理worker程序、平滑升級
一個或多個worker程序
處理並響應使用者請求
快取相關的程序：
cache loader：載入快取物件
cache manager：管理快取物件
nginx模組
nginx高度模組化，但其模組早期不支援DSO機制；1.9.11版本支援動態裝載和解除安裝
模組分類：
核心模組：core module
標準模組：
HTTP 模組： ngx_http_*
HTTP Core modules 預設功能
HTTP Optional modules 需編譯時指定
Mail 模組 ngx_mail_*
Stream 模組 ngx_stream_*
第三方模組
核心模組：是 Nginx 伺服器正常執行 必不可少 的模組，提供 錯誤日誌記錄 、 配置文
件解析 、 事件驅動機制 、 程序管理 等核心功能
標準HTTP模組：提供 HTTP 協議解析相關的功能，比如： 埠配置 、 網頁編碼設定 、
HTTP響應頭設定 等等
可選HTTP模組：主要用於擴充套件標準的 HTTP 功能，讓 Nginx 能處理一些特殊的服務，
比如： Flash 多媒體傳輸 、解析 GeoIP 請求、 網路傳輸壓縮 、 安全協議 SSL 支援等
郵件服務模組：主要用於支援 Nginx 的 郵件服務 ，包括對 POP3 協議、 IMAP 協議和
SMTP協議的支援
第三方模組：是為了擴充套件 Nginx 伺服器應用，完成開發者自定義功能，比如： Json 支援、
Lua 支援等
nginx的功用
靜態的web資源伺服器
html，圖片，js，css，txt等靜態資源
結合FastCGI/uWSGI/SCGI等協議反向代理動態資源請求
http/https協議的反向代理
imap4/pop3協議的反向代理
tcp/udp協議的請求轉發（反向代理）
nginx目錄結構和命令
ls /usr/local/nginx/
html是測試頁，sbin是主程式
ls /usr/local/nginx/sbin/
nginx 只有一個程式檔案
ls /usr/local/nginx/html/
50x.html index.html 測試網頁
Nginx：預設為啟動nginx
-h 檢視幫助選項
-V 檢視版本和配置選項
-t 測試nginx語法錯誤
-c filename 指定配置檔案(default: /etc/nginx/nginx.conf)
-s signal 傳送訊號給master程序，signal：stop, quit, reopen, reload
示例： nginx -s stop 停止nginx
nginx -s reload 載入配置檔案
-g directives 在命令列中指明全域性指令
nginx配置
配置檔案的組成部分：
主配置檔案：nginx.conf
子配置檔案 include conf.d/*.conf
fastcgi， uwsgi，scgi等協議相關的配置檔案
mime.types：支援的mime型別
主配置檔案的配置指令：
directive value [value2 ...];
注意：
(1) 指令必須以分號結尾
(2) 支援使用配置變數
內建變數：由Nginx模組引入，可直接引用
自定義變數：由使用者使用set命令定義
set variable_name value;
引用變數：$variable_name
主配置檔案結構：四部
main block：主配置段，即全域性配置段，對http,mail都有效
event {
...
} 事件驅動相關的配置
http {
...
} http/https 協議相關配置段
mail {
...
} mail 協議相關配置段
stream {
...
} stream 伺服器相關配置段
http協議相關的配置結構
http {
...
... 各server的公共配置
server { 每個server用於定義一個虛擬主機
...
}
server {
...
server_name 虛擬主機名
root 主目錄
alias 路徑別名
location [OPERATOR] URL { 指定URL的特性
...
if CONDITION {
...
}
}
}
}
Main 全域性配置段常見的配置指令分類
正常執行必備的配置
優化效能相關的配置
用於除錯及定位問題相關的配置
事件驅動相關的配置
幫助文件
http://nginx.org/en/docs/
正常執行必備的配置
1、user
指定worker程序的執行身份，如組不指定，預設和使用者名稱同名
Syntax: user user [group];
Default: user nobody nobody;
Context: main
2、pid /PATH/TO/PID_FILE;
指定儲存nginx主程序PID的檔案路徑
3、include file | mask;
指明包含進來的其它配置檔案片斷
4、load_module file ;
模組載入配置檔案： /usr/share/nginx/modules/*.conf
指明要裝載的動態模組路徑： /usr/lib64/nginx/modules
效能優化相關的配置：
1、worker_processes number | auto;
worker程序的數量；通常應該為當前主機的cpu的物理核心數
2、worker_cpu_affinity cpumask ...;
worker_cpu_affinity auto [cpumask] 提高快取命中率
CPU MASK： 00000001：0號CPU
00000010：1號CPU
10000000：8號CPU
worker_cpu_affinity 0001 0010 0100 1000;
worker_cpu_affinity 0101 1010;
3、worker_priority number;
指定worker程序的nice值，設定worker程序優先順序：[-20,20]
4、worker_rlimit_nofile number;
worker程序所能夠開啟的檔案數量上限,如65535
事件驅動相關的配置:
events {
...
}
1、worker_connections number;
每個worker程序所能夠開啟的最大併發連線數數量，如10240
總最大併發數：worker_processes * worker_connections
2、use method;
指明併發連線請求的處理方法 ,預設自動選擇最優方法
示例：use epoll;
3、accept_mutex on | off;
處理新的連線請求的方法；on指由各個worker輪流處理新請求，Off指每個新請求
的到達都會通知(喚醒)所有的worker程序，但只有一個程序可獲得連線造成“驚群”，
影響效能
除錯和定位問題
1、daemon on|off;
是否以守護程序方式執行nignx，預設是守護程序方式
2、master_process on|off;
是否以master/worker模型執行nginx；預設為on,off 將不啟動worker
3、error_log file [level] ;
錯誤日誌檔案及其級別；出於除錯需要，可設定為debug；但debug僅在編譯時使
用了“--with-debug”選項時才有效
/path/logfile： 記錄到檔案中
stderr： 傳送到標準錯誤
syslog：server-address[,parameter=values] 傳送到syslog
memory:size 記憶體
level:debug|info|notice|warn|error|crit|alter|emerg 日誌級別
1、server { ... }
配置一個虛擬主機
server {
listen address[:PORT]|PORT;
server_name SERVER_NAME;
root /PATH/TO/DOCUMENT_ROOT;
}
2、listen PORT|address[:port]|unix:/PATH/TO/SOCKET_FILE
listen address[:port] [default_server] [ssl] [http2 | spdy]
[backlog=number] [rcvbuf=size] [sndbuf=size];
default_server 設定為預設虛擬主機
ssl 限制僅能夠通過ssl連線提供服務
backlog=number 超過併發連線數後，新請求進入後援佇列的長度
rcvbuf=size 接收緩衝區大小
sndbuf=size 傳送緩衝區大小
注意：
(1) 基於port；
listen PORT; 指令監聽在不同的埠
(2) 基於ip的虛擬主機
listen IP:PORT; IP 地址不同
(3) 基於hostname
server_name fqdn; 指令指向不同的主機名
3、server_name name ...;
虛擬主機的主機名稱後可跟多個由空白字元分隔的字串
支援*通配任意長度的任意字元
server_name *.winthcloud.com www.winthcloud.*
支援~起始的字元做正則表示式模式匹配，效能原因慎用
server_name ~^www\d+\.winthcloud\.com$
說明： \d 表示 [0-9]
匹配優先順序機制從高到低
(1) 首先是字串精確匹配 如：www.winthcloud.com
(2) 左側*萬用字元 如：*.winthcloud.com
(3) 右側*萬用字元 如：www.winthcloud.*
(4) 正則表示式 如： ~^.*\.winthcloud\.com$
(5) default_server
4、tcp_nodelay on | off;
在keepalived模式下的連線是否啟用TCP_NODELAY選項
當為off時，延遲傳送，合併多個請求後再發送
預設On時，不延遲傳送
可用於：http, server, location
5、sendfile on | off;
是否啟用sendfile功能，在核心中封裝報文直接傳送,預設Off
6、server_tokens on | off | build | string
是否在響應報文的Server首部顯示nginx版本
定義路徑相關的配置
7、root
設定web資源的路徑對映；用於指明請求的URL所對應的文件的目錄路徑，
可用於http, server, location, if in location
server {
...
root /data/www/vhost1;
}
示例
http://www.winthcloud.com/images/logo.jpg
--> /data/www/vhosts/images/logo.jpg
8、location [ = | ~ | ~* | ^~ ] uri { ... }
location @name { ... }
在一個server中location配置段可存在多個，用於實現從uri到檔案系統的路
徑對映；ngnix會根據使用者請求的URI來檢查定義的所有location，並找出一個
最佳匹配，而後應用其配置
示例：
server {...
server_name www.winthcloud.com;
location /images/ {
root /data/imgs/;
}
}
http://www.winthcloud.com/images/logo.jpg
--> /data/imgs/images/logo.jpg
出現多個時其匹配順序
= 對URI做精確匹配；
location = / {
...
}
http://www.winthcloud.com/ 匹配
http://www.winthcloud.com/index.html 不匹配
^~ 對URI的最左邊部分做匹配檢查，不區分字元大小寫
~ 對URI做正則表示式模式匹配，區分字元大小寫
~* 對URI做正則表示式模式匹配，不區分字元大小寫
不帶符號 匹配起始於此uri的所有的uri
匹配優先順序從高到低：
=, ^~, ～/～*, 不帶符號
9、alias path;
路徑別名，文件對映的另一種機制；僅能用於location上下文
示例：
http://www.winthcloud.com/bbs/index.html
location /bbs {
alias /web/forum/;
} --> /web/forum/index.html 注意： /bbs 後建議不要加 /
location /bbs/ {
root /web/forum/;
} --> /web/forum/bbs/index.html
注意：location中使用root指令和alias指令的意義不同
(a) root，給定的路徑對應於location中的/uri 左側的/
(b) alias，給定的路徑對應於location中的/uri 的完整路徑
10、index file ...;
指定預設網頁檔案，此指令由ngx_http_index_module模組提供
11、error_page code ... [=[response]] uri;
模組：ngx_http_core_module
定義錯誤頁，以指定的響應狀態碼進行響應
可用位置：http, server, location, if in location
error_page 404 /404.html
error_page 404 =200 /404.html
error_page 404 =302 /index.html
12、try_files file ... uri;
try_files file ... =code;
按順序檢查檔案是否存在，返回第一個找到的檔案或資料夾（結尾加斜線表示為文
件夾），如果所有檔案或資料夾都找不到，會進行一個內部重定向到最後一個引數。
只有最後一個引數可以引起一個內部重定向，之前的引數只設置內部URI的指向。最
後一個引數是回退URI且必須存在，否則會出現內部500錯誤
location /images/ {
try_files $uri /images/default.gif;
} 說明：/images/default.gif是URI
location / {
try_files $uri $uri/index.html $uri.html =404;
}
定義客戶端請求的相關配置
13、keepalive_timeout timeout [header_timeout];
設定保持連線超時時長，0表示禁止長連線，預設為75s
14、keepalive_requests number;
在一次長連線上所允許請求的資源的最大數量，預設為100
15、keepalive_disable none | browser ...;
對哪種瀏覽器禁用長連線
16、send_timeout time;
向客戶端傳送響應報文的超時時長，此處是指兩次寫操作之間的間隔時長，而非整個
響應過程的傳輸時長
17、client_body_buffer_size size;
用於接收每個客戶端請求報文的body部分的緩衝區大小；預設為16k；超出此大小時，
其將被暫存到磁碟上的由下面client_body_temp_path指令所定義的位置
18、client_body_temp_path path [level1 [level2 [level3]]];
設定儲存客戶端請求報文的body部分的臨時儲存路徑及子目錄結構和數量
目錄名為16進位制的數字；
client_body_temp_path /var/tmp/client_body 1 2 2
1 1級目錄佔1位16進位制，即2^4=16個目錄 0-f
2 2級目錄佔2位16進位制，即2^8=256個目錄 00-ff
2 3級目錄佔2位16進位制，即2^8=256個目錄 00-ff
對客戶端進行限制的相關配置
19、limit_rate rate;
限制響應給客戶端的傳輸速率，單位是bytes/second
預設值0表示無限制
20、limit_except method ... { ... }，僅用於location
限制客戶端使用除了指定的請求方法之外的其它方法
method:GET, HEAD, POST, PUT, DELETE，MKCOL, COPY, MOVE, OPTIONS,
PROPFIND, PROPPATCH, LOCK, UNLOCK, PATCH
limit_except GET {
allow 192.168.1.0/24;
deny all;
}
除了GET和HEAD 之外其它方法僅允許192.168.1.0/24網段主機使用
檔案操作優化的配置
21、aio on | off | threads[=pool];
是否啟用aio功能 asynchronous I/O
22、directio size | off;
當檔案大於等於給定大小時，例如directio 4m，同步（直接）寫磁碟，而非寫快取
23、open_file_cache off;
open_file_cache max=N [inactive=time];
nginx可以快取以下三種資訊：
(1) 檔案元資料：檔案的描述符、檔案大小和最近一次的修改時間
(2) 開啟的目錄結構
(3) 沒有找到的或者沒有許可權訪問的檔案的相關資訊
max=N：可快取的快取項上限；達到上限後會使用LRU演算法實現管理
inactive=time：快取項的非活動時長，在此處指定的時長內未被命中的或命中
的次數少於open_file_cache_min_uses指令所指定的次數的快取項即為非活動項，
將被刪除
24、open_file_cache_errors on | off;
是否快取查詢時發生錯誤的檔案一類的資訊
預設值為off
25、open_file_cache_min_uses number;
open_file_cache指令的inactive引數指定的時長內，至少被命中此處指定的次數
方可被歸類為活動項
預設值為1
26、open_file_cache_valid time;
快取項有效性的檢查頻率
預設值為60s