“

Nginx 是一個 輕量級 / 高性能的反向代理 Web 服務(wù)器，用于 HTTP、HTTPS、SMTP、POP3 和 IMAP 協(xié)議。他實現(xiàn)非常高效的反向代理、負載平衡，他可以處理 2-3 萬并發(fā)連接數(shù)，官方監(jiān)測能支持 5 萬并發(fā)，現(xiàn)在中國使用 nginx 網(wǎng)站用戶有很多，例如：新浪、網(wǎng)易、 騰訊等。

Nginx 有哪些優(yōu)點？

• 跨平臺、配置簡單。

• 非阻塞、高并發(fā)連接：處理 2-3 萬并發(fā)連接數(shù)，官方監(jiān)測能支持 5 萬并發(fā)。

• 內(nèi)存消耗

• ?。洪_啟 10 個 Nginx 才占 150M 內(nèi)存。

• 成本低廉，且開源。

• 穩(wěn)定性高，宕機的概率非常小。

• 內(nèi)置的健康檢查功能：如果有一個服務(wù)器宕機，會做一個健康檢查，再發(fā)送的請求就不會發(fā)送到宕機的服務(wù)器了。重新將請求提交到其他的節(jié)點上

Nginx 應(yīng)用場景？

• http 服務(wù)器。Nginx 是一個 http 服務(wù)可以獨立提供 http 服務(wù)。可以做網(wǎng)頁靜態(tài)服務(wù)器。

• 虛擬主機?？梢詫崿F(xiàn)在一臺服務(wù)器虛擬出多個網(wǎng)站，例如個人網(wǎng)站使用的虛擬機。

• 反向代理，負載均衡。當網(wǎng)站的訪問量達到一定程度后，單臺服務(wù)器不能滿足用戶的請求時，需要用多臺服務(wù)器集群可以使用 nginx 做反向代理。并且多臺服務(wù)器可以平均分擔負載，不會應(yīng)為某臺服務(wù)器負載高宕機而某臺服務(wù)器閑置的情況。

• nginz 中也可以配置安全管理、比如可以使用 Nginx 搭建 API 接口網(wǎng)關(guān), 對每個接口服務(wù)進行攔截。

Nginx 怎么處理請求的？

server { # 第一個Server區(qū)塊開始，表示一個獨立的虛擬主機站點 ?

listen ? ? ? 80；# 提供服務(wù)的端口，默認80 ??

server_name localhost; # 提供服務(wù)的域名主機名 ?

location / { # 第一個location區(qū)塊開始 ? ??

root ? html; # 站點的根目錄，相當于Nginx的安裝目錄 ? ??

index ?index.html index.html; # 默認的首頁文件，多個用空格分開}

# 第一個location區(qū)塊結(jié)果

• 首先，Nginx 在啟動時，會解析配置文件，得到需要監(jiān)聽的端口與 IP 地址，然后在 Nginx 的 Master 進程里面先初始化好這個監(jiān)控的 Socket(創(chuàng)建 S ocket，設(shè)置 addr、reuse 等選項，綁定到指定的 ip 地址端口，再 listen 監(jiān)聽)。

• 然后，再 fork(一個現(xiàn)有進程可以調(diào)用 fork 函數(shù)創(chuàng)建一個新進程。由 fork 創(chuàng)建的新進程被稱為子進程) 出多個子進程出來。

• 之后，子進程會競爭 accept 新的連接。此時，客戶端就可以向 nginx 發(fā)起連接了。當客戶端與 nginx 進行三次握手，與 nginx 建立好一個連接后。此時，某一個子進程會 accept 成功，得到這個建立好的連接的 Socket ，然后創(chuàng)建 nginx 對連接的封裝，即 ngx_connection_t 結(jié)構(gòu)體。

• 接著，設(shè)置讀寫事件處理函數(shù)，并添加讀寫事件來與客戶端進行數(shù)據(jù)的交換。

• 最后，Nginx 或客戶端來主動關(guān)掉連接，到此，一個連接就壽終正寢了。

Nginx 是如何實現(xiàn)高并發(fā)的？

“

如果一個 server 采用一個進程 (或者線程) 負責一個 request 的方式，那么進程數(shù)就是并發(fā)數(shù)。那么顯而易見的，就是會有很多進程在等待中。等什么？最多的應(yīng)該是等待網(wǎng)絡(luò)傳輸。

“

而 Nginx 的異步非阻塞工作方式正是利用了這點等待的時間。在需要等待的時候，這些進程就空閑出來待命了。因此表現(xiàn)為少數(shù)幾個進程就解決了大量的并發(fā)問題。

“

Nginx 是如何利用的呢，簡單來說：同樣的 4 個進程，如果采用一個進程負責一個 request 的方式，那么，同時進來 4 個 request 之后，每個進程就負責其中一個，直至會話關(guān)閉。期間，如果有第 5 個 request 進來了。就無法及時反應(yīng)了，因為 4 個進程都沒干完活呢，因此，一般有個調(diào)度進程，每當新進來了一個 request ，就新開個進程來處理。

回想下，BIO 是不是存在醬紫的問題？

“

Nginx 不這樣，每進來一個 request ，會有一個 worker 進程去處理。但不是全程的處理，處理到什么程度呢？處理到可能發(fā)生阻塞的地方，比如向上游（后端）服務(wù)器轉(zhuǎn)發(fā) request ，并等待請求返回。那么，這個處理的 worker 不會這么傻等著，他會在發(fā)送完請求后，注冊一個事件：“如果 upstream 返回了，告訴我一聲，我再接著干”。于是他就休息去了。此時，如果再有 request 進來，他就可以很快再按這種方式處理。而一旦上游服務(wù)器返回了，就會觸發(fā)這個事件，worker 才會來接手，這個 request 才會接著往下走。

這就是為什么說，Nginx 基于事件模型。

由于 web server 的工作性質(zhì)決定了每個 request 的大部份生命都是在網(wǎng)絡(luò)傳輸中，實際上花費在 server 機器上的時間片不多。這是幾個進程就解決高并發(fā)的秘密所在。即：

webserver 剛好屬于網(wǎng)絡(luò) IO 密集型應(yīng)用，不算是計算密集型。

異步，非阻塞，使用 epoll ，和大量細節(jié)處的優(yōu)化。也正是 Nginx 之所以然的技術(shù)基石。

什么是正向代理？

“

一個位于客戶端和原始服務(wù)器 (origin server) 之間的服務(wù)器，為了從原始服務(wù)器取得內(nèi)容，客戶端向代理發(fā)送一個請求并指定目標(原始服務(wù)器)，然后代理向原始服務(wù)器轉(zhuǎn)交請求并將獲得的內(nèi)容返回給客戶端。

客戶端才能使用正向代理。正向代理總結(jié)就一句話：代理端代理的是客戶端。例如說：我們使用的 OpenVPN 等等。

什么是反向代理？

反向代理（Reverse Proxy）方式，是指以代理服務(wù)器來接受 Internet 上的連接請求，然后將請求，發(fā)給內(nèi)部網(wǎng)絡(luò)上的服務(wù)器并將從服務(wù)器上得到的結(jié)果返回給 Internet 上請求連接的客戶端，此時代理服務(wù)器對外就表現(xiàn)為一個反向代理服務(wù)器。

“

反向代理總結(jié)就一句話：代理端代理的是服務(wù)端。

反向代理服務(wù)器的優(yōu)點是什么?

“

反向代理服務(wù)器可以隱藏源服務(wù)器的存在和特征。它充當互聯(lián)網(wǎng)云和 web 服務(wù)器之間的中間層。這對于安全方面來說是很好的，特別是當您使用 web 托管服務(wù)時。

Nginx 目錄結(jié)構(gòu)有哪些？

tree /usr/local/nginx

?/usr/local/nginx?

├── client_body_temp?

├── conf # Nginx所有配置文件的目錄

│ ├── fastcgi.conf # fastcgi相關(guān)參數(shù)的配置文件

│ ├── fastcgi.conf.default ? ? ? ? # fastcgi.conf的原始備份文件

│ ├── fastcgi_params # fastcgi的參數(shù)文件

│ ├── fastcgi_params.default ? ? ??

│ ├── koi-utf?

│ ├── koi-win?

│ ├── mime.types # 媒體類型

│ ├── mime.types.default

│ ├── nginx.conf # Nginx主配置文件

│ ├── nginx.conf.default

│ ├── scgi_params # scgi相關(guān)參數(shù)文件

│ ├── scgi_params.default ?

│ ├── uwsgi_params # uwsgi相關(guān)參數(shù)文件

│ ├── uwsgi_params.default

│ └── win-utf?

├── fastcgi_temp # fastcgi臨時數(shù)據(jù)目錄

├── html # Nginx默認站點目錄

│ ├── 50x.html # 錯誤頁面優(yōu)雅替代顯示文件，例如當出現(xiàn)502錯誤時會調(diào)用此頁面

│ └── index.html # 默認的首頁文件

├── logs # Nginx日志目錄

│ ├── access.log # 訪問日志文件

│ ├── error.log # 錯誤日志文件

│ └── nginx.pid # pid文件，Nginx進程啟動后，會把所有進程的ID號寫到此文件

├── proxy_temp # 臨時目錄

├── sbin # Nginx命令目錄

│ └── nginx # Nginx的啟動命令

├── scgi_temp # 臨時目錄

└── uwsgi_temp # 臨時目錄

Nginx 配置文件 nginx.conf 有哪些屬性模塊?

worker_processes ?1；# worker進程的數(shù)量

events { # 事件區(qū)塊開始?

? ?worker_connections ?1024；# 每個worker進程支持的最大連接數(shù)}?# 事件區(qū)塊結(jié)束

http { # HTTP區(qū)塊開始 ? ?

include ? ? ? mime.types；# Nginx支持的媒體類型庫文件 ? ?

default_type application/octet-stream；# 默認的媒體類型 ? ?

sendfile on；# 開啟高效傳輸模式 ??

?keepalive_timeout 65；# 連接超時 ??

?server { # 第一個Server區(qū)塊開始，表示一個獨立的虛擬主機站點 ??

? ? ?listen ? ? ? 80；# 提供服務(wù)的端口，默認80 ? ? ? ?

server_name localhost；# 提供服務(wù)的域名主機名 ? ? ??

?location / { # 第一個location區(qū)塊開始 ? ? ? ? ??

?root ? html；# 站點的根目錄，相當于Nginx的安裝目錄 ? ? ? ? ??

?index index.html index.htm；# 默認的首頁文件，多個用空格分開 ? ? ? ?} # 第一個location區(qū)塊結(jié)果 ? ? ??

?error_page 500502503504 ?/50x.html；# 出現(xiàn)對應(yīng)的http狀態(tài)碼時，使用50x.html回應(yīng)客戶 ? ? ? ?location = /50x.html { # location區(qū)塊開始，訪問50x.html ? ? ? ? ??

?root ? html；# 指定對應(yīng)的站點目錄為html ? ??

? ?} ??

?} ? ?......

cookie 和 session 區(qū)別？

共同：

存放用戶信息。存放的形式：key-value 格式 變量和變量內(nèi)容鍵值對。

區(qū)別：

cookie

• 存放在客戶端瀏覽器

• 每個域名對應(yīng)一個 cookie，不能跨躍域名訪問其他 cookie

• 用戶可以查看或修改 cookie

• http 響應(yīng)報文里面給你瀏覽器設(shè)置

• 鑰匙（用于打開瀏覽器上鎖頭）

session:

• 存放在服務(wù)器（文件，數(shù)據(jù)庫，redis）

• 存放敏感信息

• 鎖頭

為什么 Nginx 不使用多線程？

“

Apache: 創(chuàng)建多個進程或線程，而每個進程或線程都會為其分配 cpu 和內(nèi)存（線程要比進程小的多，所以 worker 支持比 perfork 高的并發(fā)），并發(fā)過大會榨干服務(wù)器資源。

Nginx: 采用單線程來異步非阻塞處理請求（管理員可以配置 Nginx 主進程的工作進程的數(shù)量）(epoll)，不會為每個請求分配 cpu 和內(nèi)存資源，節(jié)省了大量資源，同時也減少了大量的 CPU 的上下文切換。所以才使得 Nginx 支持更高的并發(fā)。

nginx 和 apache 的區(qū)別

輕量級，同樣起 web 服務(wù)，比 apache 占用更少的內(nèi)存和資源。

抗并發(fā)，nginx 處理請求是異步非阻塞的，而 apache 則是阻塞性的，在高并發(fā)下 nginx 能保持低資源，低消耗高性能。

高度模塊化的設(shè)計，編寫模塊相對簡單。

最核心的區(qū)別在于 apache 是同步多進程模型，一個連接對應(yīng)一個進程，nginx 是異步的，多個連接可以對應(yīng)一個進程。

什么是動態(tài)資源、靜態(tài)資源分離？

“

動態(tài)資源、靜態(tài)資源分離，是讓動態(tài)網(wǎng)站里的動態(tài)網(wǎng)頁根據(jù)一定規(guī)則把不變的資源和經(jīng)常變的資源區(qū)分開來，動靜資源做好了拆分以后我們就可以根據(jù)靜態(tài)資源的特點將其做緩存操作，這就是網(wǎng)站靜態(tài)化處理的核心思路。

動態(tài)資源、靜態(tài)資源分離簡單的概括是：動態(tài)文件與靜態(tài)文件的分離。

為什么要做動、靜分離？

在我們的軟件開發(fā)中，有些請求是需要后臺處理的（如：.jsp,.do 等等），有些請求是不需要經(jīng)過后臺處理的（如：css、html、jpg、js 等等文件），這些不需要經(jīng)過后臺處理的文件稱為靜態(tài)文件，否則動態(tài)文件。

“

因此我們后臺處理忽略靜態(tài)文件。這會有人又說那我后臺忽略靜態(tài)文件不就完了嗎？當然這是可以的，但是這樣后臺的請求次數(shù)就明顯增多了。在我們對資源的響應(yīng)速度有要求的時候，我們應(yīng)該使用這種動靜分離的策略去解決動、靜分離將網(wǎng)站靜態(tài)資源（HTML，JavaScript，CSS，img 等文件）與后臺應(yīng)用分開部署，提高用戶訪問靜態(tài)代碼的速度，降低對后臺應(yīng)用訪問

這里我們將靜態(tài)資源放到 Nginx 中，動態(tài)資源轉(zhuǎn)發(fā)到 Tomcat 服務(wù)器中去。

當然，因為現(xiàn)在七牛、阿里云等 CDN 服務(wù)已經(jīng)很成熟，主流的做法，是把靜態(tài)資源緩存到 CDN 服務(wù)中，從而提升訪問速度。

“

相比本地的 Nginx 來說，CDN 服務(wù)器由于在國內(nèi)有更多的節(jié)點，可以實現(xiàn)用戶的就近訪問。并且，CDN 服務(wù)可以提供更大的帶寬，不像我們自己的應(yīng)用服務(wù)，提供的帶寬是有限的。

什么叫 CDN 服務(wù)？

CDN ，即內(nèi)容分發(fā)網(wǎng)絡(luò)。

其目的是，通過在現(xiàn)有的 Internet 中 增加一層新的網(wǎng)絡(luò)架構(gòu)，將網(wǎng)站的內(nèi)容發(fā)布到最接近用戶的網(wǎng)絡(luò)邊緣，使用戶可就近取得所需的內(nèi)容，提高用戶訪問網(wǎng)站的速度。

一般來說，因為現(xiàn)在 CDN 服務(wù)比較大眾，所以基本所有公司都會使用 CDN 服務(wù)。

Nginx 怎么做的動靜分離？

“

只需要指定路徑對應(yīng)的目錄。location / 可以使用正則表達式匹配。并指定對應(yīng)的硬盤中的目錄。如下：（操作都是在 Linux 上）

location /image/ { ??

?root /usr/local/static/; ? ?

autoindex on;}

步驟：

# 創(chuàng)建目錄mkdir /usr/local/static/image?

# 進入目錄

cd ?/usr/local/static/image

# 上傳照片photo.jpg

# 重啟

nginxsudo nginx -s reload

打開瀏覽器 輸入 server_name/image/1.jpg 就可以訪問該靜態(tài)圖片了

Nginx 負載均衡的算法怎么實現(xiàn)的? 策略有哪些?

“

為了避免服務(wù)器崩潰，大家會通過負載均衡的方式來分擔服務(wù)器壓力。將對臺服務(wù)器組成一個集群，當用戶訪問時，先訪問到一個轉(zhuǎn)發(fā)服務(wù)器，再由轉(zhuǎn)發(fā)服務(wù)器將訪問分發(fā)到壓力更小的服務(wù)器。

Nginx 負載均衡實現(xiàn)的策略有以下五種：

1 . 輪詢 (默認)

每個請求按時間順序逐一分配到不同的后端服務(wù)器，如果后端某個服務(wù)器宕機，能自動剔除故障系統(tǒng)。

upstream backserver { server 192.168.0.12; server 192.168.0.13;}

2. 權(quán)重 weight

weight 的值越大，分配到的訪問概率越高，主要用于后端每臺服務(wù)器性能不均衡的情況下。其次是為在主從的情況下設(shè)置不同的權(quán)值，達到合理有效的地利用主機資源。

# 權(quán)重越高，在被訪問的概率越大，如上例，分別是20%，80%。upstream backserver {

server 192.168.0.12 weight=2; server 192.168.0.13 weight=8;

}

3. ip_hash(IP 綁定)

每個請求按訪問 IP 的哈希結(jié)果分配，使來自同一個 IP 的訪客固定訪問一臺后端服務(wù)器，并且可以有效解決動態(tài)網(wǎng)頁存在的 session 共享問題

upstream backserver { ip_hash; server 192.168.0.12:88;

server 192.168.0.13:80;

}

4. fair(第三方插件)

必須安裝 upstream_fair 模塊。

對比 weight、ip_hash 更加智能的負載均衡算法，fair 算法可以根據(jù)頁面大小和加載時間長短智能地進行負載均衡，響應(yīng)時間短的優(yōu)先分配。

# 哪個服務(wù)器的響應(yīng)速度快，就將請求分配到那個服務(wù)器上。upstream backserver {?




server server1; server server2; fair;

}

5.url_hash(第三方插件)

必須安裝 Nginx 的 hash 軟件包

按訪問 url 的 hash 結(jié)果來分配請求，使每個 url 定向到同一個后端服務(wù)器，可以進一步提高后端緩存服務(wù)器的效率。

upstream backserver {?

server squid1:3128; server squid2:3128; hash $request_uri; hash_method crc32;?

}

如何用 Nginx 解決前端跨域問題？

使用 Nginx 轉(zhuǎn)發(fā)請求。把跨域的接口寫成調(diào)本域的接口，然后將這些接口轉(zhuǎn)發(fā)到真正的請求地址。

Nginx 虛擬主機怎么配置?

1、基于域名的虛擬主機，通過域名來區(qū)分虛擬主機——應(yīng)用：外部網(wǎng)站

2、基于端口的虛擬主機，通過端口來區(qū)分虛擬主機——應(yīng)用：公司內(nèi)部網(wǎng)站，外部網(wǎng)站的管理后臺

3、基于 ip 的虛擬主機。

基于虛擬主機配置域名

需要建立 / data/www /data/bbs 目錄，windows 本地 hosts 添加虛擬機 ip 地址對應(yīng)的域名解析；對應(yīng)域名網(wǎng)站目錄下新增 index.html 文件；

# 當客戶端訪問www.lijie.com,監(jiān)聽端口號為80,直接跳轉(zhuǎn)到data/www目錄下文件

server { ? ?

listen ? ? ? 80; ? ?

server_name ?www.lijie.com;?

? ?location / { ? ? ??

?root ? data/www; ? ? ??

?index ?index.html index.htm; ? ?}

}

# 當客戶端訪問www.lijie.com,監(jiān)聽端口號為80,直接跳轉(zhuǎn)到data/bbs目錄下文件?

server { ??

?listen ? ? ? 80; ? ?

server_name ?bbs.lijie.com; ? ?

location / { ? ? ? ?root ? data/bbs; ?

?? ? ?index ?index.html index.htm; ?

??}

?}

基于端口的虛擬主機

使用端口來區(qū)分，瀏覽器使用域名或 ip 地址: 端口號 訪問

# 當客戶端訪問www.lijie.com,監(jiān)聽端口號為8080,直接跳轉(zhuǎn)到data/www目錄下文件

server { ? ?listen ? ? ? 8080; ?

??server_name ?8080.lijie.com; ??

?location / { ? ? ? ?

root ? data/www; ? ? ? ?

index ?index.html index.htm; ? ?}

?}

# 當客戶端訪問www.lijie.com,監(jiān)聽端口號為80直接跳轉(zhuǎn)到真實ip服務(wù)器地址 127.0.0.1:8080

server { ? ?listen ? ? ? 80;

?? ?server_name ?www.lijie.com;?

? ?location / { ? ??

? ? proxy_pass http://127.0.0.1:8080; ? ? ?

??index ?index.html index.htm; ? ?

} }

location 的作用是什么？

location 指令的作用是根據(jù)用戶請求的 URI 來執(zhí)行不同的應(yīng)用，也就是根據(jù)用戶請求的網(wǎng)站 URL 進行匹配，匹配成功即進行相關(guān)的操作。

location 的語法能說出來嗎？

“

注意：~ 代表自己輸入的英文字母

Location 正則案例

# 優(yōu)先級1,精確匹配，根路徑

location =/ {?

? ?return 400; }

# 優(yōu)先級2,以某個字符串開頭,以av開頭的，優(yōu)先匹配這里，區(qū)分大小寫

location ^~ /av { ?

root /data/av/; }

# 優(yōu)先級3，區(qū)分大小寫的正則匹配，匹配/media*****路徑

location ~ /media { ? ? ?alias /data/static/; }

# 優(yōu)先級4 ，不區(qū)分大小寫的正則匹配，所有的****.jpg|gif|png 都走這里

location ~* .*\.(jpg|gif|png|js|css)$ { ? root ?/data/av/; }

# 優(yōu)先7，通用匹配

location / { ? ?return 403; }

限流怎么做的？

Nginx 限流就是限制用戶請求速度，防止服務(wù)器受不了

限流有 3 種

• 正常限制訪問頻率（正常流量）

• 突發(fā)限制訪問頻率（突發(fā)流量）

• 限制并發(fā)連接數(shù)

Nginx 的限流都是基于漏桶流算法

“

實現(xiàn)三種限流算法

1、正常限制訪問頻率（正常流量）：

限制一個用戶發(fā)送的請求，我 Nginx 多久接收一個請求。

Nginx 中使用 ngx_http_limit_req_module 模塊來限制的訪問頻率，限制的原理實質(zhì)是基于漏桶算法原理來實現(xiàn)的。在 nginx.conf 配置文件中可以使用 limit_req_zone 命令及 limit_req 命令限制單個 IP 的請求處理頻率。

# 定義限流維度，一個用戶一分鐘一個請求進來，多余的全部漏掉

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/m;

# 綁定限流維度

server{ ? ? ? ?

location/seckill.html{ ? ? ? ?

limit_req zone=zone; ? ? ? ?

proxy_pass http://lj_seckill; ? ?}

}

1r/s 代表 1 秒一個請求，1r/m 一分鐘接收一個請求， 如果 Nginx 這時還有別人的請求沒有處理完，Nginx 就會拒絕處理該用戶請求。

2、突發(fā)限制訪問頻率（突發(fā)流量）：

限制一個用戶發(fā)送的請求，我 Nginx 多久接收一個。

上面的配置一定程度可以限制訪問頻率，但是也存在著一個問題：如果突發(fā)流量超出請求被拒絕處理，無法處理活動時候的突發(fā)流量，這時候應(yīng)該如何進一步處理呢？

Nginx 提供 burst 參數(shù)結(jié)合 nodelay 參數(shù)可以解決流量突發(fā)的問題，可以設(shè)置能處理的超過設(shè)置的請求數(shù)外能額外處理的請求數(shù)。我們可以將之前的例子添加 burst 參數(shù)以及 nodelay 參數(shù)：

# 定義限流維度，一個用戶一分鐘一個請求進來，多余的全部漏掉

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/m;

# 綁定限流維度server{ ? ? ? ?

location/seckill.html{ ? ? ??

?limit_req zone=zone burst=5 nodelay; ? ? ?

??proxy_pass http://lj_seckill; ? ?}

}

“

為什么就多了一個 burst=5 nodelay; 呢，多了這個可以代表 Nginx 對于一個用戶的請求會立即處理前五個，多余的就慢慢來落，沒有其他用戶的請求我就處理你的，有其他的請求的話我 Nginx 就漏掉不接受你的請求

3、 限制并發(fā)連接數(shù)

Nginx 中的
ngx_http_limit_conn_module 模塊提供了限制并發(fā)連接數(shù)的功能，可以使用 limit_conn_zone 指令以及 limit_conn 執(zhí)行進行配置。接下來我們可以通過一個簡單的例子來看下：

http { ? ?

limit_conn_zone $binary_remote_addr zone=myip:10m; ?

??limit_conn_zone $server_name zone=myServerName:10m; }

server { ? ?

location / { ? ? ??

?limit_conn myip 10; ? ? ??

?limit_conn myServerName 100; ? ? ??

?rewrite / http://www.lijie.net permanent; ? ?}

?}

上面配置了單個 IP 同時并發(fā)連接數(shù)最多只能 10 個連接，并且設(shè)置了整個虛擬服務(wù)器同時最大并發(fā)數(shù)最多只能 100 個鏈接。當然，只有當請求的 header 被服務(wù)器處理后，虛擬服務(wù)器的連接數(shù)才會計數(shù)。剛才有提到過 Nginx 是基于漏桶算法原理實現(xiàn)的，實際上限流一般都是基于漏桶算法和令牌桶算法實現(xiàn)的。

漏桶流算法和令牌桶算法知道？

漏桶算法

漏桶算法思路很簡單，我們把水比作是請求，漏桶比作是系統(tǒng)處理能力極限，水先進入到漏桶里，漏桶里的水按一定速率流出，當流出的速率小于流入的速率時，由于漏桶容量有限，后續(xù)進入的水直接溢出（拒絕請求），以此實現(xiàn)限流。

令牌桶算法

令牌桶算法的原理也比較簡單，我們可以理解成醫(yī)院的掛號看病，只有拿到號以后才可以進行診病。

“

系統(tǒng)會維護一個令牌（token）桶，以一個恒定的速度往桶里放入令牌（token），這時如果有請求進來想要被處理，則需要先從桶里獲取一個令牌（token），當桶里沒有令牌（token）可取時，則該請求將被拒絕服務(wù)。令牌桶算法通過控制桶的容量、發(fā)放令牌的速率，來達到對請求的限制。

Nginx 配置高可用性怎么配置？

“

當上游服務(wù)器 (真實訪問服務(wù)器)，一旦出現(xiàn)故障或者是沒有及時相應(yīng)的話，應(yīng)該直接輪訓到下一臺服務(wù)器，保證服務(wù)器的高可用

Nginx 配置代碼：

server { ? ? ??

?listen ? ? ? 80; ? ? ? ?

server_name ?www.lijie.com; ? ? ? ?

location / { ? ? ? ? ? ?### 指定上游服務(wù)器負載均衡服務(wù)器?

? ? ? ? ? ?proxy_pass http://backServer; ? ? ? ? ? ?###nginx與上游服務(wù)器(真實訪問的服務(wù)器)超時時間 后端服務(wù)器連接的超時時間_發(fā)起握手等候響應(yīng)超時時間 ? ? ? ? ??

?proxy_connect_timeout 1s; ? ? ? ? ? ?###nginx發(fā)送給上游服務(wù)器(真實訪問的服務(wù)器)超時時間 ? ? ? ? ??

?proxy_send_timeout 1s; ? ? ? ? ? ?### nginx接受上游服務(wù)器(真實訪問的服務(wù)器)超時時間 ? ? ? ? ? ?

proxy_read_timeout 1s; ? ? ? ? ??

?index ?index.html index.htm; ? ? ? ?} ?

??}

Nginx 怎么判斷別 IP 不可訪問？

# 如果訪問的ip地址為192.168.9.115,則返回403 if ?($remote_addr = 192.168.9.115) { ? ? return 403; }

在 nginx 中，如何使用未定義的服務(wù)器名稱來阻止處理請求？

只需將請求刪除的服務(wù)器就可以定義為：

服務(wù)器名被保留一個空字符串，他在沒有主機頭字段的情況下匹配請求，而一個特殊的 nginx 的非標準代碼被返回，從而終止連接。

怎么限制瀏覽器訪問？

## 不允許谷歌瀏覽器訪問 如果是谷歌瀏覽器返回500

if ($http_user_agent ~ Chrome) { ?return 500; }?

Rewrite全局變量是什么？?

$remote_addr //獲取客戶端ip

$binary_remote_addr //客戶端ip（二進制)

$remote_port //客戶端port，如：50472

$remote_user //已經(jīng)經(jīng)過Auth Basic Module驗證的用戶名

$host //請求主機頭字段，否則為服務(wù)器名稱，如:blog.sakmon.com

$request //用戶請求信息，如：GET ?a=1&b=2 HTTP/1.1

$request_filename //當前請求的文件的路徑名，由root或alias和URI request組合而成，如：/2013/81.html

$status //請求的響應(yīng)狀態(tài)碼,如:200

$body_bytes_sent // 響應(yīng)時送出的body字節(jié)數(shù)數(shù)量。即使連接中斷，這個數(shù)據(jù)也是精確的,如：40

$content_length // 等于請求行的“Content_Length”的值

$content_type // 等于請求行的“Content_Type”的值

$http_referer // 引用地址

$http_user_agent // 客戶端agent信息,如：Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36

$args //與

$query_string相同 等于當中URL的參數(shù)(GET)，如a=1&b=2

$document_uri //與

$uri相同 這個變量指當前的請求URI，不包括任何參數(shù)(見$args) 如:/2013/81.html$document_root //針對當前請求的根路徑設(shè)置值

$hostname //如：centos53.localdomain

$http_cookie //客戶端cookie信息

$cookie_COOKIE //cookie COOKIE變量的值

$is_args //如果有

$args參數(shù)，這個變量等于”?”，否則等于”"，空值，如?

$limit_rate //這個變量可以限制連接速率，0表示不限速

$query_string // 與

$args相同 等于當中URL的參數(shù)(GET)，如a=1&b=2

$request_body // 記錄POST過來的數(shù)據(jù)信息

$request_body_file //客戶端請求主體信息的臨時文件名

$request_method //客戶端請求的動作，通常為GET或POST,如：GET

$request_uri //包含請求參數(shù)的原始URI，不包含主機名，如：/2013/81.html?a=1&b=2$scheme //HTTP方法（如http，https）,如：http

$uri //這個變量指當前的請求URI，不包括任何參數(shù)(見$args) 如:/2013/81.html

$request_completion //如果請求結(jié)束，設(shè)置為OK. 當請求未結(jié)束或如果該請求不是請求鏈串的最后一個時，為空(Empty)，如：OK$server_protocol //請求使用的協(xié)議，通常是HTTP/1.0或HTTP/1.1，如：HTTP/1.1$server_addr //服務(wù)器IP地址，在完成一次系統(tǒng)調(diào)用后可以確定這個值

$server_name //服務(wù)器名稱，如：blog.sakmon.com

$server_port //請求到達服務(wù)器的端口號,如：80

Nginx 如何實現(xiàn)后端服務(wù)的健康檢查?

方式一，利用 nginx 自帶模塊 ngx_http_proxy_module 和 ngx_http_upstream_module 對后端節(jié)點做健康檢查。

方式二 (推薦)，利用
nginx_upstream_check_module 模塊對后端節(jié)點做健康檢查。

Nginx 如何開啟壓縮？

開啟 nginx gzip 壓縮后，網(wǎng)頁、css、js 等靜態(tài)資源的大小會大大的減少，從而可以節(jié)約大量的帶寬，提高傳輸效率，給用戶快的體驗。雖然會消耗 cpu 資源，但是為了給用戶更好的體驗是值得的。

開啟的配置如下：

將以上配置放到 nginx.conf 的 http{…} 節(jié)點中。

http { ?# 開啟gzip?

??gzip on; ?

# 啟用gzip壓縮的最小文件；小于設(shè)置值的文件將不會被壓縮 ?

gzip_min_length 1k;?

??# gzip 壓縮級別 1-10?

??gzip_comp_level 2;?

??# 進行壓縮的文件類型。?

?gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png;?

??# 是否在http header中添加Vary: Accept-Encoding，建議開啟?

??gzip_vary on; }

保存并重啟 nginx，刷新頁面（為了避免緩存，請強制刷新）就能看到效果了。以谷歌瀏覽器為例，通過 F12 看請求的響應(yīng)頭部：

我們可以先來對比下，如果我們沒有開啟 zip 壓縮之前，我們的對應(yīng)的文件大小，如下所示：

現(xiàn)在我們開啟了 gzip 進行壓縮后的文件的大小，可以看到如下所示：

并且我們查看響應(yīng)頭會看到 gzip 這樣的壓縮，如下所示

gzip 壓縮前后效果對比：jquery 原大小 90kb，壓縮后只有 30kb。

gzip 雖然好用，但是以下類型的資源不建議啟用。

1、圖片類型

“

原因：圖片如 jpg、png 本身就會有壓縮，所以就算開啟 gzip 后，壓縮前和壓縮后大小沒有多大區(qū)別，所以開啟了反而會白白的浪費資源。（Tips：可以試試將一張 jpg 圖片壓縮為 zip，觀察大小并沒有多大的變化。雖然 zip 和 gzip 算法不一樣，但是可以看出壓縮圖片的價值并不大）

2、大文件

原因：會消耗大量的 cpu 資源，且不一定有明顯的效果。

ngx_http_upstream_module 的作用是什么?

“

ngx_http_upstream_module 用于定義可通過 fastcgi 傳遞、proxy 傳遞、uwsgi 傳遞、memcached 傳遞和 scgi 傳遞指令來引用的服務(wù)器組。

什么是 C10K 問題?

C10K 問題是指無法同時處理大量客戶端 (10,000) 的網(wǎng)絡(luò)套接字。

Nginx 是否支持將請求壓縮到上游?

“

您可以使用 Nginx 模塊 gunzip 將請求壓縮到上游。gunzip 模塊是一個過濾器，它可以對不支持 “gzip” 編碼方法的客戶機或服務(wù)器使用 “內(nèi)容編碼: gzip” 來解壓縮響應(yīng)。

如何在 Nginx 中獲得當前的時間?

要獲得 Nginx 的當前時間，必須使用 SSI 模塊、和 date_local 的變量。

Proxy_set_header THE-TIME $date_gmt;

用 Nginx 服務(wù)器解釋 - s 的目的是什么?

用于運行 Nginx -s 參數(shù)的可執(zhí)行文件。

如何在 Nginx 服務(wù)器上添加模塊?

在編譯過程中，必須選擇 Nginx 模塊，因為 Nginx 不支持模塊的運行時間選擇。

生產(chǎn)中如何設(shè)置 worker 進程的數(shù)量呢？

“

在有多個 cpu 的情況下，可以設(shè)置多個 worker，worker 進程的數(shù)量可以設(shè)置到和 cpu 的核心數(shù)一樣多，如果在單個 cpu 上起多個 worker 進程，那么操作系統(tǒng)會在多個 worker 之間進行調(diào)度，這種情況會降低系統(tǒng)性能，如果只有一個 cpu，那么只啟動一個 worker 進程就可以了。

nginx 狀態(tài)碼

499：

“

服務(wù)端處理時間過長，客戶端主動關(guān)閉了連接。

502：

(1).FastCGI 進程是否已經(jīng)啟動

(2).FastCGI worker 進程數(shù)是否不夠

(3).FastCGI 執(zhí)行時間過長

• fastcgi_connect_timeout 300;

• fastcgi_send_timeout 300;

• fastcgi_read_timeout 300;

(4).FastCGI Buffer 不夠，nginx 和 apache 一樣，有前端緩沖限制，可以調(diào)整緩沖參數(shù)

• fastcgi_buffer_size 32k;

• fastcgi_buffers 8 32k;

(5). Proxy Buffer 不夠，如果你用了 Proxying，調(diào)整

• proxy_buffer_size 16k;

• proxy_buffers 4 16k;

(6).php 腳本執(zhí)行時間過長

• 將 php-fpm.conf 的 0s 的 0s 改成一個時間