一、什么是Nginx？

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

二、Nginx有哪些優(yōu)點(diǎn)？

跨平臺、配置簡單。

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

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

成本低廉，且開源。

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

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

三、Nginx應(yīng)用場景？

http服務(wù)器：Nginx是一個(gè)http服務(wù)可以獨(dú)立提供http服務(wù)?？梢宰鼍W(wǎng)頁靜態(tài)服務(wù)器。

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

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

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

四、Nginx怎么處理請求？

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

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

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

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

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

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

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

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

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

回想下，BIO 是不是存在這樣的問題？

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

這就是為什么說，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è)請求并指定目標(biāo)(原始服務(wù)器)，然后代理向原始服務(wù)器轉(zhuǎn)交請求并將獲得的內(nèi)容返回給客戶端。

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

七、什么是反向代理？

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

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

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

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

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

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

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

共同:

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

區(qū)別:

cookie：

存放在客戶端瀏覽器

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

用戶可以查看或修改cookie

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

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

session:

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

存放敏感信息

鎖頭

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

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

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

十二、nginx和apache的區(qū)別

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

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

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

最核心的區(qū)別在于apache是同步多進(jìn)程模型，一個(gè)連接對應(yīng)一個(gè)進(jìn)程，nginx是異步的，多個(gè)連接可以對應(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)頁根據(jù)一定規(guī)則把不變的資源和經(jīng)常變的資源區(qū)分開來，動(dòng)靜資源做好了拆分以后我們就可以根據(jù)靜態(tài)資源的特點(diǎn)將其做緩存操作，這就是網(wǎng)站靜態(tài)化處理的核心思路。

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

十四、為什么要做動(dòng)、靜分離？

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

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

這里我們將靜態(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ù)中，從而提升訪問速度。

相比本地的 Nginx 來說，CDN 服務(wù)器由于在國內(nèi)有更多的節(jié)點(diǎn)，可以實(shí)現(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)站的速度。

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

十六、Nginx怎么做的動(dòng)靜分離？

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

步驟：

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

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

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

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

1 .輪詢(默認(rèn))：每個(gè)請求按時(shí)間順序逐一分配到不同的后端服務(wù)器，如果后端某個(gè)服務(wù)器宕機(jī)，能自動(dòng)剔除故障系統(tǒng)。

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

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

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

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

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

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

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

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

十九、Nginx虛擬主機(jī)怎么配置?

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

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

3、基于ip的虛擬主機(jī)。

二十、基于虛擬主機(jī)配置域名

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

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

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

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

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

二十三、location正則案例

二十四、限流怎么做的?

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

限流有3種：

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

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

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

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

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

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

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

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

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

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

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

上面的配置一定程度可以限制訪問頻率，但是也存在著一個(gè)問題：如果突發(fā)流量超出請求被拒絕處理，無法處理活動(dòng)時(shí)候的突發(fā)流量，這時(shí)候應(yīng)該如何進(jìn)一步處理呢？Nginx提供burst參數(shù)結(jié)合nodelay參數(shù)可以解決流量突發(fā)的問題，可以設(shè)置能處理的超過設(shè)置的請求數(shù)外能額外處理的請求數(shù)。我們可以將之前的例子添加burst參數(shù)以及nodelay參數(shù)：

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

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

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

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

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

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

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

****

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

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

二十六、Nginx配置高可用性怎么配置？

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

Nginx配置代碼：

二十七、Nginx怎么判斷別IP不可訪問？

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

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

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

二十九、怎么限制瀏覽器訪問？

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

三十一、Nginx 如何實(shí)現(xiàn)后端服務(wù)的健康檢查？

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

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

三十二、Nginx 如何開啟壓縮？

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

開啟的配置如下：

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

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

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

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

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

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

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

1、圖片類型

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

2、大文件

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

三十三、ngx_http_upstream_module的作用是什么?

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

三十四、什么是C10K問題?

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

三十五、Nginx是否支持將請求壓縮到上游?

您可以使用Nginx模塊gunzip將請求壓縮到上游。gunzip模塊是一個(gè)過濾器，它可以對不支持gzip編碼方法的客戶機(jī)或服務(wù)器使用內(nèi)容編碼:gzip來解壓縮響應(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ù)器上添加模塊?

在編譯過程中，必須選擇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í)間過長，客戶端主動(dòng)關(guān)閉了連接。

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

下面是502的一些可能性：

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

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

FastCGI執(zhí)行時(shí)間過長；

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

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

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

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

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