Nginx服務基本概念、配置詳解和反向代理

時間 2020-01-05

原文原文鏈接

Nginx服務基本概念、配置詳解和反向代理javascript

-----------------------------------------------------------------------------------------------------------------------------------------
php

1、httpd MPM（多路處理模塊）：css

(1)prefork：進程模型，兩級結構，root用戶開啓主進程master負責生成子進程apache，每一個子進程負責響應一個請求，兼容性相對於其它兩種模式是最好的html

(2)worker：線程模型，三級結構，主進程master負責生成子進程，每一個子進程負責生成多個線程，每一個線程響應一個請求前端

(3)event：線程模型，三級結構,主進程master負責生成子進程，每一個子進程響應多個請求java

2、I/O介紹:node

PIO：應用程序的輸入輸出，file-->cpu-->ram，每次文件輸入輸出都要通過cpu，形成cpu很忙python

DMA：直接內存訪問，當cpu收到請求須要讀取一個文件，cpu只須要發送一個指令就完了，不參與IO的過程，剩下的工做是DMAC（直接內存訪問控制器）工做，將磁盤上的文件讀入內存中mysql

一、I/O分類:linux

網絡IO：本質是socket讀取

磁盤IO：

二、、每次IO，都要經由兩個階段：

第一步：將數據從磁盤文件先加載至內核內存空間（緩衝區），等待數據準備完成，時間較長

第二步：將數據從內核緩衝區複製到用戶空間的進程的內存中，時間較短

三、同步/異步：關注的是消息通訊機制

同步：synchronous，調用者等待被調用者返回消息，才能繼續執行

異步：asynchronous，被調用者經過狀態、通知或回調機制主動通知調用者被調用者的運行狀態

四、阻塞/非阻塞：關注調用者在等待結果返回以前所處的狀態

阻塞：blocking，指IO操做須要完全完成後才返回到用戶空間，調用結果返回以前，調用者被掛起

非阻塞：nonblocking，指IO操做被調用後當即返回給用戶一個狀態值，無需等到IO操做完全完成，最終的調用結果返回以前，調用者不會被掛起

同步阻塞：調用者等待被調用者返回消息，調用結果返回以前，調用者被掛起

同步非阻塞

異步阻塞

異步非阻塞：最佳選擇

五、I/O模型：

阻塞型、非阻塞型、複用型、信號驅動型、異步

六、同步阻塞IO模型

(1)同步阻塞IO模型是最簡單的IO模型，用戶線程在內核進行IO操做時被阻塞

(2)用戶線程經過系統調用read發起IO讀操做，由用戶空間轉到內核空間。內核等到數據包到達後，而後將接收的數據拷貝到用戶空間，完成read操做

(3)用戶須要等待read將數據讀取到buffer後，才繼續處理接收的數據。整個IO請求的過程當中，用戶線程是被阻塞的，這致使用戶在發起IO請求時，不能作任何事情，對CPU的資源利用率不夠

七、同步非阻塞IO模型，程序時不時詢問內核數據是否準備好

(1)用戶線程發起IO請求時當即返回。但並未讀取到任何數據，用戶線程須要不斷地發起IO請求，直到數據到達後，才真正讀取到數據，繼續執行。即「輪詢」機制

(2)整個IO請求的過程當中，雖然用戶線程每次發起IO請求後能夠當即返回，可是爲了等到數據，仍須要不斷地輪詢、重複請求，消耗了大量的CPU的資源

(3)是比較浪費CPU的方式，通常不多直接使用這種模型，而是在其餘IO模型中使用非阻塞IO這一特性

八、IO多路複用模型

(1)多個鏈接（用戶請求，圖中的select處）共用一個等待機制，本模型會阻塞進程，可是進程是阻塞在select或者poll這兩個系統調用上，而不是阻塞在真正的IO操做上

(2)用戶首先將須要進行IO操做添加到select中，繼續執行作其餘的工做（異步），同時等待select系統調用返回。當數據到達時，IO被激活，select函數返回。用戶線程正式發起read請求，讀取數據並繼續執行

(3)從流程上來看，使用select函數進行IO請求和同步阻塞模型沒有太大的區別，甚至還多了添加監視IO，以及調用select函數的額外操做，效率更差。而且阻塞了兩次，可是第一次阻塞在select上時，select能夠監控多個IO上是否已有IO操做準備就緒，便可達到在同一個線程內同時處理多個IO請求的目的。而不像阻塞IO那種，一次只能監控一個IO

(4)雖然上述方式容許單線程內處理多個IO請求，可是每一個IO請求的過程仍是阻塞的（在select函數上阻塞），平均時間甚至比同步阻塞IO模型還要長。若是用戶線程只是註冊本身須要的IO請求，而後去作本身的事情，等到數據到來時再進行處理，則能夠提升CPU的利用率

(5)IO多路複用是最常使用的IO模型，可是其異步程度還不夠「完全」，因它使用了會阻塞線程的select系統調用。所以IO多路複用只能稱爲異步阻塞IO模型，而非真正的異步IO

(6)IO多路複用是指內核一旦發現進程指定的一個或者多個IO條件準備讀取，就通知該進程

(7)IO多路複用適用以下場合：

當客戶端處理多個描述符時（通常是交互式輸入和網絡套接口），必須使用I/O複用

當一個客戶端同時處理多個套接字時，此狀況可能的但不多出現

當一個TCP服務器既要處理監聽套接字，又要處理已鏈接套接字，通常也要用到I/O複用

當一個服務器即要處理TCP，又要處理UDP，通常要使用I/O複用

當一個服務器要處理多個服務或多個協議，通常要使用I/O複用

九、信號驅動IO模型

(1)信號驅動IO：signal-driven I/O

(2)用戶進程能夠經過sigaction系統調用註冊一個信號處理程序，而後主程序能夠繼續向下執行，當有IO操做準備就緒時，由內核通知觸發一個SIGIO信號處理程序執行，而後將用戶進程所須要的數據從內核空間拷貝到用戶空間

(3)此模型的優點在於等待數據報到達期間進程不被阻塞。用戶主程序能夠繼續執行，只要等待來自信號處理函數的通知

(4)該模型並不經常使用

十、異步IO模型

(1)異步IO與信號驅動IO最主要的區別是信號驅動IO是由內核通知什麼時候能夠進行IO操做，而異步IO則是由內核告訴用戶線程IO操做什麼時候完成。信號驅動IO當內核通知觸發信號處理程序時，信號處理程序還須要阻塞在從內核空間緩衝區拷貝數據到用戶空間緩衝區這個階段，而異步IO直接是在第二個階段完成後，內核直接通知用戶線程能夠進行後續操做了

(2)相比於IO多路複用模型，異步IO並不十分經常使用，很多高性能併發服務程序使用IO多路複用模型+多線程任務處理的架構基本能夠知足需求。目前操做系統對異步IO的支持並不是特別完善，更多的是採用IO多路複用模型模擬異步IO的方式（IO事件觸發時不直接通知用戶線程，而是將數據讀寫完畢後放到用戶指定的緩衝區中）

十一、五種IO模型總結

blocked：阻塞

sysnchronous：同步

asynchronous：異步

十二、I/O模型的具體實現

主要實現方式有如下幾種：

Select：Linux實現對應，I/O複用模型，BSD4.2最先實現

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）模型

1三、select/poll/epoll

遍歷：逐個去尋找

(1)Select：POSIX所規定，目前幾乎在全部的平臺上支持，其良好跨平臺支持也是它的一個優勢，本質上是經過設置或者檢查存放fd標誌位的數據結構來進行下一步處理，apache用的此機制

缺點：

單個進程可監視的fd數量被限制，即能監聽端口的數量有限，cat /proc/sys/fs/file-max

對socket是線性掃描，即採用輪詢的方法，效率較低

select 採起了內存拷貝方法來實現內核將 FD 消息通知給用戶空間，這樣一個用來存放大量fd的數據結構，這樣會使得用戶空間和內核空間在傳遞該結構時複製開銷大

(2)poll：本質上和select沒有區別，它將用戶傳入的數組拷貝到內核空間，而後查詢每一個fd對應的設備狀態

其沒有最大鏈接數的限制，緣由是它是基於鏈表來存儲的

大量的fd的數組被總體複製於用戶態和內核地址空間之間，而無論這樣的複製是否是有意義

poll特色是「水平觸發」，若是報告了fd後，沒有被處理，那麼下次poll時會再次報告該fd

邊緣觸發：只通知一次

(3)epoll：在Linux 2.6內核中提出的select和poll的加強版本，nginx使用此機制

支持水平觸發LT和邊緣觸發ET，最大的特色在於邊緣觸發，它只告訴進程哪些fd剛剛變爲就需態，而且只會通知一次

使用「事件」的就緒通知方式，經過epoll_ctl註冊fd，一旦該fd就緒，內核就會採用相似callback的回調機制來激活該fd，epoll_wait即可以收到通知

優勢:

沒有最大併發鏈接的限制：能打開的FD的上限遠大於1024(1G的內存能監聽約10萬個端口)

效率提高：非輪詢的方式，不會隨着FD數目的增長而效率降低；只有活躍可用的FD纔會調用callback函數，即epoll最大的優勢就在於它只管理「活躍」的鏈接，而跟鏈接總數無關

內存拷貝，利用mmap(Memory Mapping)加速與內核空間的消息傳遞；即epoll使用mmap減小複製開銷

3、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模塊

4、nginx的程序架構

一、web服務相關的功能：

虛擬主機（server）

支持 keep-alive 和管道鏈接

訪問日誌（支持基於日誌緩衝提升其性能）

url rewirte

路徑別名

基於IP及用戶的訪問控制

支持速率限制及併發數限制

從新配置和在線升級而無須中斷客戶的工做進程

Memcached 的 GET 接口

二、nginx的程序架構：master/worker結構

一個master進程：

負載加載和分析配置文件、管理worker進程、平滑升級

一個或多個worker進程

處理並響應用戶請求

緩存相關的進程：

cache loader：載入緩存對象

cache manager：管理緩存對象

4、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 支持等

5、nginx的功用

一、靜態的web資源服務器，好比說html，圖片，js，css，txt等靜態資源

二、結合FastCGI/uWSGI/SCGI等協議反向代理動態資源請求

三、http/https協議的反向代理

四、imap4/pop3協議的反向代理

五、tcp/udp協議的請求轉發（反向代理）

6、nginx的安裝

一、官方：

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

點進去

下一步

二、Fedora-EPEL:

https://mirrors.aliyun.com/epel/7/x86_64/，阿里如今提供的版本爲1.12版

3、源碼編譯時注意家目錄/var/lib/nginx

useradd -r -s /sbin/nologin 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

更改源碼：src/core/nginx.h

src/http/ngx_http_header_filter_module.c

編譯安裝nginx選項：

--prefix=/etc/nginx 安裝路徑

--sbin-path=/usr/sbin/nginx 指明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 指明pid文件安裝位置

--lock-path=/var/run/nginx.lock 鎖文件安裝位置

--http-client-body-temp-path=/var/cache/nginx/client_temp 客戶端body部分的臨時文件存放路徑，服務器容許客戶端使用put方法提交大數據時，臨時存放的磁盤路徑

--http-proxy-temp-path=/var/cache/nginx/proxy_temp 做爲代理服務器，服務器響應報文的臨時文件存放路徑

--http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp 做爲fastcgi代理服務器，服務器響應報文的臨時文件存放路徑

--http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp 做爲uwsgi代理服務器，服務器響應報文的臨時文件存放路徑

--http-scgi-temp-path=/var/cache/nginx/scgi_temp 做爲scgi反代服務器，服務器響應報文的臨時文件存放路徑

--user=nginx 指明以那個身份運行worker進程，主控master進程通常由root運行

--group=nginx

--with-http_ssl_module 表示把指定模塊編譯進來

編譯完成後界面：

版本修改結果

7、nginx的使用

一、ls /usr/local/nginx/

html是測試頁，sbin是主程序

二、ls /usr/local/nginx/sbin/

nginx 只有一個程序文件

三、ls /usr/local/nginx/html/

50x.html index.html 測試網頁

四、systemctl start nginx.service，若用此命令開啓，管理用systemctl命令

命令：nginx，啓動nginx，若用此命令啓動，管理用nginx -s命令

-v，顯示信息

-V，顯示安裝信息

-t，檢查配置文件語法

-T，檢查配置文件語法並顯示配置文件內容

-q，配置文件壓縮過程當中不顯示非錯誤信息

-s，發送信號，nginx -s stop quit reopen reload

-p，設置安裝目錄

-c，從哪讀取配置文件

-g，設置全局設置

8、nginx配置

一、配置文件的組成部分：

(1)主配置文件：/etc/nginx.conf

子配置文件：/etc/nginx/conf.d/*.conf

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

(3)mime.types：支持的mime類型

二、主配置文件的配置指令：

directive value [value2 ...];

三、注意：

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

(2) 支持使用配置變量

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

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

set variable_name value;

引用變量：$variable_name

四、主配置文件結構：四部

main block：主配置段，即全局配置段，對http,mail都有效

(1)event {

...

} 事件驅動相關的配置

(2)http {

...

} http/https 協議相關配置段

(3)mail {

...

} mail 協議相關配置段

(4)stream {

...

} stream 服務器相關配置段

五、Main 全局配置段常見的配置指令分類

(1)正常運行必備的配置

(2)優化性能相關的配置

(3)用於調試及定位問題相關的配置

(4)事件驅動相關的配置

幫助文檔：http://nginx.org/en/docs/

六、正常運行必備的配置：

(1)user

指定以誰的身份運行worker進程，如組不指定，默認和用戶名同名

Syntax: user user [group];

Default: user nobody nobody;

Context: main

默認nginx

進程

改成apache後

(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的親緣性，worker進程綁定在哪顆cpu上工做

worker_cpu_affinity auto [cpumask] 提升緩存命中率

CPU上有緩存，而進程常常會切換CPU，切換CPU後原來CPU上的緩存就無法利用了，這樣會影響當前效率

CPU MASK：

00000001：0號CPU，從0開始算第一顆CPU

00000010：1號CPU

10000000：7號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，表現形式爲一個socket文件

八、事件驅動相關的配置:

events {

...

}

(1)worker_connections 10240;

每一個worker進程所可以打開的最大併發鏈接數數量，如10240

總最大併發數：worker_processes * worker_connections

(2)use method;

指明併發鏈接請求的處理方法 ,默認自動選擇最優方法

示例：use epoll;

(3)accept_mutex on | off;，on由各個worker接收新的進程，off每一個新來的請求都會通知worker進程但最後只會有一個worker進程獲得處理

處理新的鏈接請求的方法；on指由各個worker輪流處理新請求，Off指每一個新請求的到達都會通知(喚醒)全部的worker進程，但只有一個進程可得到鏈接，形成「驚羣」，影響性能

九、調試和定位問題：（通常測試環境用）

(1)daemon on|off;，在模塊外面寫

是否以守護進程方式運行nignx，默認是守護進程方式

(2)master_process on|off;

是否以master/worker模型運行nginx；默認爲on,off 將不啓動worker

(3)rror_log file [level] ;

錯誤日誌文件及其級別；出於調試須要，可設定爲debug；但debug僅在編譯時使用了「--with-debug」選項時纔有效

/path/logfile：記錄到文件中

stderr：發送到標準錯誤

syslog：server-address[,parameter=values] 發送到syslog

memory:size 內存

9、http協議的相關配置：

http {

... ...

server { -------->該語句塊必定嵌套在http語句裏

...

server_name

root

location [OPERATOR] /uri/ {

...

}

server {

...

}

一、ngx_http_core_module

與套接字相關的配置：

(1)server { ... }

配置一個虛擬主機

server {

listen address[:PORT]|PORT;

server_name SERVER_NAME;

root /PATH/TO/DOCUMENT_ROOT;

}

能夠在路徑/etc/nginx/conf.d/下新建文件

建立虛擬主機

在訪問機的hosts文件添加解析，分別對www.a.com www.b.com wwwc.com進行curl

(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>基於hostnameserver_name fqdn; 指令指向不一樣的主機名

當存在

且主配置文件中

結果爲

緣由爲

當存在

結果理所固然爲

(3)server_name name ...;

虛擬主機的主機名稱後可跟多個由空白字符分隔的字符串

支持*通配任意長度的任意字符，server_name *.magedu.com www.magedu.*

支持~起始的字符作正則表達式模式匹配，性能緣由慎用

server_name ~^www\d+\.magedu\.com$

說明： \d 表示 [0-9]

匹配優先級機制從高到低

<1>首先是字符串精確匹配如：www.magedu.com

<2>左側*通配符如：*.magedu.com

<3>右側*通配符如：www.magedu.*

<4>正則表達式如： ~^.*\.magedu\.com$

<5>default_server

(4)tcp_nodelay on | off;，對於用戶端而要on，對於客戶端要Off

長鏈接：鏈接創建後用戶還能夠發送屢次請求

短鏈接：鏈接一次後立馬斷開

在keepalived模式下的鏈接是否啓用TCP_NODELAY選項

當爲off時，延遲發送，合併多個請求後再發送

默認On時，不延遲發送

可用於：http, server, location

(5)sendfile on | off;，爲優化性能，此項最好是ON

是否啓用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; ------>指定家目錄的工做路徑

}

當在nginx網站目錄下建立軟連接指向一個其它位置的文件，訪問該軟連接能夠直接得到該文件，好比說

測試後有

(8)location [ = | ~ | ~* | ^~ ] uri { ... }，用來定義訪問資源的路徑，路徑是uri路徑

location @name { ... }

在一個server中location配置段可存在多個，用於實現從uri到文件系統的路徑映射；ngnix會根據用戶請求的URI來檢查定義的全部location，並找出一個最佳匹配，然後應用其配置

示例：

server {...

server_name www.a.com;

location /images/ {

root /data/imgs/;

}

http://www.a.com/images/logo.jpg

--> /data/imgs/images/logo.jpg

有配置

結果

= 對URI作精確匹配；

location = / {

...

}

http://www.a.com/ 匹配

http://www.a.com/index.html 不匹配

^~ 對URI作匹配檢查，不區分字符大小寫，匹配符合之後，中止往下搜索

~ 對URI作正則表達式模式匹配，區分字符大小寫

~* 對URI作正則表達式模式匹配，不區分字符大小寫

不帶符號匹配起始於此uri的全部的uri

匹配優先級從高到低：

=, ^~, ～/～*, 不帶符號

(location =) > (location 完整路徑) > (location ^~ 路徑) > (location ~,~* 正則順序) > (location 部分起始路徑) > (/)

示例：

server {

root /vhosts/www/htdocs/ ;雖然根目錄是在 /vhosts/www/htdocs/

location /admin/ {但location的定義是隨着它語句下的root目錄變化的

root /apps/app1/data/;

}

http://www.chenux.com/admin/index.html當訪問網址的www.chenux.com/admin/index.html

--> /apps/app1/data/admin/index.html實質訪問的是/apps/app1/data//admin/index.html

---------------------------------------------------------------------------------------------------------------------

location = / {http://www.chenux.com/

[ configuration A ]

}

---------------------------------------------------------------------------------------------------------------------

location / {http://www.chenux.com/index.html

[ configuration B ]

}

---------------------------------------------------------------------------------------------------------------------

location /documents/ {http://www.chenux.com/documents/logo.jpg

[ configuration C ]

}

---------------------------------------------------------------------------------------------------------------------

location ^~ /images/ {http://www.chenux.com/images/linux.txt

[ configuration D ]

}

---------------------------------------------------------------------------------------------------------------------

location ~* \.(gif|jpg|jpeg)$ {http://www.chenux.com/images/logo.jpeg

[ configuration E ]

}

(9)alias path;，只能在location裏

路徑別名，文檔映射的另外一種機制；僅能用於location上下文，放到alias裏

示例：

http://www.magedu.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 的完整路徑，以後alias內目錄內容將完整替換location中的目錄

(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，當頁面報404的時候返回404.html

error_page 404 =200 /404.html，當頁面報404的時候返回錯誤碼200，此時指向頁面404.html

演示一

演示二

附錯誤碼

200：成功，請求數據經過響應報文的entity-body部分發送;OK

301：請求的URL指向的資源已經被刪除；但在響應報文中經過首部Location指明瞭資源如今所處的新位置；Moved Permanently，永久重定向，該域名將被淘汰

302：響應報文Location指明資源臨時新位置Moved Temporarily，臨時重定向，域名保留

304：客戶端發出了條件式請求，但服務器上的資源不曾發生改變，則經過響應此響應狀態碼通知客戶端；Not Modified，利用瀏覽器自身的緩存進行響應

401：須要輸入帳號和密碼認證方能訪問資源；Unauthorized

403：請求被禁止；Forbidden

404：服務器沒法找到客戶端請求的資源；Not Found

500：服務器內部錯誤；Internal Server Error

502：代理服務器從後端服務器收到了一條僞響應，如沒法鏈接到網關；Bad Gateway

503：服務不可用，臨時服務器維護或過載，服務器沒法處理請求

504：網關超時

(12)try_files file ... uri;，找不到鏈接了，給用戶返回個文件

try_files file ... =code;

按順序檢查文件是否存在，返回第一個找到的文件或文件夾（結尾加斜線表示爲文件夾），若是全部文件或文件夾都找不到，會進行一個內部重定向到最後一個參數。只有最後一個參數能夠引發一個內部重定向，以前的參數只設置內部URI的指向。最後一個參數是回退URI且必須存在，不然會出現內部500錯誤

location /images/ {

try_files $uri /images/default.gif;

}

說明：/images/default.gif是URI，當訪問images下不存在的圖片時候，將自動返回默認的頁面default.gif

測試結果

---------------------------------------------------------------------------------------------------------------------

location / {

try_files $uri $uri/index.html $uri.html =404;

}

---->嘗試尋找連接，找不到就找連接下index.html，再找不到就找連接.html，再找不到則返回404碼

(13)定義客戶端請求的相關配置

<1>keepalive_timeout timeout [header_timeout];，非遊戲網站調稍微短些

設定保持鏈接超時時長，0表示禁止長鏈接，默認爲75s

<2>keepalive_requests number;

在一次長鏈接上所容許請求的資源的最大數量，默認爲100

<3>keepalive_disable none | browser ...;

對哪一種瀏覽器禁用長鏈接

<4>send_timeout time;

向客戶端發送響應報文的超時時長，此處是指兩次寫操做之間的間隔時長，而非整個響應過程的傳輸時長

<5>client_body_buffer_size size;

用於接收每一個客戶端請求報文的body部分的緩衝區大小；默認爲16k；超出此大小時，其將被暫存到磁盤上的由下面client_body_temp_path指令所定義的位置

<6>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

(14)對客戶端進行限制的相關配置

<1>limit_rate rate;

限制響應給客戶端的傳輸速率，單位是bytes/second

默認值0表示無限制

測試

<2>imit_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網段主機使用

測試

(15)文件操做優化的配置

<1>aio on | off | threads[=pool];

是否啓用aio功能

<2>directio size | off;

當文件大於等於給定大小時，例如directio 4m，同步（直接）寫磁盤，而非寫緩存

<3>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指令所指定的次數的緩存項即爲非活動項，將被刪除

(16)open_file_cache_errors on | off;

是否緩存查找時發生錯誤的文件一類的信息

默認值爲off

(17)open_file_cache_min_uses number;

open_file_cache指令的inactive參數指定的時長內，至少被命中此處指定的次數方可被歸類爲活動項

默認值爲1

(18)open_file_cache_valid time;

緩存項有效性的檢查頻率

默認值爲60s

二、ngx_http_access_module

ngx_http_access_module模塊，可實現基於ip的訪問控制功能

(1)allow address | CIDR | unix: | all;

(2)deny address | CIDR | unix: | all;

http, server, location, limit_except

自上而下檢查，一旦匹配，將生效，條件嚴格的置前

示例：

location / {

deny 192.168.1.1;

allow 192.168.1.0/24;

allow 10.1.1.0/16;

allow 2001:0db8::/32;

deny all;

}

測試

三、ngx_http_auth_basic_module，驗證模塊

(1)ngx_http_auth_basic_module模塊

實現基於用戶的訪問控制，使用basic機制進行用戶認證

(2)auth_basic string | off;

(3)auth_basic_user_file file;

location /admin/ {

auth_basic "Admin Area";

auth_basic_user_file /etc/nginx/.ngxpasswd;

}

用戶口令文件：

<1>明文文本：格式name:password:comment

<2>加密文本：由htpasswd命令實現

httpd-tools所提供

演示：

創建驗證目錄

yum -y install httpd-tools

利用htpasswd命令實現，

配置文件裏添加

測試

命令行測試

四、ngx_http_stub_status_module模塊

(1)用於輸出nginx的基本狀態信息

輸出信息示例：

Active connections: 291

server accepts handled requests

16630948 16630948 31070465

上面三個數字分別對應accepts,handled,requests三個值

Reading: 6 Writing: 179 Waiting: 106

Active connections:當前狀態，活動狀態的鏈接數

accepts：統計總值，已經接受的客戶端請求的總數

handled：統計總值，已經處理完成的客戶端請求的總數

requests：統計總值，客戶端發來的總的請求數

Reading：當前狀態，正在讀取客戶端請求報文首部的鏈接的鏈接數

Writing：當前狀態，正在向客戶端發送響應報文過程當中的鏈接數

Waiting：當前狀態，正在等待客戶端發出請求的空閒鏈接數

(2)stub_status;

示例：location /status {

stub_status;

allow 172.16.0.0/16;

deny all;

}

結果頁面

五、ngx_http_log_module

ngx_http_log_module模塊，指定日誌格式記錄請求

(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_uses：在inactive指定的時長內訪問大於等於此值方可被看成活動項

inactive：非活動時長

valid：驗證緩存中各緩存項是否爲活動項的時間間隔

六、ngx_http_gzip_module

(1)gzip on | off;

啓用或禁用gzip壓縮

(2)gzip_comp_level level;

壓縮比由低到高：1 到 9

默認：1

(3)gzip_disable regex ...;

匹配到客戶端瀏覽器不執行壓縮

(4)gzip_min_length length;

啓用壓縮功能的響應報文大小閾值

(5)gzip_http_version 1.0 | 1.1;

設定啓用壓縮功能時，協議的最小版本

默認：1.1

(6)gzip_buffers number size;

支持實現壓縮功能時緩衝區數量及每一個緩存區的大小

默認：32 4k 或 16 8k

(7)gzip_types mime-type ...;

指明僅對哪些類型的資源執行壓縮操做；即壓縮過濾器

默認包含有text/html，不用顯示指定，不然出錯

(8)gzip_vary on | off;

若是啓用壓縮，是否在響應報文首部插入「Vary: Accept-Encoding」

nginx充當代理服務器時，對於後端服務器的響應報文，在何種條件下啓用壓縮功能

off：不啓用壓縮

expired，no-cache, no-store，private：對後端服務器的響應報文首部Cache-Control值任何一個，啓用壓縮功能

示例：

gzip on;

gzip_comp_level 6;

gzip_min_length 64;

gzip_proxied any;

gzip_types text/xml text/css application/javascript;

gzip_vary on

七、ngx_http_ssl_module模塊：，

(1)ssl on | off;

爲指定虛擬機啓用HTTPS protocol，建議用listen指令代替

(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];

none: 通知客戶端支持ssl session cache，但實際不支持

builtin[:size]：使用OpenSSL內建緩存，爲每worker進程私有

[shared:name:size]：在各worker之間使用一個共享的緩存

(6)ssl_session_timeout time;

客戶端鏈接能夠複用ssl session cache中緩存的有效時長，默認5m

注：一個裝有nginx的物理主機能夠實現多主機的https，apache實現不了此功能

示例：

server {

listen 443 ssl;

server_name www.magedu.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;

ssl_session_timeout 10m;

}

演示：

一、簡單生成自簽名

cd /etc/pki/tls/certs

vim Makefile，註釋此項能夠在生成密鑰時候不用輸入密碼

make a.crt

一臺nginx服務器帶兩個含有ssl的https服務器，apache作不到

八、ngx_http_rewrite_module模塊：

將用戶請求的URI基於PCRE regex所描述的模式進行檢查，然後完成重定向替換

示例：

http://www.magedu.com/hn --> http://www.magedu.com/henan

http://www.magedu.com --> https://www.magedu.com/

(1)rewrite regex replacement [flag]，rewrite 正則表達式替代 flag

將用戶請求的URI基於regex所描述的模式進行檢查，匹配到時將其替換爲replacement指定的新的URI

注意：若是在同一級配置塊中存在多個rewrite規則，那麼會自下而下逐個檢查；被某條件規則替換完成後，會從新一輪的替換檢查

隱含有循環機制,但不超過10次；若是超過，提示500響應碼，[flag]所表示的標誌位用於控制此循環機制

若是replacement是以http://或https://開頭，則替換結果會直接以重向返回給客戶端, 即永久重定向301

[flag]：

last：重寫完成後中止對當前URI在當前location中後續的其它重寫操做，然後對新的URI啓動新一輪重寫檢查；提早重啓新一輪循環，不建議在location中使用，默認

break：重寫完成後中止對當前URI在當前location中後續的其它重寫操做，然後直接跳轉至重寫規則配置塊以後的其它配置；結束循環，建議在location中使用

redirect：臨時重定向，重寫完成後以臨時重定向方式直接返回重寫後生成的新URI給客戶端，由客戶端從新發起請求；使用相對路徑,或者http://或https://開頭，狀態碼：302

permanent:重寫完成後以永久重定向方式直接返回重寫後生成的新URI給客戶端，由客戶端從新發起請求，狀態碼：301

示例：當用戶訪問bbs時候跳轉到forum

測試結果

此能夠說明能夠將/bbs目錄刪除也不會受影響，訪問/bbs時候自動跳轉到/forum

示例：域名跳轉

示例：文件格式訪問替換

示例：訪問http跳轉到https

或者

(2)return

return code [text]; 返回到指定的響應碼

return code URL; 返回到指定的響應碼並跳轉到連接

return URL;

中止處理，並返回給客戶端指定的響應碼，對 301, 302, 303, 307, 308跳轉到URL

(3)rewrite_log on | off;

是否開啓重寫日誌, 發送至error_log（notice level）

(4)set $variable value;

用戶自定義變量

注意：變量定義和調用都要以$開頭

(5)if (condition) { ... }

條件知足時，執行配置塊中的配置指令；server, location

condition：

比較操做符：

= 相同 != 不一樣

~ 模式匹配，區分字符大小寫

~* 模式匹配，不區分字符大小寫

!~ 模式不匹配，區分字符大小寫

!~* 模式不匹配，不區分字符大小寫

跳轉http到https關鍵語句

文件及目錄存在性判斷：

-e，!-e 存在與否（包括文件，目錄，軟連接）

-f，!-f 文件 -d，!-d 目錄 -x，!-x 執行

九、ngx_http_referer_module模塊，防盜鏈，先定義有效的，再條件判斷無效的將作怎樣的處理

用來阻止Referer首部無有效值的請求訪問，可防止盜鏈

(1)valid_referers none|blocked|server_names|string ...;

定義referer首部的合法可用值，不能匹配的將是非法值

none：請求報文首部沒有referer首部

blocked：請求報文有referer首部，但無有效值

server_names：referer首部中包含本主機名

arbitrary_string：任意字符串，但可以使用*做通配符

regular expression：被指定的正則表達式模式匹配到的字符串,要使用~開頭，例如： ~.*\.chenux\.com

示例：

valid_referers none block server_names *.b *.b.com b.*b.* ~\.baidu\. ~\.google\. ;

if ($invalid_referer) {

#return 403 ;

return 301 http://www.b.com;

}

十、ngx_http_proxy_module模塊：

轉發請求至另外一臺主機，只能轉發到一臺

(1)proxy_pass URL;

<1>Context:location, if in location, limit_except

注意：proxy_pass後面路徑不帶uri時，會將location的uri傳遞（附加）給後端主機

server {

...

server_name HOSTNAME;

location /uri/ {

proxy_pass http://host[:port]; 最後沒有/

}

...

}

上面示例：http://HOSTNAME/uri --> http://host/uri

若是上面示例中有 /，即：http://host[:port]/

意味着：http://HOSTNAME/uri --> http://host/ 即置換

<2>proxy_pass後面的路徑是一個uri時，其會將location的uri替換爲proxy_pass的uri

server {

...

server_name HOSTNAME;

location /uri/ {

proxy_pass http://host/new_uri/;

}

...

}

http://HOSTNAME/uri/ --> http://host/new_uri/

<3>若是location定義其uri時使用了正則表達式的模式，則proxy_pass以後必須不能使用uri; 用戶請求時傳遞的uri將直接附加至後端服務器以後

server {

...

server_name HOSTNAME;

location ~|~* /uri/ {

proxy_pass http://host; 不能加/

}

...

}

http://HOSTNAME/uri/ --> http://host/uri/

示例，根據輸入不一樣的主機名反向代理到不一樣主機

首先有nginx配置

其次有apache內虛擬主機配置

最後有結果

<4>proxy_set_header field value;，反向代理後請求報文頭部會丟失，此選項可作添加

設定發日後端主機的請求報文的請求首部的值

Context: http, server, location

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

請求報文的標準格式以下：

X-Forwarded-For: client1, proxy1, proxy2

示例：

一、在apache服務器上的主配置有：

二、在nginx反向代理服務器的配置有

三、

<5>proxy_cache_path;

定義可用於proxy功能的緩存；Context:http，內容只能在http裏寫

proxy_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=time] [loader_threshold=time] [purger=on|off] [purger_files=number] [purger_sleep=time] [purger_threshold=time];

<6>proxy_cache zone | off; 默認off

指明調用的緩存，或關閉緩存機制；Context:http, server, location

<7>proxy_cache_key string;

緩存中用於「鍵」的內容

默認值：proxy_cache_key $scheme$proxy_host$request_uri;

<8>proxy_cache_valid [code ...] time;

定義對特定響應碼的響應內容的緩存時長

定義在http{...}中

示例:

proxy_cache_valid 200 302 10m;

proxy_cache_valid 404 1m;

示例：在http配置定義緩存信息

proxy_cache_path /var/cache/nginx/proxy_cache

levels=1:1:1 keys_zone=proxycache:20m

inactive=120s max_size=1g;

說明：proxycache:20m 指內存中緩存的大小，主要用於存放key和metadata（如：使用次數）

max_size=1g 指磁盤存入文件內容的緩存空間最大值

調用緩存功能，須要定義在相應的配置段，如server{...}；

proxy_cache proxycache;

proxy_cache_key $request_uri;

proxy_cache_valid 200 302 301 1h;

proxy_cache_valid any 1m;

示例：開啓緩存功能

再到nginx單獨配置主機的配置文件中添加

當curl後會在自定義的目錄裏產生緩存

<9>proxy_cache_use_stale;

在被代理的後端服務器出現哪一種狀況下，可直接使用過時的緩存響應客戶端

<10>proxy_cache_methods GET | HEAD | POST ...;

對哪些客戶端請求方法對應的響應進行./緩存

，GET和HEAD方法老是被緩存

<11>proxy_hide_header field;

默認nginx在響應報文中不傳遞後端服務器的首部字段Date, Server, X-Pad, X-Accel-等，用於隱藏後端服務器特定的響應首部

<12>proxy_connect_timeout time;

定義與後端服務器創建鏈接的超時時長，如超時會出現502錯誤，默認爲60s，通常不建議超出75s

<13>proxy_send_timeout time;

將請求發送給後端服務器的超時時長；默認爲60s

<14>proxy_read_timeout time;

等待後端服務器發送響應報文的超時時長，默認爲60s

十一、ngx_http_headers_module模塊

向由代理服務器響應給客戶端的響應報文添加自定義首部，或修改指定首部的值

(1)add_header name value [always];

添加自定義首部

add_header X-Via $server_addr;

add_header X-Cache $upstream_cache_status;

add_header X-Accel $server_name;

$upstream_cache_status：查看後端服務器獲得的緩存狀態，命中、未命中、過時等等

示例

結果

(2)add_trailer name value [always];

添加自定義響應信息的尾部

附：動靜分離關鍵代碼（一臺httpd，另外一臺http+php）

同構拓撲圖

關鍵代碼

十二、ngx_http_fastcgi_module

ngx_http_fastcgi_module模塊，轉發請求到FastCGI服務器，不支持php模塊方式

(1)fastcgi_pass address;，後端服務器爲fastcgi，反向代理必須用此選項

address爲後端的fastcgi server的地址

可用位置：location, if in location

(2)fastcgi_index name;

fastcgi默認的主頁資源

示例：fastcgi_index index.php;

(3)fastcgi_param parameter value [if_not_empty];

設置傳遞給 FastCGI服務器的參數值，能夠是文本，變量或組合

參數在/etc/nginx/fastcgi_params.default文件中

示例1：

[1]在後端服務器先配置fpm server和mariadb-server

[2]在前端nginx服務上作如下配置：

location ~* \.php$ {

fastcgi_pass 後端fpm服務器IP:9000;

fastcgi_index index.php;

fastcgi_param SCRIPT_FILENAME /app/php$fastcgi_script_name;

include fastcgi_params;

…

}

示例2：經過/pm_status和/ping來獲取fpm server狀態信息

location ~* ^/(pm_status|ping)$ {

include fastcgi_params;

fastcgi_pass 後端fpm服務器IP: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=time] [loader_threshold=time] [purger=on|off] [purger_files=number] [purger_sleep=time] [purger_threshold=time];

定義fastcgi的緩存；

path 緩存位置爲磁盤上的文件系統

max_size=size

磁盤path路徑中用於緩存數據的緩存空間上限

levels=levels：緩存目錄的層級數量，以及每一級的目錄數量

levels=ONE:TWO:THREE

示例：leves=1:2:2

keys_zone=name:size

k/v映射的內存空間的名稱及大小

inactive=time

非活動時長

(5)fastcgi_cache zone | off;

調用指定的緩存空間來緩存數據

可用位置：http, server, location

(6)fastcgi_cache_key string;

定義用做緩存項的key的字符串

示例：fastcgi_cache_key $request_rui;

(7)fastcgi_cache_methods GET | HEAD | POST ...;

爲哪些請求方法使用緩存

(8)fastcgi_cache_min_uses number;

緩存空間中的緩存項在inactive定義的非活動時間內至少要被訪問到此處所指定的次數方可被認做活動項

(9)fastcgi_keep_conn on | off;

收到後端服務器響應後，fastcgi服務器是否關閉鏈接，建議啓用長鏈接

(10)fastcgi_cache_valid [code ...] time;

不一樣的響應碼各自的緩存時長

示例：

http {

fastcgi_cache_path /var/cache/nginx/fcgi_cache levels=1:2:1 keys_zone=fcgicache:20m inactive=120s;

...

server {

location ~* \.php$ {

...

fastcgi_cache fcgicache;

fastcgi_cache_key $request_uri;

fastcgi_cache_valid 200 302 10m;

fastcgi_cache_valid 301 1h;

fastcgi_cache_valid any 1m;

...

}

相似於代理服務器緩存，依舊是放在server內

實驗：異構fastcgi轉發

一、安裝配置啓動php

yum -y install php-fpm

vim /etc/php/www.conf

mkdir /data/php -pv，cp test.php /data/php

systemctl start php-fpm

二、vim /etc/nginx/conf.d/*.conf

或者這麼加

其他項

或者fastcgi_pass後走套接字，而不走網絡端口

三、安裝數據庫

yum -y install php-mysql mariadb-server

create database wpdb;

grant all privileges on wpdb.* to 'wpuser'@'localhost' identified by 'wpps'

四、cp -a wordpress/ /data/php

vim wp-config.php

填寫數據庫名稱用戶密碼等

systemctl restart php-fpm

五、由於動靜分離，nginx網站目錄也須要放一個wordpress

1三、ngx_http_upstream_module模塊，後臺調度模塊，自備健康性檢查功能

用於將多個服務器定義成服務器組，而由proxy_pass, fastcgi_pass等指令進行引用

(1)upstream name { ... }

定義後端服務器組，會引入一個新的上下文

默認調度算法是wrr

Context: http

upstream httpdsrvs {

server ...

server...

...

}

(2)server address [parameters];

在upstream上下文中server成員，以及相關的參數；Context:upstream

address的表示格式：

unix:/PATH/TO/SOME_SOCK_FILE

IP[:PORT]

HOSTNAME[:PORT]

parameters：

weight=number 權重，默認爲1

max_conns 鏈接後端報務器最大併發活動鏈接數，1.11.5後支持

max_fails=number 失敗嘗試最大次數；超出此處指定的次數時，server將被標記爲不可用,默認爲1

fail_timeout=time 後端服務器標記爲不可用狀態的鏈接超時時長，默認10s

backup 將服務器標記爲「備用」，即全部服務器均不可用時才啓用，用於sorry server

down 標記爲「不可用」，實現灰度發佈

示例：實現簡單的nginx調度

首先在/etc/nginx/nginx.conf中有

而且

或者此處在在/etc/nginx/conf.d/*.conf中加這段，同樣效果

而後在/etc/nginx/conf.d/*.conf中有

最後測試結果

(3)ip_hash 源地址hash調度方法，基於ip地址哈希值調度到後端服務器

(4)least_conn 最少鏈接調度算法，當server擁有不一樣的權重時其爲wlc，當全部後端主機鏈接數相同時，則使用wrr，適用於長鏈接

(5)hash key [consistent] 基於指定的key的hash表來實現對請求的調度，此處的key能夠直接文本、變量或兩者組合

做用：將請求分類，同一類請求將發往同一個upstream server，使用consistent參數，將使用ketama一致性hash算法，適用於後端是Cache服務器（如varnish）時使用

hash $request_uri consistent;，目標地址哈希，當用戶訪問同一uri時都會調度到同一臺主機

hash $remote_addr;，變向的和ip_hash算法相似，根據客戶端地址分配後臺服務器

(6)keepalive 鏈接數N;

爲每一個worker進程保留的空閒的長鏈接數量，可節約nginx端口，並減小鏈接管理的消耗

(7)health_check [parameters];，注意：僅對nginx plus有效，收費版

健康狀態檢測機制；只能用於location上下文

經常使用參數：

interval=time檢測的頻率，默認爲5秒

fails=number：斷定服務器不可用的失敗檢測次數；默認爲1次

passes=number：斷定服務器可用的失敗檢測次數；默認爲1次

uri=uri：作健康狀態檢測測試的目標uri；默認爲/

match=NAME：健康狀態檢測的結果評估調用此處指定的match配置塊

(8)match name { ... }，注意：僅對nginx plus有效，收費版

對backend server作健康狀態檢測時，定義其結果判斷機制；只能用於http上下文

經常使用的參數：

status code[ code ...]: 指望的響應狀態碼

header HEADER[operator value]：指望存在響應首部，也可對指望的響應首部的值基於比較操做符和值進行比較

body：指望響應報文的主體部分應該有的內容

1四、nginx的其它的二次發行版：

Tengine：由淘寶網發起的Web服務器項目。它在Nginx的基礎上，針對大訪問量網站的需求，添加了不少高級功能和特性。Tengine的性能和穩定性已經在大型的網站如淘寶網，天貓商城等獲得了很好的檢驗。它的最終目標是打造一個高效、穩定、安全、易用的Web平臺。從2011年12月開始，Tengine成爲一個開源項目，官網 http://tengine.taobao.org/

OpenResty：基於 Nginx 與 Lua 語言的高性能 Web 平臺

ngx_stream_core_module模塊

模擬反代基於tcp或udp的服務鏈接，即工做於傳輸層的反代或調度器

1五、ngx_stream_proxy_module模塊

可實現代理基於TCP，UDP (1.9.13), UNIX-domain sockets的數據流

(1)proxy_pass address;

指定後端服務器地址

(2)proxy_timeout timeout;

無數據傳輸時，保持鏈接狀態的超時時長

默認爲10m

(3)proxy_connect_timeout time;

設置nginx與被代理的服務器嘗試創建鏈接的超時時長

默認爲60s

實現結果是telnet IP時候telnet的後臺服務器在輪詢

1六、實現Nginx高併發Linux內核優化

因爲默認的Linux內核參數考慮的是最通用場景，這明顯不符合用於支持高併發訪問的Web服務器的定義，因此須要修改Linux內核參數，是的Nginx能夠擁有更高的性能,根據業務特色來進行調整，當Nginx做爲靜態web內容服務器、反向代理或者提供壓縮服務器的服務器時，期內核參數的調整都是不一樣的，這裏針對最通用的、使Nginx支持更多併發請求的TCP網絡參數作簡單的配置,修改/etc/sysctl.conf來更改內核參數

fs.file-max = 999999

表示單個進程較大能夠打開的句柄數

net.ipv4.tcp_tw_reuse = 1

參數設置爲 1 ，表示容許將TIME_WAIT狀態的socket從新用於新的TCP連接，這對於服務器來講意義重大，由於總有大量TIME_WAIT狀態的連接存在

net.ipv4.tcp_keepalive_time = 600

當keepalive啓動時，TCP發送keepalive消息的頻度；默認是2小時，將其設置爲10分鐘，可更快的清理無效連接

net.ipv4.tcp_fin_timeout = 30

當服務器主動關閉連接時，socket保持在FIN_WAIT_2狀態的較大時間

net.ipv4.tcp_max_tw_buckets = 5000

這個參數表示操做系統容許TIME_WAIT套接字數量的較大值，若是超過這個數字，TIME_WAIT套接字將馬上被清除並打印警告信息,默認爲8000，過多的TIME_WAIT套接字會使Web服務器變慢

net.ipv4.ip_local_port_range = 1024 65000

定義UDP和TCP連接的本地端口的取值範圍