40個(gè) Nginx 常問(wèn)面試題
“Nginx 是一款輕量級(jí)的 Web 服務(wù)器、反向代理服務(wù)器，由于它的內(nèi)存占用少，啟動(dòng)極快，高并發(fā)能力強(qiáng)，在互聯(lián)網(wǎng)項(xiàng)目中廣泛應(yīng)用。
那么關(guān)于 Nginx 的核心技術(shù)點(diǎn)有哪些呢？
什么是 Nginx？
“Nginx 是一個(gè) 輕量級(jí) / 高性能的反向代理 Web 服務(wù)器，用于 HTTP、HTTPS、SMTP、POP3 和 IMAP 協(xié)議。他實(shí)現(xiàn)非常高效的反向代理、負(fù)載平衡，他可以處理 2-3 萬(wàn)并發(fā)連接數(shù)，官方監(jiān)測(cè)能支持 5 萬(wàn)并發(fā)，現(xiàn)在中國(guó)使用 nginx 網(wǎng)站用戶(hù)有很多，例如：新浪、網(wǎng)易、 騰訊等。
Nginx 有哪些優(yōu)點(diǎn)？
-
跨平臺(tái)、配置簡(jiǎn)單。
-
非阻塞、高并發(fā)連接：處理 2-3 萬(wàn)并發(fā)連接數(shù)，官方監(jiān)測(cè)能支持 5 萬(wàn)并發(fā)。
-
內(nèi)存消耗
-
小：開(kāi)啟 10 個(gè) Nginx 才占 150M 內(nèi)存。
-
成本低廉，且開(kāi)源。
-
穩(wěn)定性高，宕機(jī)的概率非常小。
-
內(nèi)置的健康檢查功能：如果有一個(gè)服務(wù)器宕機(jī)，會(huì)做一個(gè)健康檢查，再發(fā)送的請(qǐng)求就不會(huì)發(fā)送到宕機(jī)的服務(wù)器了。重新將請(qǐng)求提交到其他的節(jié)點(diǎn)上
Nginx 應(yīng)用場(chǎng)景？
-
http 服務(wù)器。Nginx 是一個(gè) http 服務(wù)可以獨(dú)立提供 http 服務(wù)。可以做網(wǎng)頁(yè)靜態(tài)服務(wù)器。
-
虛擬主機(jī)。可以實(shí)現(xiàn)在一臺(tái)服務(wù)器虛擬出多個(gè)網(wǎng)站，例如個(gè)人網(wǎng)站使用的虛擬機(jī)。
-
反向代理，負(fù)載均衡。當(dāng)網(wǎng)站的訪(fǎng)問(wèn)量達(dá)到一定程度后，單臺(tái)服務(wù)器不能滿(mǎn)足用戶(hù)的請(qǐng)求時(shí)，需要用多臺(tái)服務(wù)器集群可以使用 nginx 做反向代理。并且多臺(tái)服務(wù)器可以平均分擔(dān)負(fù)載，不會(huì)應(yīng)為某臺(tái)服務(wù)器負(fù)載高宕機(jī)而某臺(tái)服務(wù)器閑置的情況。
-
nginz 中也可以配置安全管理、比如可以使用 Nginx 搭建 API 接口網(wǎng)關(guān), 對(duì)每個(gè)接口服務(wù)進(jìn)行攔截。
Nginx 怎么處理請(qǐng)求的？
server { # 第一個(gè)Server區(qū)塊開(kāi)始，表示一個(gè)獨(dú)立的虛擬主機(jī)站點(diǎn)
listen 80；# 提供服務(wù)的端口，默認(rèn)80
server_name localhost; # 提供服務(wù)的域名主機(jī)名
location / { # 第一個(gè)location區(qū)塊開(kāi)始
root html; # 站點(diǎn)的根目錄，相當(dāng)于Nginx的安裝目錄
index index.html index.html; # 默認(rèn)的首頁(yè)文件，多個(gè)用空格分開(kāi)
} # 第一個(gè)location區(qū)塊結(jié)果
-
首先，Nginx 在啟動(dòng)時(shí)，會(huì)解析配置文件，得到需要監(jiān)聽(tīng)的端口與 IP 地址，然后在 Nginx 的 Master 進(jìn)程里面先初始化好這個(gè)監(jiān)控的 Socket(創(chuàng)建 S ocket，設(shè)置 addr、reuse 等選項(xiàng)，綁定到指定的 ip 地址端口，再 listen 監(jiān)聽(tīng))。
-
然后，再 fork(一個(gè)現(xiàn)有進(jìn)程可以調(diào)用 fork 函數(shù)創(chuàng)建一個(gè)新進(jìn)程。由 fork 創(chuàng)建的新進(jìn)程被稱(chēng)為子進(jìn)程) 出多個(gè)子進(jìn)程出來(lái)。
-
之后，子進(jìn)程會(huì)競(jìng)爭(zhēng) accept 新的連接。此時(shí)，客戶(hù)端就可以向 nginx 發(fā)起連接了。當(dāng)客戶(hù)端與 nginx 進(jìn)行三次握手，與 nginx 建立好一個(gè)連接后。此時(shí)，某一個(gè)子進(jìn)程會(huì) accept 成功，得到這個(gè)建立好的連接的 Socket ，然后創(chuàng)建 nginx 對(duì)連接的封裝，即 ngx_connection_t 結(jié)構(gòu)體。
-
接著，設(shè)置讀寫(xiě)事件處理函數(shù)，并添加讀寫(xiě)事件來(lái)與客戶(hù)端進(jìn)行數(shù)據(jù)的交換。
-
最后，Nginx 或客戶(hù)端來(lái)主動(dòng)關(guān)掉連接，到此，一個(gè)連接就壽終正寢了。
Nginx 是如何實(shí)現(xiàn)高并發(fā)的？
“如果一個(gè) server 采用一個(gè)進(jìn)程 (或者線(xiàn)程) 負(fù)責(zé)一個(gè) request 的方式，那么進(jìn)程數(shù)就是并發(fā)數(shù)。那么顯而易見(jiàn)的，就是會(huì)有很多進(jìn)程在等待中。等什么？最多的應(yīng)該是等待網(wǎng)絡(luò)傳輸。
“而 Nginx 的異步非阻塞工作方式正是利用了這點(diǎn)等待的時(shí)間。在需要等待的時(shí)候，這些進(jìn)程就空閑出來(lái)待命了。因此表現(xiàn)為少數(shù)幾個(gè)進(jìn)程就解決了大量的并發(fā)問(wèn)題。
“Nginx 是如何利用的呢，簡(jiǎn)單來(lái)說(shuō)：同樣的 4 個(gè)進(jìn)程，如果采用一個(gè)進(jìn)程負(fù)責(zé)一個(gè) request 的方式，那么，同時(shí)進(jìn)來(lái) 4 個(gè) request 之后，每個(gè)進(jìn)程就負(fù)責(zé)其中一個(gè)，直至?xí)?huà)關(guān)閉。期間，如果有第 5 個(gè) request 進(jìn)來(lái)了。就無(wú)法及時(shí)反應(yīng)了，因?yàn)?4 個(gè)進(jìn)程都沒(méi)干完活呢，因此，一般有個(gè)調(diào)度進(jìn)程，每當(dāng)新進(jìn)來(lái)了一個(gè) request ，就新開(kāi)個(gè)進(jìn)程來(lái)處理。
回想下，BIO 是不是存在醬紫的問(wèn)題？
“Nginx 不這樣，每進(jìn)來(lái)一個(gè) request ，會(huì)有一個(gè) worker 進(jìn)程去處理。但不是全程的處理，處理到什么程度呢？處理到可能發(fā)生阻塞的地方，比如向上游（后端）服務(wù)器轉(zhuǎn)發(fā) request ，并等待請(qǐng)求返回。那么，這個(gè)處理的 worker 不會(huì)這么傻等著，他會(huì)在發(fā)送完請(qǐng)求后，注冊(cè)一個(gè)事件：“如果 upstream 返回了，告訴我一聲，我再接著干”。于是他就休息去了。此時(shí)，如果再有 request 進(jìn)來(lái)，他就可以很快再按這種方式處理。而一旦上游服務(wù)器返回了，就會(huì)觸發(fā)這個(gè)事件，worker 才會(huì)來(lái)接手，這個(gè) request 才會(huì)接著往下走。
這就是為什么說(shuō)，Nginx 基于事件模型。
由于 web server 的工作性質(zhì)決定了每個(gè) request 的大部份生命都是在網(wǎng)絡(luò)傳輸中，實(shí)際上花費(fèi)在 server 機(jī)器上的時(shí)間片不多。這是幾個(gè)進(jìn)程就解決高并發(fā)的秘密所在。即：
webserver 剛好屬于網(wǎng)絡(luò) IO 密集型應(yīng)用，不算是計(jì)算密集型。
異步，非阻塞，使用 epoll ，和大量細(xì)節(jié)處的優(yōu)化。也正是 Nginx 之所以然的技術(shù)基石。
什么是正向代理？
“一個(gè)位于客戶(hù)端和原始服務(wù)器 (origin server) 之間的服務(wù)器，為了從原始服務(wù)器取得內(nèi)容，客戶(hù)端向代理發(fā)送一個(gè)請(qǐng)求并指定目標(biāo)(原始服務(wù)器)，然后代理向原始服務(wù)器轉(zhuǎn)交請(qǐng)求并將獲得的內(nèi)容返回給客戶(hù)端。
客戶(hù)端才能使用正向代理。正向代理總結(jié)就一句話(huà)：代理端代理的是客戶(hù)端。例如說(shuō)：我們使用的 OpenVPN 等等。
什么是反向代理？
反向代理（Reverse Proxy）方式，是指以代理服務(wù)器來(lái)接受 Internet 上的連接請(qǐng)求，然后將請(qǐng)求，發(fā)給內(nèi)部網(wǎng)絡(luò)上的服務(wù)器并將從服務(wù)器上得到的結(jié)果返回給 Internet 上請(qǐng)求連接的客戶(hù)端，此時(shí)代理服務(wù)器對(duì)外就表現(xiàn)為一個(gè)反向代理服務(wù)器。
“反向代理總結(jié)就一句話(huà)：代理端代理的是服務(wù)端。
反向代理服務(wù)器的優(yōu)點(diǎn)是什么?
“反向代理服務(wù)器可以隱藏源服務(wù)器的存在和特征。它充當(dāng)互聯(lián)網(wǎng)云和 web 服務(wù)器之間的中間層。這對(duì)于安全方面來(lái)說(shuō)是很好的，特別是當(dāng)您使用 web 托管服務(wù)時(shí)。
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 # 媒體類(lèi)型
│ ├── 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í)數(shù)據(jù)目錄
├── html # Nginx默認(rèn)站點(diǎn)目錄
│ ├── 50x.html # 錯(cuò)誤頁(yè)面優(yōu)雅替代顯示文件，例如當(dāng)出現(xiàn)502錯(cuò)誤時(shí)會(huì)調(diào)用此頁(yè)面
│ └── index.html # 默認(rèn)的首頁(yè)文件
├── logs # Nginx日志目錄
│ ├── access.log # 訪(fǎng)問(wèn)日志文件
│ ├── error.log # 錯(cuò)誤日志文件
│ └── nginx.pid # pid文件，Nginx進(jìn)程啟動(dòng)后，會(huì)把所有進(jìn)程的ID號(hào)寫(xiě)到此文件
├── proxy_temp # 臨時(shí)目錄
├── sbin # Nginx命令目錄
│ └── nginx # Nginx的啟動(dòng)命令
├── scgi_temp # 臨時(shí)目錄
└── uwsgi_temp # 臨時(shí)目錄
Nginx 配置文件 nginx.conf 有哪些屬性模塊?
worker_processes 1；# worker進(jìn)程的數(shù)量
events { # 事件區(qū)塊開(kāi)始
worker_connections 1024；# 每個(gè)worker進(jìn)程支持的最大連接數(shù)
} # 事件區(qū)塊結(jié)束
http { # HTTP區(qū)塊開(kāi)始
include mime.types；# Nginx支持的媒體類(lèi)型庫(kù)文件
default_type application/octet-stream；# 默認(rèn)的媒體類(lèi)型
sendfile on；# 開(kāi)啟高效傳輸模式
keepalive_timeout 65；# 連接超時(shí)
server { # 第一個(gè)Server區(qū)塊開(kāi)始，表示一個(gè)獨(dú)立的虛擬主機(jī)站點(diǎn)
listen 80；# 提供服務(wù)的端口，默認(rèn)80
server_name localhost；# 提供服務(wù)的域名主機(jī)名
location / { # 第一個(gè)location區(qū)塊開(kāi)始
root html；# 站點(diǎn)的根目錄，相當(dāng)于Nginx的安裝目錄
index index.html index.htm；# 默認(rèn)的首頁(yè)文件，多個(gè)用空格分開(kāi)
} # 第一個(gè)location區(qū)塊結(jié)果
error_page 500502503504 /50x.html；# 出現(xiàn)對(duì)應(yīng)的http狀態(tài)碼時(shí)，使用50x.html回應(yīng)客戶(hù)
location = /50x.html { # location區(qū)塊開(kāi)始，訪(fǎng)問(wèn)50x.html
root html；# 指定對(duì)應(yīng)的站點(diǎn)目錄為html
}
}
......
cookie 和 session 區(qū)別？
共同：
存放用戶(hù)信息。存放的形式：key-value 格式 變量和變量?jī)?nèi)容鍵值對(duì)。
區(qū)別：
cookie
-
存放在客戶(hù)端瀏覽器
-
每個(gè)域名對(duì)應(yīng)一個(gè) cookie，不能跨躍域名訪(fǎng)問(wèn)其他 cookie
-
用戶(hù)可以查看或修改 cookie
-
http 響應(yīng)報(bào)文里面給你瀏覽器設(shè)置
-
鑰匙（用于打開(kāi)瀏覽器上鎖頭）
session:
-
存放在服務(wù)器（文件，數(shù)據(jù)庫(kù)，redis）
-
存放敏感信息
-
鎖頭
為什么 Nginx 不使用多線(xiàn)程？
“Apache: 創(chuàng)建多個(gè)進(jìn)程或線(xiàn)程，而每個(gè)進(jìn)程或線(xiàn)程都會(huì)為其分配 cpu 和內(nèi)存（線(xiàn)程要比進(jìn)程小的多，所以 worker 支持比 perfork 高的并發(fā)），并發(fā)過(guò)大會(huì)榨干服務(wù)器資源。
Nginx: 采用單線(xiàn)程來(lái)異步非阻塞處理請(qǐng)求（管理員可以配置 Nginx 主進(jìn)程的工作進(jìn)程的數(shù)量）(epoll)，不會(huì)為每個(gè)請(qǐng)求分配 cpu 和內(nèi)存資源，節(jié)省了大量資源，同時(shí)也減少了大量的 CPU 的上下文切換。所以才使得 Nginx 支持更高的并發(fā)。
nginx 和 apache 的區(qū)別
輕量級(jí)，同樣起 web 服務(wù)，比 apache 占用更少的內(nèi)存和資源。
抗并發(fā)，nginx 處理請(qǐng)求是異步非阻塞的，而 apache 則是阻塞性的，在高并發(fā)下 nginx 能保持低資源，低消耗高性能。
高度模塊化的設(shè)計(jì)，編寫(xiě)模塊相對(duì)簡(jiǎn)單。
最核心的區(qū)別在于 apache 是同步多進(jìn)程模型，一個(gè)連接對(duì)應(yīng)一個(gè)進(jìn)程，nginx 是異步的，多個(gè)連接可以對(duì)應(yīng)一個(gè)進(jìn)程。
什么是動(dòng)態(tài)資源、靜態(tài)資源分離？
“動(dòng)態(tài)資源、靜態(tài)資源分離，是讓動(dòng)態(tài)網(wǎng)站里的動(dòng)態(tài)網(wǎng)頁(yè)根據(jù)一定規(guī)則把不變的資源和經(jīng)常變的資源區(qū)分開(kāi)來(lái)，動(dòng)靜資源做好了拆分以后我們就可以根據(jù)靜態(tài)資源的特點(diǎn)將其做緩存操作，這就是網(wǎng)站靜態(tài)化處理的核心思路。
動(dòng)態(tài)資源、靜態(tài)資源分離簡(jiǎn)單的概括是：動(dòng)態(tài)文件與靜態(tài)文件的分離。
為什么要做動(dòng)、靜分離？
在我們的軟件開(kāi)發(fā)中，有些請(qǐng)求是需要后臺(tái)處理的（如：.jsp,.do 等等），有些請(qǐng)求是不需要經(jīng)過(guò)后臺(tái)處理的（如：css、html、jpg、js 等等文件），這些不需要經(jīng)過(guò)后臺(tái)處理的文件稱(chēng)為靜態(tài)文件，否則動(dòng)態(tài)文件。
“因此我們后臺(tái)處理忽略靜態(tài)文件。這會(huì)有人又說(shuō)那我后臺(tái)忽略靜態(tài)文件不就完了嗎？當(dāng)然這是可以的，但是這樣后臺(tái)的請(qǐng)求次數(shù)就明顯增多了。在我們對(duì)資源的響應(yīng)速度有要求的時(shí)候，我們應(yīng)該使用這種動(dòng)靜分離的策略去解決動(dòng)、靜分離將網(wǎng)站靜態(tài)資源（HTML，JavaScript，CSS，img 等文件）與后臺(tái)應(yīng)用分開(kāi)部署，提高用戶(hù)訪(fǎng)問(wèn)靜態(tài)代碼的速度，降低對(duì)后臺(tái)應(yīng)用訪(fǎng)問(wèn)
這里我們將靜態(tài)資源放到 Nginx 中，動(dòng)態(tài)資源轉(zhuǎn)發(fā)到 Tomcat 服務(wù)器中去。
當(dāng)然，因?yàn)楝F(xiàn)在七牛、阿里云等 CDN 服務(wù)已經(jīng)很成熟，主流的做法，是把靜態(tài)資源緩存到 CDN 服務(wù)中，從而提升訪(fǎng)問(wèn)速度。
“相比本地的 Nginx 來(lái)說(shuō)，CDN 服務(wù)器由于在國(guó)內(nèi)有更多的節(jié)點(diǎn)，可以實(shí)現(xiàn)用戶(hù)的就近訪(fǎng)問(wèn)。并且，CDN 服務(wù)可以提供更大的帶寬，不像我們自己的應(yīng)用服務(wù)，提供的帶寬是有限的。
什么叫 CDN 服務(wù)？
CDN ，即內(nèi)容分發(fā)網(wǎng)絡(luò)。
其目的是，通過(guò)在現(xiàn)有的 Internet 中 增加一層新的網(wǎng)絡(luò)架構(gòu)，將網(wǎng)站的內(nèi)容發(fā)布到最接近用戶(hù)的網(wǎng)絡(luò)邊緣，使用戶(hù)可就近取得所需的內(nèi)容，提高用戶(hù)訪(fǎng)問(wèn)網(wǎng)站的速度。
一般來(lái)說(shuō)，因?yàn)楝F(xiàn)在 CDN 服務(wù)比較大眾，所以基本所有公司都會(huì)使用 CDN 服務(wù)。
Nginx 怎么做的動(dòng)靜分離？
“只需要指定路徑對(duì)應(yīng)的目錄。location / 可以使用正則表達(dá)式匹配。并指定對(duì)應(yīng)的硬盤(pán)中的目錄。如下：（操作都是在 Linux 上）
location /image/ {
root /usr/local/static/;
autoindex on;
}
步驟：
# 創(chuàng)建目錄
mkdir /usr/local/static/image
# 進(jìn)入目錄
cd /usr/local/static/image
# 上傳照片
photo.jpg
# 重啟nginx
sudo nginx -s reload
打開(kāi)瀏覽器 輸入 server_name/image/1.jpg 就可以訪(fǎng)問(wèn)該靜態(tài)圖片了
Nginx 負(fù)載均衡的算法怎么實(shí)現(xiàn)的? 策略有哪些?
“為了避免服務(wù)器崩潰，大家會(huì)通過(guò)負(fù)載均衡的方式來(lái)分擔(dān)服務(wù)器壓力。將對(duì)臺(tái)服務(wù)器組成一個(gè)集群，當(dāng)用戶(hù)訪(fǎng)問(wèn)時(shí)，先訪(fǎng)問(wèn)到一個(gè)轉(zhuǎn)發(fā)服務(wù)器，再由轉(zhuǎn)發(fā)服務(wù)器將訪(fǎng)問(wèn)分發(fā)到壓力更小的服務(wù)器。
Nginx 負(fù)載均衡實(shí)現(xiàn)的策略有以下五種：
1 . 輪詢(xún) (默認(rèn))
每個(gè)請(qǐng)求按時(shí)間順序逐一分配到不同的后端服務(wù)器，如果后端某個(gè)服務(wù)器宕機(jī)，能自動(dòng)剔除故障系統(tǒng)。
upstream backserver {
server 192.168.0.12;
server 192.168.0.13;
}
2. 權(quán)重 weight
weight 的值越大，分配到的訪(fǎng)問(wèn)概率越高，主要用于后端每臺(tái)服務(wù)器性能不均衡的情況下。其次是為在主從的情況下設(shè)置不同的權(quán)值，達(dá)到合理有效的地利用主機(jī)資源。
# 權(quán)重越高，在被訪(fǎng)問(wèn)的概率越大，如上例，分別是20%，80%。
upstream backserver {
server 192.168.0.12 weight=2;
server 192.168.0.13 weight=8;
}
3. ip_hash(IP 綁定)
每個(gè)請(qǐng)求按訪(fǎng)問(wèn) IP 的哈希結(jié)果分配，使來(lái)自同一個(gè) IP 的訪(fǎng)客固定訪(fǎng)問(wèn)一臺(tái)后端服務(wù)器，并且可以有效解決動(dòng)態(tài)網(wǎng)頁(yè)存在的 session 共享問(wèn)題
upstream backserver {
ip_hash;
server 192.168.0.12:88;
server 192.168.0.13:80;
}
4. fair(第三方插件)
必須安裝 upstream_fair 模塊。
對(duì)比 weight、ip_hash 更加智能的負(fù)載均衡算法，fair 算法可以根據(jù)頁(yè)面大小和加載時(shí)間長(zhǎng)短智能地進(jìn)行負(fù)載均衡，響應(yīng)時(shí)間短的優(yōu)先分配。
# 哪個(gè)服務(wù)器的響應(yīng)速度快，就將請(qǐng)求分配到那個(gè)服務(wù)器上。
upstream backserver {
server server1;
server server2;
fair;
}
5.url_hash(第三方插件)
必須安裝 Nginx 的 hash 軟件包
按訪(fǎng)問(wèn) url 的 hash 結(jié)果來(lái)分配請(qǐng)求，使每個(gè) url 定向到同一個(gè)后端服務(wù)器，可以進(jìn)一步提高后端緩存服務(wù)器的效率。
upstream backserver {
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
}
如何用 Nginx 解決前端跨域問(wèn)題？
使用 Nginx 轉(zhuǎn)發(fā)請(qǐng)求。把跨域的接口寫(xiě)成調(diào)本域的接口，然后將這些接口轉(zhuǎn)發(fā)到真正的請(qǐng)求地址。
Nginx 虛擬主機(jī)怎么配置?
1、基于域名的虛擬主機(jī)，通過(guò)域名來(lái)區(qū)分虛擬主機(jī)——應(yīng)用：外部網(wǎng)站
2、基于端口的虛擬主機(jī)，通過(guò)端口來(lái)區(qū)分虛擬主機(jī)——應(yīng)用：公司內(nèi)部網(wǎng)站，外部網(wǎng)站的管理后臺(tái)
3、基于 ip 的虛擬主機(jī)。
基于虛擬主機(jī)配置域名
需要建立 / data/www /data/bbs 目錄，windows 本地 hosts 添加虛擬機(jī) ip 地址對(duì)應(yīng)的域名解析；對(duì)應(yīng)域名網(wǎng)站目錄下新增 index.html 文件；
# 當(dāng)客戶(hù)端訪(fǎng)問(wèn)www.lijie.com,監(jiān)聽(tīng)端口號(hào)為80,直接跳轉(zhuǎn)到data/www目錄下文件
server {
listen 80;
server_name www.lijie.com;
location / {
root data/www;
index index.html index.htm;
}
}
# 當(dāng)客戶(hù)端訪(fǎng)問(wèn)www.lijie.com,監(jiān)聽(tīng)端口號(hào)為80,直接跳轉(zhuǎn)到data/bbs目錄下文件
server {
listen 80;
server_name bbs.lijie.com;
location / {
root data/bbs;
index index.html index.htm;
}
}
基于端口的虛擬主機(jī)
使用端口來(lái)區(qū)分，瀏覽器使用域名或 ip 地址: 端口號(hào) 訪(fǎng)問(wèn)
# 當(dāng)客戶(hù)端訪(fǎng)問(wèn)www.lijie.com,監(jiān)聽(tīng)端口號(hào)為8080,直接跳轉(zhuǎn)到data/www目錄下文件
server {
listen 8080;
server_name 8080.lijie.com;
location / {
root data/www;
index index.html index.htm;
}
}
# 當(dāng)客戶(hù)端訪(fǎng)問(wèn)www.lijie.com,監(jiān)聽(tīng)端口號(hào)為80直接跳轉(zhuǎn)到真實(shí)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ù)用戶(hù)請(qǐng)求的 URI 來(lái)執(zhí)行不同的應(yīng)用，也就是根據(jù)用戶(hù)請(qǐng)求的網(wǎng)站 URL 進(jìn)行匹配，匹配成功即進(jìn)行相關(guān)的操作。
location 的語(yǔ)法能說(shuō)出來(lái)嗎？
“注意：~ 代表自己輸入的英文字母
Location 正則案例
# 優(yōu)先級(jí)1,精確匹配，根路徑
location =/ {
return 400;
}
# 優(yōu)先級(jí)2,以某個(gè)字符串開(kāi)頭,以av開(kāi)頭的，優(yōu)先匹配這里，區(qū)分大小寫(xiě)
location ^~ /av {
root /data/av/;
}
# 優(yōu)先級(jí)3，區(qū)分大小寫(xiě)的正則匹配，匹配/media*****路徑
location ~ /media {
alias /data/static/;
}
# 優(yōu)先級(jí)4 ，不區(qū)分大小寫(xiě)的正則匹配，所有的****.jpg|gif|png 都走這里
location ~* .*\.(jpg|gif|png|js|css)$ {
root /data/av/;
}
# 優(yōu)先7，通用匹配
location / {
return 403;
}
限流怎么做的？
Nginx 限流就是限制用戶(hù)請(qǐng)求速度，防止服務(wù)器受不了
限流有 3 種
-
正常限制訪(fǎng)問(wèn)頻率（正常流量）
-
突發(fā)限制訪(fǎng)問(wèn)頻率（突發(fā)流量）
-
限制并發(fā)連接數(shù)
Nginx 的限流都是基于漏桶流算法
“實(shí)現(xiàn)三種限流算法
1、正常限制訪(fǎng)問(wèn)頻率（正常流量）：
限制一個(gè)用戶(hù)發(fā)送的請(qǐng)求，我 Nginx 多久接收一個(gè)請(qǐng)求。
Nginx 中使用 ngx_http_limit_req_module 模塊來(lái)限制的訪(fǎng)問(wèn)頻率，限制的原理實(shí)質(zhì)是基于漏桶算法原理來(lái)實(shí)現(xiàn)的。在 nginx.conf 配置文件中可以使用 limit_req_zone 命令及 limit_req 命令限制單個(gè) IP 的請(qǐng)求處理頻率。
# 定義限流維度，一個(gè)用戶(hù)一分鐘一個(gè)請(qǐng)求進(jìn)來(lái)，多余的全部漏掉
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 秒一個(gè)請(qǐng)求，1r/m 一分鐘接收一個(gè)請(qǐng)求， 如果 Nginx 這時(shí)還有別人的請(qǐng)求沒(méi)有處理完，Nginx 就會(huì)拒絕處理該用戶(hù)請(qǐng)求。
2、突發(fā)限制訪(fǎng)問(wèn)頻率（突發(fā)流量）：
限制一個(gè)用戶(hù)發(fā)送的請(qǐng)求，我 Nginx 多久接收一個(gè)。
上面的配置一定程度可以限制訪(fǎng)問(wèn)頻率，但是也存在著一個(gè)問(wèn)題：如果突發(fā)流量超出請(qǐng)求被拒絕處理，無(wú)法處理活動(dòng)時(shí)候的突發(fā)流量，這時(shí)候應(yīng)該如何進(jìn)一步處理呢？
Nginx 提供 burst 參數(shù)結(jié)合 nodelay 參數(shù)可以解決流量突發(fā)的問(wèn)題，可以設(shè)置能處理的超過(guò)設(shè)置的請(qǐng)求數(shù)外能額外處理的請(qǐng)求數(shù)。我們可以將之前的例子添加 burst 參數(shù)以及 nodelay 參數(shù)：
# 定義限流維度，一個(gè)用戶(hù)一分鐘一個(gè)請(qǐng)求進(jìn)來(lái)，多余的全部漏掉
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;
}
}
“為什么就多了一個(gè) burst=5 nodelay; 呢，多了這個(gè)可以代表 Nginx 對(duì)于一個(gè)用戶(hù)的請(qǐng)求會(huì)立即處理前五個(gè)，多余的就慢慢來(lái)落，沒(méi)有其他用戶(hù)的請(qǐng)求我就處理你的，有其他的請(qǐng)求的話(huà)我 Nginx 就漏掉不接受你的請(qǐng)求
3、 限制并發(fā)連接數(shù)
Nginx 中的 ngx_http_limit_conn_module 模塊提供了限制并發(fā)連接數(shù)的功能，可以使用 limit_conn_zone 指令以及 limit_conn 執(zhí)行進(jìn)行配置。接下來(lái)我們可以通過(guò)一個(gè)簡(jiǎn)單的例子來(lái)看下：
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;
}
}
上面配置了單個(gè) IP 同時(shí)并發(fā)連接數(shù)最多只能 10 個(gè)連接，并且設(shè)置了整個(gè)虛擬服務(wù)器同時(shí)最大并發(fā)數(shù)最多只能 100 個(gè)鏈接。當(dāng)然，只有當(dāng)請(qǐng)求的 header 被服務(wù)器處理后，虛擬服務(wù)器的連接數(shù)才會(huì)計(jì)數(shù)。剛才有提到過(guò) Nginx 是基于漏桶算法原理實(shí)現(xiàn)的，實(shí)際上限流一般都是基于漏桶算法和令牌桶算法實(shí)現(xiàn)的。
漏桶流算法和令牌桶算法知道？
漏桶算法
漏桶算法思路很簡(jiǎn)單，我們把水比作是請(qǐng)求，漏桶比作是系統(tǒng)處理能力極限，水先進(jìn)入到漏桶里，漏桶里的水按一定速率流出，當(dāng)流出的速率小于流入的速率時(shí)，由于漏桶容量有限，后續(xù)進(jìn)入的水直接溢出（拒絕請(qǐng)求），以此實(shí)現(xiàn)限流。
令牌桶算法
令牌桶算法的原理也比較簡(jiǎn)單，我們可以理解成醫(yī)院的掛號(hào)看病，只有拿到號(hào)以后才可以進(jìn)行診病。
“系統(tǒng)會(huì)維護(hù)一個(gè)令牌（token）桶，以一個(gè)恒定的速度往桶里放入令牌（token），這時(shí)如果有請(qǐng)求進(jìn)來(lái)想要被處理，則需要先從桶里獲取一個(gè)令牌（token），當(dāng)桶里沒(méi)有令牌（token）可取時(shí)，則該請(qǐng)求將被拒絕服務(wù)。令牌桶算法通過(guò)控制桶的容量、發(fā)放令牌的速率，來(lái)達(dá)到對(duì)請(qǐng)求的限制。
Nginx 配置高可用性怎么配置？
“當(dāng)上游服務(wù)器 (真實(shí)訪(fǎng)問(wèn)服務(wù)器)，一旦出現(xiàn)故障或者是沒(méi)有及時(shí)相應(yīng)的話(huà)，應(yīng)該直接輪訓(xùn)到下一臺(tái)服務(wù)器，保證服務(wù)器的高可用
Nginx 配置代碼：
server {
listen 80;
server_name www.lijie.com;
location / {
### 指定上游服務(wù)器負(fù)載均衡服務(wù)器
proxy_pass http://backServer;
###nginx與上游服務(wù)器(真實(shí)訪(fǎng)問(wèn)的服務(wù)器)超時(shí)時(shí)間 后端服務(wù)器連接的超時(shí)時(shí)間_發(fā)起握手等候響應(yīng)超時(shí)時(shí)間
proxy_connect_timeout 1s;
###nginx發(fā)送給上游服務(wù)器(真實(shí)訪(fǎng)問(wèn)的服務(wù)器)超時(shí)時(shí)間
proxy_send_timeout 1s;
### nginx接受上游服務(wù)器(真實(shí)訪(fǎng)問(wèn)的服務(wù)器)超時(shí)時(shí)間
proxy_read_timeout 1s;
index index.html index.htm;
}
}
Nginx 怎么判斷別 IP 不可訪(fǎng)問(wèn)？
# 如果訪(fǎng)問(wèn)的ip地址為192.168.9.115,則返回403
if ($remote_addr = 192.168.9.115) {
return 403;
}
在 nginx 中，如何使用未定義的服務(wù)器名稱(chēng)來(lái)阻止處理請(qǐng)求？
只需將請(qǐng)求刪除的服務(wù)器就可以定義為：
服務(wù)器名被保留一個(gè)空字符串，他在沒(méi)有主機(jī)頭字段的情況下匹配請(qǐng)求，而一個(gè)特殊的 nginx 的非標(biāo)準(zhǔn)代碼被返回，從而終止連接。
怎么限制瀏覽器訪(fǎng)問(wèn)？
## 不允許谷歌瀏覽器訪(fǎng)問(wèn) 如果是谷歌瀏覽器返回500
if ($http_user_agent ~ Chrome) {
return 500;
}
Rewrite全局變量是什么？
$remote_addr //獲取客戶(hù)端ip
$binary_remote_addr //客戶(hù)端ip（二進(jìn)制)
$remote_port //客戶(hù)端port，如：50472
$remote_user //已經(jīng)經(jīng)過(guò)Auth Basic Module驗(yàn)證的用戶(hù)名
$host //請(qǐng)求主機(jī)頭字段，否則為服務(wù)器名稱(chēng)，如:blog.sakmon.com
$request //用戶(hù)請(qǐng)求信息，如：GET ?a=1&b=2 HTTP/1.1
$request_filename //當(dāng)前請(qǐng)求的文件的路徑名，由root或alias和URI request組合而成，如：/2013/81.html
$status //請(qǐng)求的響應(yīng)狀態(tài)碼,如:200
$body_bytes_sent // 響應(yīng)時(shí)送出的body字節(jié)數(shù)數(shù)量。即使連接中斷，這個(gè)數(shù)據(jù)也是精確的,如：40
$content_length // 等于請(qǐng)求行的“Content_Length”的值
$content_type // 等于請(qǐng)求行的“Content_Type”的值
$http_referer // 引用地址
$http_user_agent // 客戶(hù)端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相同 這個(gè)變量指當(dāng)前的請(qǐng)求URI，不包括任何參數(shù)(見(jiàn)$args) 如:/2013/81.html
$document_root //針對(duì)當(dāng)前請(qǐng)求的根路徑設(shè)置值
$hostname //如：centos53.localdomain
$http_cookie //客戶(hù)端cookie信息
$cookie_COOKIE //cookie COOKIE變量的值
$is_args //如果有$args參數(shù)，這個(gè)變量等于”?”，否則等于”"，空值，如?
$limit_rate //這個(gè)變量可以限制連接速率，0表示不限速
$query_string // 與$args相同 等于當(dāng)中URL的參數(shù)(GET)，如a=1&b=2
$request_body // 記錄POST過(guò)來(lái)的數(shù)據(jù)信息
$request_body_file //客戶(hù)端請(qǐng)求主體信息的臨時(shí)文件名
$request_method //客戶(hù)端請(qǐng)求的動(dòng)作，通常為GET或POST,如：GET
$request_uri //包含請(qǐng)求參數(shù)的原始URI，不包含主機(jī)名，如：/2013/81.html?a=1&b=2
$scheme //HTTP方法（如http，https）,如：http
$uri //這個(gè)變量指當(dāng)前的請(qǐng)求URI，不包括任何參數(shù)(見(jiàn)$args) 如:/2013/81.html
$request_completion //如果請(qǐng)求結(jié)束，設(shè)置為OK. 當(dāng)請(qǐng)求未結(jié)束或如果該請(qǐng)求不是請(qǐng)求鏈串的最后一個(gè)時(shí)，為空(Empty)，如：OK
$server_protocol //請(qǐng)求使用的協(xié)議，通常是HTTP/1.0或HTTP/1.1，如：HTTP/1.1
$server_addr //服務(wù)器IP地址，在完成一次系統(tǒng)調(diào)用后可以確定這個(gè)值
$server_name //服務(wù)器名稱(chēng)，如：blog.sakmon.com
$server_port //請(qǐng)求到達(dá)服務(wù)器的端口號(hào),如：80
Nginx 如何實(shí)現(xiàn)后端服務(wù)的健康檢查?
方式一，利用 nginx 自帶模塊 ngx_http_proxy_module 和 ngx_http_upstream_module 對(duì)后端節(jié)點(diǎn)做健康檢查。
方式二 (推薦)，利用 nginx_upstream_check_module 模塊對(duì)后端節(jié)點(diǎn)做健康檢查。
Nginx 如何開(kāi)啟壓縮？
開(kāi)啟 nginx gzip 壓縮后，網(wǎng)頁(yè)、css、js 等靜態(tài)資源的大小會(huì)大大的減少，從而可以節(jié)約大量的帶寬，提高傳輸效率，給用戶(hù)快的體驗(yàn)。雖然會(huì)消耗 cpu 資源，但是為了給用戶(hù)更好的體驗(yàn)是值得的。
開(kāi)啟的配置如下：
將以上配置放到 nginx.conf 的 http{…} 節(jié)點(diǎn)中。
http {
# 開(kāi)啟gzip
gzip on;
# 啟用gzip壓縮的最小文件；小于設(shè)置值的文件將不會(huì)被壓縮
gzip_min_length 1k;
# gzip 壓縮級(jí)別 1-10
gzip_comp_level 2;
# 進(jìn)行壓縮的文件類(lèi)型。
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，建議開(kāi)啟
gzip_vary on;
}
保存并重啟 nginx，刷新頁(yè)面（為了避免緩存，請(qǐng)強(qiáng)制刷新）就能看到效果了。以谷歌瀏覽器為例，通過(guò) F12 看請(qǐng)求的響應(yīng)頭部：
我們可以先來(lái)對(duì)比下，如果我們沒(méi)有開(kāi)啟 zip 壓縮之前，我們的對(duì)應(yīng)的文件大小，如下所示：
現(xiàn)在我們開(kāi)啟了 gzip 進(jìn)行壓縮后的文件的大小，可以看到如下所示：
并且我們查看響應(yīng)頭會(huì)看到 gzip 這樣的壓縮，如下所示
gzip 壓縮前后效果對(duì)比：jquery 原大小 90kb，壓縮后只有 30kb。
gzip 雖然好用，但是以下類(lèi)型的資源不建議啟用。
1、圖片類(lèi)型
“原因：圖片如 jpg、png 本身就會(huì)有壓縮，所以就算開(kāi)啟 gzip 后，壓縮前和壓縮后大小沒(méi)有多大區(qū)別，所以開(kāi)啟了反而會(huì)白白的浪費(fèi)資源。（Tips：可以試試將一張 jpg 圖片壓縮為 zip，觀(guān)察大小并沒(méi)有多大的變化。雖然 zip 和 gzip 算法不一樣，但是可以看出壓縮圖片的價(jià)值并不大）
2、大文件
原因：會(huì)消耗大量的 cpu 資源，且不一定有明顯的效果。
ngx_http_upstream_module 的作用是什么?
“ngx_http_upstream_module 用于定義可通過(guò) fastcgi 傳遞、proxy 傳遞、uwsgi 傳遞、memcached 傳遞和 scgi 傳遞指令來(lái)引用的服務(wù)器組。
什么是 C10K 問(wèn)題?
C10K 問(wèn)題是指無(wú)法同時(shí)處理大量客戶(hù)端 (10,000) 的網(wǎng)絡(luò)套接字。
Nginx 是否支持將請(qǐng)求壓縮到上游?
“您可以使用 Nginx 模塊 gunzip 將請(qǐng)求壓縮到上游。gunzip 模塊是一個(gè)過(guò)濾器，它可以對(duì)不支持 “gzip” 編碼方法的客戶(hù)機(jī)或服務(wù)器使用 “內(nèi)容編碼: gzip” 來(lái)解壓縮響應(yīng)。
如何在 Nginx 中獲得當(dāng)前的時(shí)間?
要獲得 Nginx 的當(dāng)前時(shí)間，必須使用 SSI 模塊、和 date_local 的變量。
Proxy_set_header THE-TIME $date_gmt;
用 Nginx 服務(wù)器解釋 - s 的目的是什么?
用于運(yùn)行 Nginx -s 參數(shù)的可執(zhí)行文件。
如何在 Nginx 服務(wù)器上添加模塊?
在編譯過(guò)程中，必須選擇 Nginx 模塊，因?yàn)?Nginx 不支持模塊的運(yùn)行時(shí)間選擇。
生產(chǎn)中如何設(shè)置 worker 進(jìn)程的數(shù)量呢？
“在有多個(gè) cpu 的情況下，可以設(shè)置多個(gè) worker，worker 進(jìn)程的數(shù)量可以設(shè)置到和 cpu 的核心數(shù)一樣多，如果在單個(gè) cpu 上起多個(gè) worker 進(jìn)程，那么操作系統(tǒng)會(huì)在多個(gè) worker 之間進(jìn)行調(diào)度，這種情況會(huì)降低系統(tǒng)性能，如果只有一個(gè) cpu，那么只啟動(dòng)一個(gè) worker 進(jìn)程就可以了。
nginx 狀態(tài)碼
499：
“服務(wù)端處理時(shí)間過(guò)長(zhǎng)，客戶(hù)端主動(dòng)關(guān)閉了連接。
502：
(1).FastCGI 進(jìn)程是否已經(jīng)啟動(dòng)
(2).FastCGI worker 進(jìn)程數(shù)是否不夠
(3).FastCGI 執(zhí)行時(shí)間過(guò)長(zhǎng)
-
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í)行時(shí)間過(guò)長(zhǎng)
-
將 php-fpm.conf 的 0s 的 0s 改成一個(gè)時(shí)間