一、什么是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)站用戶有很多，例如：新浪、網(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(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)站的訪問(wèn)量達(dá)到一定程度后，單臺(tái)服務(wù)器不能滿足用戶的請(qǐng)求時(shí)，需要用多臺(tái)服務(wù)器集群可以使用nginx做反向代理。并且多臺(tái)服務(wù)器可以平均分擔(dān)負(fù)載，不會(huì)應(yīng)為某臺(tái)服務(wù)器負(fù)載高宕機(jī)而某臺(tái)服務(wù)器閑置的情況。

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

四、Nginx怎么處理請(qǐng)求？

首先，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í)，客戶端就可以向 nginx 發(fā)起連接了。當(dāng)客戶端與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)與客戶端進(jìn)行數(shù)據(jù)的交換。

最后，Nginx 或客戶端來(lái)主動(dòng)關(guān)掉連接，到此，一個(gè)連接就壽終正寢了。

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

如果一個(gè) server 采用一個(gè)進(jì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í)掙P(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è)位于客戶端和原始服務(wù)器(origin server)之間的服務(wù)器，為了從原始服務(wù)器取得內(nèi)容，客戶端向代理發(fā)送一個(gè)請(qǐng)求并指定目標(biāo)(原始服務(wù)器)，然后代理向原始服務(wù)器轉(zhuǎn)交請(qǐng)求并將獲得的內(nèi)容返回給客戶端。

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

七、什么是反向代理？

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

反向代理總結(jié)就一句話：代理端代理的是服務(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)有哪些？

九、Nginx配置文件nginx.conf有哪些屬性模塊？

十、cookie和session區(qū)別？

共同:

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

區(qū)別:

cookie：

存放在客戶端瀏覽器

每個(gè)域名對(duì)應(yīng)一個(gè)cookie，不能跨躍域名訪問(wèn)其他cookie

用戶可以查看或修改cookie

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

鑰匙（用于打開(kāi)瀏覽器上鎖頭）

session:

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

存放敏感信息

鎖頭

十一、為什么 Nginx 不使用多線程？

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

Nginx: 采用單線程來(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)部署，提高用戶訪問(wèn)靜態(tài)代碼的速度，降低對(duì)后臺(tái)應(yī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ù)中，從而提升訪問(wèn)速度。

相比本地的 Nginx 來(lái)說(shuō)，CDN 服務(wù)器由于在國(guó)內(nèi)有更多的節(jié)點(diǎn)，可以實(shí)現(xiàn)用戶的就近訪問(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ā)布到最接近用戶的網(wǎng)絡(luò)邊緣，使用戶可就近取得所需的內(nèi)容，提高用戶訪問(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上）

步驟：

打開(kāi)瀏覽器 輸入 server_name/image/photo.jpg 就可以訪問(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)用戶訪問(wèn)時(shí)，先訪問(wèn)到一個(gè)轉(zhuǎn)發(fā)服務(wù)器，再由轉(zhuǎn)發(fā)服務(wù)器將訪問(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)。

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

3.ip_hash( IP綁定)：每個(gè)請(qǐng)求按訪問(wèn)IP的哈希結(jié)果分配，使來(lái)自同一個(gè)IP的訪客固定訪問(wèn)一臺(tái)后端服務(wù)器，并且可以有效解決動(dòng)態(tài)網(wǎng)頁(yè)存在的session共享問(wèn)題

4.fair(第三方插件)：必須安裝upstream_fair模塊。

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

5.url_hash(第三方插件)：必須安裝Nginx的hash軟件包。

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

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

二十一、基于端口的虛擬主機(jī)

使用端口來(lái)區(qū)分，瀏覽器使用域名或ip地址:端口號(hào) 訪問(wèn)

二十二、location的作用是什么？

location指令的作用是根據(jù)用戶請(qǐng)求的URI來(lái)執(zhí)行不同的應(yīng)用，也就是根據(jù)用戶請(qǐng)求的網(wǎng)站URL進(jìn)行匹配，匹配成功即進(jìn)行相關(guān)的操作。 location的語(yǔ)法能說(shuō)出來(lái)嗎？ 注意：~ 代表自己輸入的英文字母

二十三、location正則案例

二十四、限流怎么做的?

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

限流有3種：

正常限制訪問(wèn)頻率（正常流量）

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

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

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

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

1、正常限制訪問(wèn)頻率（正常流量）

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

Nginx中使用ngx_http_limit_req_module模塊來(lái)限制的訪問(wèn)頻率，限制的原理實(shí)質(zhì)是基于漏桶算法原理來(lái)實(shí)現(xiàn)的。在nginx.conf配置文件中可以使用limit_req_zone命令及l(fā)imit_req命令限制單個(gè)IP的請(qǐng)求處理頻率。

1r/s代表1秒一個(gè)請(qǐng)求，1r/m一分鐘接收一個(gè)請(qǐng)求， 如果Nginx這時(shí)還有別人的請(qǐng)求沒(méi)有處理完，Nginx就會(huì)拒絕處理該用戶請(qǐng)求。

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

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

上面的配置一定程度可以限制訪問(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è) burst=5 nodelay; 呢，多了這個(gè)可以代表Nginx對(duì)于一個(gè)用戶的請(qǐng)求會(huì)立即處理前五個(gè)，多余的就慢慢來(lái)落，沒(méi)有其他用戶的請(qǐng)求我就處理你的，有其他的請(qǐng)求的話我Nginx就漏掉不接受你的請(qǐng)求！

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

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

上面配置了單個(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)的。

二十五、漏桶流算法和令牌桶算法知道？

一文搞定，手?jǐn)]Springboot + aop + Lua分布式限流的最佳實(shí)踐_vincent-CSDN博客_springboot如何限流

漏桶算法:漏桶算法思路很簡(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í)訪問(wèn)服務(wù)器)，一旦出現(xiàn)故障或者是沒(méi)有及時(shí)相應(yīng)的話，應(yīng)該直接輪訓(xùn)到下一臺(tái)服務(wù)器，保證服務(wù)器的高可用

Nginx配置代碼：

二十七、Nginx怎么判斷別IP不可訪問(wèn)？

二十八、在nginx中，如何使用未定義的服務(wù)器名稱(chēng)來(lái)阻止處理請(qǐng)求？

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

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

二十九、怎么限制瀏覽器訪問(wèn)？

三十、Rewrite全局變量是什么？

三十一、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é)約大量的帶寬，提高傳輸效率，給用戶快的體驗(yàn)。雖然會(huì)消耗cpu資源，但是為了給用戶更好的體驗(yàn)是值得的。

開(kāi)啟的配置如下：

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

保存并重啟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，觀察大小并沒(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í)處理大量客戶端(10,000)的網(wǎng)絡(luò)套接字。

三十五、Nginx是否支持將請(qǐng)求壓縮到上游?

您可以使用Nginx模塊gunzip將請(qǐng)求壓縮到上游。gunzip模塊是一個(gè)過(guò)濾器，它可以對(duì)不支持gzip編碼方法的客戶機(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)镹ginx不支持模塊的運(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)，客戶端主動(dòng)關(guān)閉了連接。

502 服務(wù)器錯(cuò)誤

下面是502的一些可能性：

FastCGI進(jìn)程是否已經(jīng)啟動(dòng)；

FastCGI worker進(jìn)程數(shù)是否不夠；

FastCGI執(zhí)行時(shí)間過(guò)長(zhǎng)；

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

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

php腳本執(zhí)行時(shí)間過(guò)長(zhǎng)

將php-fpm.conf的0s的0s改成一個(gè)時(shí)間！

鏈接：https://www.cnblogs.com/lvzhenjiang/articles/16418039.html