“

Nginx 是一款輕量級的 Web 服務(wù)器、反向代理服務(wù)器，由于它的內(nèi)存占用少，啟動極快，高并發(fā)能力強，在互聯(lián)網(wǎng)項目中廣泛應(yīng)用。

什么是 Nginx？

“

Nginx 是一個 輕量級 / 高性能的反向代理 Web 服務(wù)器，用于 HTTP、HTTPS、SMTP、POP3 和 IMAP 協(xié)議。他實現(xiàn)非常高效的反向代理、負(fù)載平衡，他可以處理 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(wǎng)頁靜態(tài)服務(wù)器。

• 虛擬主機。可以實現(xiàn)在一臺服務(wù)器虛擬出多個網(wǎng)站，例如個人網(wǎng)站使用的虛擬機。

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

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

Nginx 怎么處理請求的？

server{#第一個Server區(qū)塊開始，表示一個獨立的虛擬主機站點
 listen  80；#提供服務(wù)的端口，默認(rèn)80
server_namelocalhost;#提供服務(wù)的域名主機名
location/{#第一個location區(qū)塊開始
roothtml;#站點的根目錄，相當(dāng)于Nginx的安裝目錄
indexindex.htmlindex.html;#默認(rèn)的首頁文件，多個用空格分開
}#第一個location區(qū)塊結(jié)果

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

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

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

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

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

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

“

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

“

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

“

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

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

“

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

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

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

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

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

什么是正向代理？

“

一個位于客戶端和原始服務(wù)器 (origin server) 之間的服務(wù)器，為了從原始服務(wù)器取得內(nèi)容，客戶端向代理發(fā)送一個請求并指定目標(biāo)(原始服務(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ù)器的存在和特征。它充當(dāng)互聯(lián)網(wǎng)云和 web 服務(wù)器之間的中間層。這對于安全方面來說是很好的，特別是當(dāng)您使用 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默認(rèn)站點目錄
│├──50x.html#錯誤頁面優(yōu)雅替代顯示文件，例如當(dāng)出現(xiàn)502錯誤時會調(diào)用此頁面
│└──index.html#默認(rèn)的首頁文件
├──logs#Nginx日志目錄
│├──access.log#訪問日志文件
│├──error.log#錯誤日志文件
│└──nginx.pid#pid文件，Nginx進(jìn)程啟動后，會把所有進(jìn)程的ID號寫到此文件
├──proxy_temp#臨時目錄
├──sbin#Nginx命令目錄
│└──nginx#Nginx的啟動命令
├──scgi_temp#臨時目錄
└──uwsgi_temp#臨時目錄

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

worker_processes  1；#worker進(jìn)程的數(shù)量
events{#事件區(qū)塊開始
 worker_connections  1024；#每個worker進(jìn)程支持的最大連接數(shù)
}#事件區(qū)塊結(jié)束
http{#HTTP區(qū)塊開始
 include  mime.types；#Nginx支持的媒體類型庫文件
 default_type application/octet-stream；#默認(rèn)的媒體類型
 sendfile on；#開啟高效傳輸模式
 keepalive_timeout 65；#連接超時
server{#第一個Server區(qū)塊開始，表示一個獨立的虛擬主機站點
 listen  80；#提供服務(wù)的端口，默認(rèn)80
 server_name localhost；#提供服務(wù)的域名主機名
location/{#第一個location區(qū)塊開始
 root  html；#站點的根目錄，相當(dāng)于Nginx的安裝目錄
 index index.html index.htm；#默認(rèn)的首頁文件，多個用空格分開
}#第一個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)建多個進(jìn)程或線程，而每個進(jìn)程或線程都會為其分配 cpu 和內(nèi)存（線程要比進(jìn)程小的多，所以 worker 支持比 perfork 高的并發(fā)），并發(fā)過大會榨干服務(wù)器資源。

Nginx:采用單線程來異步非阻塞處理請求（管理員可以配置 Nginx 主進(jìn)程的工作進(jìn)程的數(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 是同步多進(jìn)程模型，一個連接對應(yīng)一個進(jìn)程，nginx 是異步的，多個連接可以對應(yīng)一個進(jìn)程。

什么是動態(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)文件不就完了嗎？當(dāng)然這是可以的，但是這樣后臺的請求次數(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ù)器中去。

當(dāng)然，因為現(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 / 可以使用正則表達(dá)式匹配。并指定對應(yīng)的硬盤中的目錄。如下：（操作都是在 Linux 上）

location/image/{
root/usr/local/static/;
autoindexon;
}
步驟：
#創(chuàng)建目錄
mkdir/usr/local/static/image

#進(jìn)入目錄
cd/usr/local/static/image

#上傳照片
photo.jpg

#重啟nginx
sudonginx-sreload

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

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

“

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

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

1 . 輪詢 (默認(rèn))

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

upstreambackserver{
server192.168.0.12;
server192.168.0.13;
}

2. 權(quán)重 weight

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

#權(quán)重越高，在被訪問的概率越大，如上例，分別是20%，80%。
upstreambackserver{
server192.168.0.12weight=2;
server192.168.0.13weight=8;
}

3. ip_hash(IP 綁定)

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

upstreambackserver{
ip_hash;
server192.168.0.12:88;
server192.168.0.13:80;
}

4. fair(第三方插件)

必須安裝 upstream_fair 模塊。

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

#哪個服務(wù)器的響應(yīng)速度快，就將請求分配到那個服務(wù)器上。
upstreambackserver{
serverserver1;
serverserver2;
fair;
}

5.url_hash(第三方插件)

必須安裝 Nginx 的 hash 軟件包

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

upstreambackserver{
serversquid1:3128;
serversquid2:3128;
hash$request_uri;
hash_methodcrc32;
}

如何用 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 文件；

#當(dāng)客戶端訪問www.lijie.com,監(jiān)聽端口號為80,直接跳轉(zhuǎn)到data/www目錄下文件
server{
listen80;
server_namewww.lijie.com;
location/{
rootdata/www;
indexindex.htmlindex.htm;
}
}

#當(dāng)客戶端訪問www.lijie.com,監(jiān)聽端口號為80,直接跳轉(zhuǎn)到data/bbs目錄下文件
server{
listen80;
server_namebbs.lijie.com;
location/{
rootdata/bbs;
indexindex.htmlindex.htm;
}
}

基于端口的虛擬主機

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

#當(dāng)客戶端訪問www.lijie.com,監(jiān)聽端口號為8080,直接跳轉(zhuǎn)到data/www目錄下文件
server{
listen8080;
server_name8080.lijie.com;
location/{
rootdata/www;
indexindex.htmlindex.htm;
}
}

#當(dāng)客戶端訪問www.lijie.com,監(jiān)聽端口號為80直接跳轉(zhuǎn)到真實ip服務(wù)器地址127.0.0.1:8080
server{
listen80;
server_namewww.lijie.com;
location/{
proxy_passhttp://127.0.0.1:8080;
indexindex.htmlindex.htm;
}
}

location 的作用是什么？

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

location 的語法能說出來嗎？

“

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

Location 正則案例

#優(yōu)先級1,精確匹配，根路徑
location=/{
return400;
}

#優(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/{
return403;
}

限流怎么做的？

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 的請求處理頻率。

#定義限流維度，一個用戶一分鐘一個請求進(jìn)來，多余的全部漏掉
limit_req_zone$binary_remote_addrzone=one:10mrate=1r/m;

#綁定限流維度
server{

location/seckill.html{
limit_reqzone=zone;
proxy_passhttp://lj_seckill;
}

}

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

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

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

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

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

#定義限流維度，一個用戶一分鐘一個請求進(jìn)來，多余的全部漏掉
limit_req_zone$binary_remote_addrzone=one:10mrate=1r/m;

#綁定限流維度
server{

location/seckill.html{
limit_reqzone=zoneburst=5nodelay;
proxy_passhttp://lj_seckill;
}

}

“

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

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

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

http{
limit_conn_zone$binary_remote_addrzone=myip:10m;
limit_conn_zone$server_namezone=myServerName:10m;
}

server{
location/{
limit_connmyip10;
limit_connmyServerName100;
rewrite/http://www.lijie.netpermanent;
}
}

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

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

漏桶算法

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

令牌桶算法

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

“

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

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

“

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

Nginx 配置代碼：

server{
listen80;
server_namewww.lijie.com;
location/{
###指定上游服務(wù)器負(fù)載均衡服務(wù)器
proxy_passhttp://backServer;
###nginx與上游服務(wù)器(真實訪問的服務(wù)器)超時時間后端服務(wù)器連接的超時時間_發(fā)起握手等候響應(yīng)超時時間
proxy_connect_timeout1s;
###nginx發(fā)送給上游服務(wù)器(真實訪問的服務(wù)器)超時時間
proxy_send_timeout1s;
###nginx接受上游服務(wù)器(真實訪問的服務(wù)器)超時時間
proxy_read_timeout1s;
indexindex.htmlindex.htm;
}
}

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

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

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

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

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

怎么限制瀏覽器訪問？

##不允許谷歌瀏覽器訪問如果是谷歌瀏覽器返回500
if($http_user_agent~Chrome){
return500;
}
Rewrite全局變量是什么？
$remote_addr//獲取客戶端ip
$binary_remote_addr//客戶端ip（二進(jìn)制)
$remote_port//客戶端port，如：50472
$remote_user//已經(jīng)經(jīng)過AuthBasicModule驗證的用戶名
$host//請求主機頭字段，否則為服務(wù)器名稱，如:blog.sakmon.com
$request//用戶請求信息，如：GET ?a=1&b=2 HTTP/1.1
$request_filename//當(dāng)前請求的文件的路徑名，由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相同等于當(dāng)中URL的參數(shù)(GET)，如a=1&b=2
$document_uri//與$uri相同這個變量指當(dāng)前的請求URI，不包括任何參數(shù)(見$args)如:/2013/81.html
$document_root//針對當(dāng)前請求的根路徑設(shè)置值
$hostname//如：centos53.localdomain
$http_cookie//客戶端cookie信息
$cookie_COOKIE//cookieCOOKIE變量的值
$is_args//如果有$args參數(shù)，這個變量等于”?”，否則等于”"，空值，如?
$limit_rate//這個變量可以限制連接速率，0表示不限速
$query_string//與$args相同等于當(dāng)中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//這個變量指當(dāng)前的請求URI，不包括任何參數(shù)(見$args)如:/2013/81.html
$request_completion//如果請求結(jié)束，設(shè)置為OK. 當(dāng)請求未結(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//請求到達(dá)服務(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
gzipon;

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

#gzip壓縮級別1-10
gzip_comp_level2;

#進(jìn)行壓縮的文件類型。

gzip_typestext/plainapplication/javascriptapplication/x-javascripttext/cssapplication/xmltext/javascriptapplication/x-httpd-phpimage/jpegimage/gifimage/png;

#是否在httpheader中添加Vary:Accept-Encoding，建議開啟
gzip_varyon;
}

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

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

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

并且我們查看響應(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 中獲得當(dāng)前的時間?

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

Proxy_set_headerTHE-TIME$date_gmt;

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

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

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

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

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

“

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

nginx 狀態(tài)碼

499：

“

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

502：

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

(2).FastCGI worker 進(jìn)程數(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 改成一個時間