深入理解Nginx工作原理及優(yōu)化技巧

?? 歡迎加入小哈的星球，你將獲得: 專屬的項(xiàng)目實(shí)戰(zhàn) / 1v1 提問(wèn) / Java 學(xué)習(xí)路線 / 學(xué)習(xí)打卡 / 每月贈(zèng)書(shū) / 社群討論

• 新項(xiàng)目:《從零手?jǐn)]：仿小紅書(shū)（微服務(wù)架構(gòu)）》 正在持續(xù)爆肝中，基于 Spring Cloud Alibaba + Spring Boot 3.x + JDK 17..., 點(diǎn)擊查看項(xiàng)目介紹；
• 《從零手?jǐn)]：前后端分離博客項(xiàng)目（全棧開(kāi)發(fā)）》 2期已完結(jié),演示鏈接：http://116.62.199.48/;

截止目前，累計(jì)輸出 54w+ 字，講解圖 2330+ 張，還在持續(xù)爆肝中.. 后續(xù)還會(huì)上新更多項(xiàng)目，目標(biāo)是將 Java 領(lǐng)域典型的項(xiàng)目都整一波，如秒殺系統(tǒng), 在線商城, IM 即時(shí)通訊，Spring Cloud Alibaba 等等，戳我加入學(xué)習(xí)，解鎖全部項(xiàng)目，已有1900+小伙伴加入

• 一、Nginx的模塊與工作原理
• 二、Nginx的進(jìn)程模型
• 三、Nginx為啥性能高－多進(jìn)程IO模型
• 四、Nginx+FastCGI運(yùn)行原理
• 五、Nginx+PHP正確配置
• 六、Nginx優(yōu)化
• 七、錯(cuò)誤排查
• 八、Nginx的php漏洞

NGINX以高性能的負(fù)載均衡器，緩存，和web服務(wù)器聞名，驅(qū)動(dòng)了全球超過(guò) 40% 最繁忙的網(wǎng)站。在大多數(shù)場(chǎng)景下，默認(rèn)的 NGINX 和 Linux 設(shè)置可以很好的工作，但要達(dá)到最佳性能，有些時(shí)候必須做些調(diào)整。

NGINX被廣泛應(yīng)用于大規(guī)模網(wǎng)站、Web應(yīng)用和移動(dòng)應(yīng)用等領(lǐng)域，以其卓越的性能、高并發(fā)處理能力和低內(nèi)存消耗而聞名。

以下是NGINX的一些特點(diǎn)：

• 高性能：通過(guò)采用事件驅(qū)動(dòng)架構(gòu)和異步非阻塞處理方式，使得NGINX在面對(duì)高并發(fā)請(qǐng)求時(shí)具備出色的性能表現(xiàn)。
• 反向代理：可以作為反向代理服務(wù)器，將客戶端請(qǐng)求轉(zhuǎn)發(fā)給后端的多個(gè)服務(wù)器，實(shí)現(xiàn)負(fù)載均衡和故障恢復(fù)。
• 靜態(tài)文件服務(wù)：通過(guò)簡(jiǎn)單配置即可提供靜態(tài)文件的訪問(wèn)服務(wù)，并且能夠支持更快速地傳輸靜態(tài)文件。
• 動(dòng)態(tài)內(nèi)容處理：可以與各種動(dòng)態(tài)語(yǔ)言（如PHP、Python等）配合使用，提供動(dòng)態(tài)內(nèi)容處理能力。
• 緩存加速：支持反向代理緩存功能，在后端服務(wù)器無(wú)法直接響應(yīng)時(shí)，可以返回緩存頁(yè)面提升響應(yīng)速度。
• SSL/TLS支持：能夠提供HTTPS協(xié)議的支持，保障數(shù)據(jù)傳輸?shù)陌踩浴?
• 可擴(kuò)展性和模塊化架構(gòu)：支持豐富的第三方模塊，可通過(guò)添加模塊來(lái)擴(kuò)展NGINX的功能。

一、Nginx的模塊與工作原理

Nginx由內(nèi)核和模塊組成，其中，內(nèi)核的設(shè)計(jì)非常微小和簡(jiǎn)潔，完成的工作也非常簡(jiǎn)單，僅僅通過(guò)查找配置文件將客戶端請(qǐng)求映射到一個(gè)location block（location是Nginx配置中的一個(gè)指令，用于URL匹配），而在這個(gè)location中所配置的每個(gè)指令將會(huì)啟動(dòng)不同的模塊去完成相應(yīng)的工作。

Nginx的模塊從結(jié)構(gòu)上分為核心模塊、基礎(chǔ)模塊和第三方模塊：

• 核心模塊：HTTP模塊、EVENT模塊和MAIL模塊
• 基礎(chǔ)模塊：HTTP Access模塊、HTTP FastCGI模塊、HTTP Proxy模塊和HTTP Rewrite模塊，
• 第三方模塊：HTTP Upstream Request Hash模塊、Notice模塊和HTTP Access Key模塊。

用戶根據(jù)自己的需要開(kāi)發(fā)的模塊都屬于第三方模塊。正是有了這么多模塊的支撐，Nginx的功能才會(huì)如此強(qiáng)大。

Nginx的模塊從功能上分為如下三類：

• Handlers（處理器模塊）：此類模塊直接處理請(qǐng)求，并進(jìn)行輸出內(nèi)容和修改headers信息等操作。Handlers處理器模塊一般只能有一個(gè)。
• Filters （過(guò)濾器模塊）：此類模塊主要對(duì)其他處理器模塊輸出的內(nèi)容進(jìn)行修改操作，最后由Nginx輸出。
• Proxies （代理類模塊）：此類模塊是Nginx的HTTP Upstream之類的模塊，這些模塊主要與后端一些服務(wù)比如FastCGI等進(jìn)行交互，實(shí)現(xiàn)服務(wù)代理和負(fù)載均衡等功能。

圖1-1展示了Nginx模塊常規(guī)的HTTP請(qǐng)求和響應(yīng)的過(guò)程：

Nginx本身做的工作實(shí)際很少，當(dāng)它接到一個(gè)HTTP請(qǐng)求時(shí)，它僅僅是通過(guò)查找配置文件將此次請(qǐng)求映射到一個(gè)location block，而此location中所配置的各個(gè)指令則會(huì)啟動(dòng)不同的模塊去完成工作，因此模塊可以看做Nginx真正的勞動(dòng)工作者。通常一個(gè)location中的指令會(huì)涉及一個(gè)handler模塊和多個(gè)filter模塊（當(dāng)然，多個(gè)location可以復(fù)用同一個(gè)模塊）。handler模塊負(fù)責(zé)處理請(qǐng)求，完成響應(yīng)內(nèi)容的生成，而filter模塊對(duì)響應(yīng)內(nèi)容進(jìn)行處理。

Nginx的模塊直接被編譯進(jìn)Nginx，因此屬于靜態(tài)編譯方式。啟動(dòng)Nginx后，Nginx的模塊被自動(dòng)加載，不像Apache，首先將模塊編譯為一個(gè)so文件，然后在配置文件中指定是否進(jìn)行加載。在解析配置文件時(shí)，Nginx的每個(gè)模塊都有可能去處理某個(gè)請(qǐng)求，但是同一個(gè)處理請(qǐng)求只能由一個(gè)模塊來(lái)完成。

二、Nginx的進(jìn)程模型

在工作方式上，Nginx分為單工作進(jìn)程和多工作進(jìn)程兩種模式。在單工作進(jìn)程模式下，除主進(jìn)程外，還有一個(gè)工作進(jìn)程，工作進(jìn)程是單線程的；在多工作進(jìn)程模式下，每個(gè)工作進(jìn)程包含多個(gè)線程。Nginx默認(rèn)為單工作進(jìn)程模式。

Nginx在啟動(dòng)后，會(huì)有一個(gè)master進(jìn)程和多個(gè)worker進(jìn)程。

master進(jìn)程：管理進(jìn)程

master進(jìn)程主要用來(lái)管理worker進(jìn)程，具體包括如下4個(gè)主要功能：

• （1）接收來(lái)自外界的信號(hào)。
• （2）向各worker進(jìn)程發(fā)送信號(hào)。
• （3）監(jiān)控woker進(jìn)程的運(yùn)行狀態(tài)。
• （4）當(dāng)woker進(jìn)程退出后（異常情況下），會(huì)自動(dòng)重新啟動(dòng)新的woker進(jìn)程。

用戶交互接口：master進(jìn)程充當(dāng)整個(gè)進(jìn)程組與用戶的交互接口，同時(shí)對(duì)進(jìn)程進(jìn)行監(jiān)護(hù)。它不需要處理網(wǎng)絡(luò)事件，不負(fù)責(zé)業(yè)務(wù)的執(zhí)行，只會(huì)通過(guò)管理worker進(jìn)程來(lái)實(shí)現(xiàn)重啟服務(wù)、平滑升級(jí)、更換日志文件、配置文件實(shí)時(shí)生效等功能。

重啟work進(jìn)程：我們要控制nginx，只需要通過(guò)kill向master進(jìn)程發(fā)送信號(hào)就行了。比如kill -HUP pid，則是告訴nginx，從容地重啟nginx，我們一般用這個(gè)信號(hào)來(lái)重啟nginx，或重新加載配置，因?yàn)槭菑娜莸刂貑?，因此服?wù)是不中斷的。

master進(jìn)程在接收到HUP信號(hào)后是怎么做的呢？

1）、首先master進(jìn)程在接到信號(hào)后，會(huì)先重新加載配置文件，然后再啟動(dòng)新的worker進(jìn)程，并向所有老的worker進(jìn)程發(fā)送信號(hào)，告訴他們可以光榮退休了。

2）、新的worker在啟動(dòng)后，就開(kāi)始接收新的請(qǐng)求，而老的worker在收到來(lái)自master的信號(hào)后，就不再接收新的請(qǐng)求，并且在當(dāng)前進(jìn)程中的所有未處理完的請(qǐng)求處理完成后，再退出。

直接給master進(jìn)程發(fā)送信號(hào)，這是比較傳統(tǒng)的操作方式，nginx在0.8版本之后，引入了一系列命令行參數(shù)，來(lái)方便我們管理。比如，./nginx -s reload，就是來(lái)重啟nginx，./nginx -s stop，就是來(lái)停止nginx的運(yùn)行。如何做到的呢？我們還是拿reload來(lái)說(shuō)，我們看到，執(zhí)行命令時(shí)，我們是啟動(dòng)一個(gè)新的nginx進(jìn)程，而新的nginx進(jìn)程在解析到reload參數(shù)后，就知道我們的目的是控制nginx來(lái)重新加載配置文件了，它會(huì)向master進(jìn)程發(fā)送信號(hào)，然后接下來(lái)的動(dòng)作，就和我們直接向master進(jìn)程發(fā)送信號(hào)一樣了。

worker進(jìn)程：處理請(qǐng)求

而基本的網(wǎng)絡(luò)事件，則是放在worker進(jìn)程中來(lái)處理了。多個(gè)worker進(jìn)程之間是對(duì)等的，他們同等競(jìng)爭(zhēng)來(lái)自客戶端的請(qǐng)求，各進(jìn)程互相之間是獨(dú)立的。一個(gè)請(qǐng)求，只可能在一個(gè)worker進(jìn)程中處理，一個(gè)worker進(jìn)程，不可能處理其它進(jìn)程的請(qǐng)求。worker進(jìn)程的個(gè)數(shù)是可以設(shè)置的，一般我們會(huì)設(shè)置與機(jī)器cpu核數(shù)一致，這里面的原因與nginx的進(jìn)程模型以及事件處理模型是分不開(kāi)的。

worker進(jìn)程之間是平等的，每個(gè)進(jìn)程，處理請(qǐng)求的機(jī)會(huì)也是一樣的。當(dāng)我們提供80端口的http服務(wù)時(shí)，一個(gè)連接請(qǐng)求過(guò)來(lái)，每個(gè)進(jìn)程都有可能處理這個(gè)連接，怎么做到的呢？

Nginx采用異步非阻塞的方式來(lái)處理網(wǎng)絡(luò)事件，類似于Libevent，具體過(guò)程如下：

1）接收請(qǐng)求：首先，每個(gè)worker進(jìn)程都是從master進(jìn)程fork過(guò)來(lái)，在master進(jìn)程建立好需要listen的socket（listenfd）之后，然后再fork出多個(gè)worker進(jìn)程。所有worker進(jìn)程的listenfd會(huì)在新連接到來(lái)時(shí)變得可讀，每個(gè)work進(jìn)程都可以去accept這個(gè)socket（listenfd）。當(dāng)一個(gè)client連接到來(lái)時(shí)，所有accept的work進(jìn)程都會(huì)受到通知，但只有一個(gè)進(jìn)程可以accept成功，其它的則會(huì)accept失敗。為保證只有一個(gè)進(jìn)程處理該連接，Nginx提供了一把共享鎖accept_mutex來(lái)保證同一時(shí)刻只有一個(gè)work進(jìn)程在accept連接。所有worker進(jìn)程在注冊(cè)listenfd讀事件前搶accept_mutex，搶到互斥鎖的那個(gè)進(jìn)程注冊(cè)listenfd讀事件，在讀事件里調(diào)用accept接受該連接。

2）處理請(qǐng)求：當(dāng)一個(gè)worker進(jìn)程在accept這個(gè)連接之后，就開(kāi)始讀取請(qǐng)求，解析請(qǐng)求，處理請(qǐng)求，產(chǎn)生數(shù)據(jù)后，再返回給客戶端，最后才斷開(kāi)連接，這樣一個(gè)完整的請(qǐng)求就是這樣的了。

我們可以看到，一個(gè)請(qǐng)求，完全由worker進(jìn)程來(lái)處理，而且只在一個(gè)worker進(jìn)程中處理。worker進(jìn)程之間是平等的，每個(gè)進(jìn)程，處理請(qǐng)求的機(jī)會(huì)也是一樣的。

nginx的進(jìn)程模型，可以由下圖來(lái)表示：

三、Nginx為啥性能高－多進(jìn)程IO模型

3.1nginx采用多進(jìn)程模型好處

首先，對(duì)于每個(gè)worker進(jìn)程來(lái)說(shuō)，獨(dú)立的進(jìn)程，不需要加鎖，所以省掉了鎖帶來(lái)的開(kāi)銷(xiāo)，同時(shí)在編程以及問(wèn)題查找時(shí)，也會(huì)方便很多。

其次，采用獨(dú)立的進(jìn)程，可以讓互相之間不會(huì)影響，一個(gè)進(jìn)程退出后，其它進(jìn)程還在工作，服務(wù)不會(huì)中斷，master進(jìn)程則很快啟動(dòng)新的worker進(jìn)程。當(dāng)然，worker進(jìn)程的異常退出，肯定是程序有bug了，異常退出，會(huì)導(dǎo)致當(dāng)前worker上的所有請(qǐng)求失敗，不過(guò)不會(huì)影響到所有請(qǐng)求，所以降低了風(fēng)險(xiǎn)。

3.2nginx多進(jìn)程事件模型：異步非阻塞

雖然nginx采用多worker的方式來(lái)處理請(qǐng)求，每個(gè)worker里面只有一個(gè)主線程，那能夠處理的并發(fā)數(shù)很有限啊，多少個(gè)worker就能處理多少個(gè)并發(fā)，何來(lái)高并發(fā)呢？非也，這就是nginx的高明之處，nginx采用了異步非阻塞的方式來(lái)處理請(qǐng)求，也就是說(shuō)，nginx是可以同時(shí)處理成千上萬(wàn)個(gè)請(qǐng)求的。一個(gè)worker進(jìn)程可以同時(shí)處理的請(qǐng)求數(shù)只受限于內(nèi)存大小，而且在架構(gòu)設(shè)計(jì)上，不同的worker進(jìn)程之間處理并發(fā)請(qǐng)求時(shí)幾乎沒(méi)有同步鎖的限制，worker進(jìn)程通常不會(huì)進(jìn)入睡眠狀態(tài)，因此，當(dāng)Nginx上的進(jìn)程數(shù)與CPU核心數(shù)相等時(shí)（最好每一個(gè)worker進(jìn)程都綁定特定的CPU核心），進(jìn)程間切換的代價(jià)是最小的。

而apache的常用工作方式（apache也有異步非阻塞版本，但因其與自帶某些模塊沖突，所以不常用），每個(gè)進(jìn)程在一個(gè)時(shí)刻只處理一個(gè)請(qǐng)求，因此，當(dāng)并發(fā)數(shù)上到幾千時(shí)，就同時(shí)有幾千的進(jìn)程在處理請(qǐng)求了。這對(duì)操作系統(tǒng)來(lái)說(shuō)，是個(gè)不小的挑戰(zhàn)，進(jìn)程帶來(lái)的內(nèi)存占用非常大，進(jìn)程的上下文切換帶來(lái)的cpu開(kāi)銷(xiāo)很大，自然性能就上不去了，而這些開(kāi)銷(xiāo)完全是沒(méi)有意義的。

為什么nginx可以采用異步非阻塞的方式來(lái)處理呢，或者異步非阻塞到底是怎么回事呢？

我們先回到原點(diǎn)，看看一個(gè)請(qǐng)求的完整過(guò)程:首先，請(qǐng)求過(guò)來(lái)，要建立連接，然后再接收數(shù)據(jù)，接收數(shù)據(jù)后，再發(fā)送數(shù)據(jù)。

具體到系統(tǒng)底層，就是讀寫(xiě)事件，而當(dāng)讀寫(xiě)事件沒(méi)有準(zhǔn)備好時(shí)，必然不可操作，如果不用非阻塞的方式來(lái)調(diào)用，那就得阻塞調(diào)用了，事件沒(méi)有準(zhǔn)備好，那就只能等了，等事件準(zhǔn)備好了，你再繼續(xù)吧。阻塞調(diào)用會(huì)進(jìn)入內(nèi)核等待，cpu就會(huì)讓出去給別人用了，對(duì)單線程的worker來(lái)說(shuō)，顯然不合適，當(dāng)網(wǎng)絡(luò)事件越多時(shí)，大家都在等待呢，cpu空閑下來(lái)沒(méi)人用，cpu利用率自然上不去了，更別談高并發(fā)了。好吧，你說(shuō)加進(jìn)程數(shù)，這跟apache的線程模型有什么區(qū)別，注意，別增加無(wú)謂的上下文切換。所以，在nginx里面，最忌諱阻塞的系統(tǒng)調(diào)用了。不要阻塞，那就非阻塞嘍。非阻塞就是，事件沒(méi)有準(zhǔn)備好，馬上返回EAGAIN，告訴你，事件還沒(méi)準(zhǔn)備好呢，你慌什么，過(guò)會(huì)再來(lái)吧。好吧，你過(guò)一會(huì)，再來(lái)檢查一下事件，直到事件準(zhǔn)備好了為止，在這期間，你就可以先去做其它事情，然后再來(lái)看看事件好了沒(méi)。雖然不阻塞了，但你得不時(shí)地過(guò)來(lái)檢查一下事件的狀態(tài)，你可以做更多的事情了，但帶來(lái)的開(kāi)銷(xiāo)也是不小的。

nginx支持的事件模型如下（nginx的wiki）:

Nginx支持如下處理連接的方法（I/O復(fù)用方法），這些方法可以通過(guò)use指令指定。

select– 標(biāo)準(zhǔn)方法。如果當(dāng)前平臺(tái)沒(méi)有更有效的方法，它是編譯時(shí)默認(rèn)的方法。你可以使用配置參數(shù) –with-select_module 和 –without-select_module 來(lái)啟用或禁用這個(gè)模塊。

poll– 標(biāo)準(zhǔn)方法。如果當(dāng)前平臺(tái)沒(méi)有更有效的方法，它是編譯時(shí)默認(rèn)的方法。你可以使用配置參數(shù) –with-poll_module 和 –without-poll_module 來(lái)啟用或禁用這個(gè)模塊。

kqueue– 高效的方法，使用于 FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X. 使用雙處理器的MacOS X系統(tǒng)使用kqueue可能會(huì)造成內(nèi)核崩潰。

epoll – 高效的方法，使用于Linux內(nèi)核2.6版本及以后的系統(tǒng)。在某些發(fā)行版本中，如SuSE 8.2, 有讓2.4版本的內(nèi)核支持epoll的補(bǔ)丁。

rtsig – 可執(zhí)行的實(shí)時(shí)信號(hào)，使用于Linux內(nèi)核版本2.2.19以后的系統(tǒng)。默認(rèn)情況下整個(gè)系統(tǒng)中不能出現(xiàn)大于1024個(gè)POSIX實(shí)時(shí)(排隊(duì))信號(hào)。這種情況 對(duì)于高負(fù)載的服務(wù)器來(lái)說(shuō)是低效的；所以有必要通過(guò)調(diào)節(jié)內(nèi)核參數(shù) /proc/sys/kernel/rtsig-max 來(lái)增加隊(duì)列的大小?？墒菑腖inux內(nèi)核版本2.6.6-mm2開(kāi)始， 這個(gè)參數(shù)就不再使用了，并且對(duì)于每個(gè)進(jìn)程有一個(gè)獨(dú)立的信號(hào)隊(duì)列，這個(gè)隊(duì)列的大小可以用 RLIMIT_SIGPENDING 參數(shù)調(diào)節(jié)。當(dāng)這個(gè)隊(duì)列過(guò)于擁塞，nginx就放棄它并且開(kāi)始使用 poll 方法來(lái)處理連接直到恢復(fù)正常。

/dev/poll – 高效的方法，使用于 Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+.

eventport – 高效的方法，使用于 Solaris 10. 為了防止出現(xiàn)內(nèi)核崩潰的問(wèn)題， 有必要安裝這個(gè) 安全補(bǔ)丁。

在linux下面，只有epoll是高效的方法

下面再來(lái)看看epoll到底是如何高效的，Epoll是Linux內(nèi)核為處理大批量句柄而作了改進(jìn)的poll。要使用epoll只需要這三個(gè)系統(tǒng)調(diào)用：epoll_create(2)， epoll_ctl(2)， epoll_wait(2)。它是在2.5.44內(nèi)核中被引進(jìn)的(epoll(4) is a new API introduced in Linux kernel 2.5.44)，在2.6內(nèi)核中得到廣泛應(yīng)用。

epoll的優(yōu)點(diǎn)

支持一個(gè)進(jìn)程打開(kāi)大數(shù)目的socket描述符(FD)

select 最不能忍受的是一個(gè)進(jìn)程所打開(kāi)的FD是有一定限制的，由FD_SETSIZE設(shè)置，默認(rèn)值是2048。對(duì)于那些需要支持的上萬(wàn)連接數(shù)目的IM服務(wù)器來(lái)說(shuō)顯 然太少了。這時(shí)候你一是可以選擇修改這個(gè)宏然后重新編譯內(nèi)核，不過(guò)資料也同時(shí)指出這樣會(huì)帶來(lái)網(wǎng)絡(luò)效率的下降，二是可以選擇多進(jìn)程的解決方案(傳統(tǒng)的 Apache方案)，不過(guò)雖然linux上面創(chuàng)建進(jìn)程的代價(jià)比較小，但仍舊是不可忽視的，加上進(jìn)程間數(shù)據(jù)同步遠(yuǎn)比不上線程間同步的高效，所以也不是一種完 美的方案。不過(guò) epoll則沒(méi)有這個(gè)限制，它所支持的FD上限是最大可以打開(kāi)文件的數(shù)目，這個(gè)數(shù)字一般遠(yuǎn)大于2048,舉個(gè)例子,在1GB內(nèi)存的機(jī)器上大約是10萬(wàn)左 右，具體數(shù)目可以cat /proc/sys/fs/file-max察看,一般來(lái)說(shuō)這個(gè)數(shù)目和系統(tǒng)內(nèi)存關(guān)系很大。

IO效率不隨FD數(shù)目增加而線性下降

傳統(tǒng)的select/poll另一個(gè)致命弱點(diǎn)就是當(dāng)你擁有一個(gè)很大的socket集合，不過(guò)由于網(wǎng)絡(luò)延時(shí)，任一時(shí)間只有部分的socket是”活躍”的，但 是select/poll每次調(diào)用都會(huì)線性掃描全部的集合，導(dǎo)致效率呈現(xiàn)線性下降。但是epoll不存在這個(gè)問(wèn)題，它只會(huì)對(duì)”活躍”的socket進(jìn)行操 作—這是因?yàn)樵趦?nèi)核實(shí)現(xiàn)中epoll是根據(jù)每個(gè)fd上面的callback函數(shù)實(shí)現(xiàn)的。那么，只有”活躍”的socket才會(huì)主動(dòng)的去調(diào)用 callback函數(shù)，其他idle狀態(tài)socket則不會(huì)，在這點(diǎn)上，epoll實(shí)現(xiàn)了一個(gè)”偽”AIO，因?yàn)檫@時(shí)候推動(dòng)力在os內(nèi)核。在一些 benchmark中，如果所有的socket基本上都是活躍的—比如一個(gè)高速LAN環(huán)境，epoll并不比select/poll有什么效率，相 反，如果過(guò)多使用epoll_ctl,效率相比還有稍微的下降。但是一旦使用idle connections模擬WAN環(huán)境,epoll的效率就遠(yuǎn)在select/poll之上了。

使用mmap加速內(nèi)核與用戶空間的消息傳遞

這 點(diǎn)實(shí)際上涉及到epoll的具體實(shí)現(xiàn)了。無(wú)論是select,poll還是epoll都需要內(nèi)核把FD消息通知給用戶空間，如何避免不必要的內(nèi)存拷貝就很 重要，在這點(diǎn)上，epoll是通過(guò)內(nèi)核于用戶空間mmap同一塊內(nèi)存實(shí)現(xiàn)的。而如果你想我一樣從2.5內(nèi)核就關(guān)注epoll的話，一定不會(huì)忘記手工 mmap這一步的。

內(nèi)核微調(diào)

這一點(diǎn)其實(shí)不算epoll的優(yōu)點(diǎn)了，而是整個(gè)linux平臺(tái)的優(yōu)點(diǎn)。也許你可以懷疑linux平臺(tái)，但是你無(wú)法回避linux平臺(tái)賦予你微調(diào)內(nèi)核的能力。比如，內(nèi)核TCP/IP協(xié) 議棧使用內(nèi)存池管理sk_buff結(jié)構(gòu)，那么可以在運(yùn)行時(shí)期動(dòng)態(tài)調(diào)整這個(gè)內(nèi)存pool(skb_head_pool)的大小— 通過(guò)echo XXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函數(shù)的第2個(gè)參數(shù)(TCP完成3次握手 的數(shù)據(jù)包隊(duì)列長(zhǎng)度)，也可以根據(jù)你平臺(tái)內(nèi)存大小動(dòng)態(tài)調(diào)整。更甚至在一個(gè)數(shù)據(jù)包面數(shù)目巨大但同時(shí)每個(gè)數(shù)據(jù)包本身大小卻很小的特殊系統(tǒng)上嘗試最新的NAPI網(wǎng)卡驅(qū)動(dòng)架構(gòu)。

(epoll內(nèi)容，參考epoll_互動(dòng)百科)

推薦設(shè)置worker的個(gè)數(shù)為cpu的核數(shù)，在這里就很容易理解了，更多的worker數(shù)，只會(huì)導(dǎo)致進(jìn)程來(lái)競(jìng)爭(zhēng)cpu資源了，從而帶來(lái)不必要的上下文切換。而且，nginx為了更好的利用多核特性，提供了cpu親緣性的綁定選項(xiàng)，我們可以將某一個(gè)進(jìn)程綁定在某一個(gè)核上，這樣就不會(huì)因?yàn)檫M(jìn)程的切換帶來(lái)cache的失效。像這種小的優(yōu)化在nginx中非常常見(jiàn)，同時(shí)也說(shuō)明了nginx作者的苦心孤詣。比如，nginx在做4個(gè)字節(jié)的字符串比較時(shí)，會(huì)將4個(gè)字符轉(zhuǎn)換成一個(gè)int型，再作比較，以減少cpu的指令數(shù)等等。

代碼來(lái)總結(jié)一下nginx的事件處理模型：

while (true) {
    for t in run_tasks:
        t.handler();
    update_time(&now);
    timeout = ETERNITY;
    for t in wait_tasks: /* sorted already */
        if (t.time <= now) {
            t.timeout_handler();
        } else {
            timeout = t.time - now;
            break;
        }
    nevents = poll_function(events, timeout);
    for i in nevents:
        task t;
        if (events[i].type == READ) {
            t.handler = read_handler;
        } else { /* events[i].type == WRITE */
            t.handler = write_handler;
        }
        run_tasks_add(t);
}

四、Nginx+FastCGI運(yùn)行原理

4.1什么是 FastCGI

FastCGI是一個(gè)可伸縮地、高速地在HTTP server和動(dòng)態(tài)腳本語(yǔ)言間通信的接口。多數(shù)流行的HTTP server都支持FastCGI，包括Apache、Nginx和lighttpd等。同時(shí)，F(xiàn)astCGI也被許多腳本語(yǔ)言支持，其中就有PHP。

FastCGI是從CGI發(fā)展改進(jìn)而來(lái)的。傳統(tǒng)CGI接口方式的主要缺點(diǎn)是性能很差，因?yàn)槊看蜨TTP服務(wù)器遇到動(dòng)態(tài)程序時(shí)都需要重新啟動(dòng)腳本解析器來(lái)執(zhí)行解析，然后將結(jié)果返回給HTTP服務(wù)器。這在處理高并發(fā)訪問(wèn)時(shí)幾乎是不可用的。另外傳統(tǒng)的CGI接口方式安全性也很差，現(xiàn)在已經(jīng)很少使用了。

FastCGI接口方式采用C/S結(jié)構(gòu)，可以將HTTP服務(wù)器和腳本解析服務(wù)器分開(kāi)，同時(shí)在腳本解析服務(wù)器上啟動(dòng)一個(gè)或者多個(gè)腳本解析守護(hù)進(jìn)程。當(dāng)HTTP服務(wù)器每次遇到動(dòng)態(tài)程序時(shí)，可以將其直接交付給FastCGI進(jìn)程來(lái)執(zhí)行，然后將得到的結(jié)果返回給瀏覽器。這種方式可以讓HTTP服務(wù)器專一地處理靜態(tài)請(qǐng)求或者將動(dòng)態(tài)腳本服務(wù)器的結(jié)果返回給客戶端，這在很大程度上提高了整個(gè)應(yīng)用系統(tǒng)的性能。

4.2Nginx+FastCGI運(yùn)行原理

Nginx不支持對(duì)外部程序的直接調(diào)用或者解析，所有的外部程序（包括PHP）必須通過(guò)FastCGI接口來(lái)調(diào)用。FastCGI接口在Linux下是socket（這個(gè)socket可以是文件socket，也可以是ip socket）。

wrapper：為了調(diào)用CGI程序，還需要一個(gè)FastCGI的wrapper（wrapper可以理解為用于啟動(dòng)另一個(gè)程序的程序），這個(gè)wrapper綁定在某個(gè)固定socket上，如端口或者文件socket。當(dāng)Nginx將CGI請(qǐng)求發(fā)送給這個(gè)socket的時(shí)候，通過(guò)FastCGI接口，wrapper接收到請(qǐng)求，然后Fork(派生）出一個(gè)新的線程，這個(gè)線程調(diào)用解釋器或者外部程序處理腳本并讀取返回?cái)?shù)據(jù)；接著，wrapper再將返回的數(shù)據(jù)通過(guò)FastCGI接口，沿著固定的socket傳遞給Nginx；最后，Nginx將返回的數(shù)據(jù)（html頁(yè)面或者圖片）發(fā)送給客戶端。這就是Nginx+FastCGI的整個(gè)運(yùn)作過(guò)程，如圖1-3所示。

所以，我們首先需要一個(gè)wrapper，這個(gè)wrapper需要完成的工作：

• 通過(guò)調(diào)用fastcgi（庫(kù)）的函數(shù)通過(guò)socket和ningx通信（讀寫(xiě)socket是fastcgi內(nèi)部實(shí)現(xiàn)的功能，對(duì)wrapper是非透明的）
• 調(diào)度thread，進(jìn)行fork和kill
• 和application（php）進(jìn)行通信

4.3spawn-fcgi與PHP-FPM

FastCGI接口方式在腳本解析服務(wù)器上啟動(dòng)一個(gè)或者多個(gè)守護(hù)進(jìn)程對(duì)動(dòng)態(tài)腳本進(jìn)行解析，這些進(jìn)程就是FastCGI進(jìn)程管理器，或者稱為FastCGI引擎。spawn-fcgi與PHP-FPM就是支持PHP的兩個(gè)FastCGI進(jìn)程管理器。因此HTTPServer完全解放出來(lái)，可以更好地進(jìn)行響應(yīng)和并發(fā)處理。

spawn-fcgi與PHP-FPM的異同：

1）spawn-fcgi是HTTP服務(wù)器lighttpd的一部分，目前已經(jīng)獨(dú)立成為一個(gè)項(xiàng)目，一般與lighttpd配合使用來(lái)支持PHP。但是ligttpd的spwan-fcgi在高并發(fā)訪問(wèn)的時(shí)候，會(huì)出現(xiàn)內(nèi)存泄漏甚至自動(dòng)重啟FastCGI的問(wèn)題。即：PHP腳本處理器當(dāng)機(jī)，這個(gè)時(shí)候如果用戶訪問(wèn)的話，可能就會(huì)出現(xiàn)白頁(yè)(即PHP不能被解析或者出錯(cuò))。

2）Nginx是個(gè)輕量級(jí)的HTTP server，必須借助第三方的FastCGI處理器才可以對(duì)PHP進(jìn)行解析，因此其實(shí)這樣看來(lái)nginx是非常靈活的，它可以和任何第三方提供解析的處理器實(shí)現(xiàn)連接從而實(shí)現(xiàn)對(duì)PHP的解析(在nginx.conf中很容易設(shè)置)。nginx也可以使用spwan-fcgi(需要一同安裝lighttpd，但是需要為nginx避開(kāi)端口，一些較早的blog有這方面安裝的教程)，但是由于spawn-fcgi具有上面所述的用戶逐漸發(fā)現(xiàn)的缺陷，現(xiàn)在慢慢減少用nginx+spawn-fcgi組合了。

由于spawn-fcgi的缺陷，現(xiàn)在出現(xiàn)了第三方(目前已經(jīng)加入到PHP core中)的PHP的FastCGI處理器PHP-FPM，它和spawn-fcgi比較起來(lái)有如下優(yōu)點(diǎn)：

由于它是作為PHP的patch補(bǔ)丁來(lái)開(kāi)發(fā)的，安裝的時(shí)候需要和php源碼一起編譯，也就是說(shuō)編譯到php core中了，因此在性能方面要優(yōu)秀一些；

同時(shí)它在處理高并發(fā)方面也優(yōu)于spawn-fcgi，至少不會(huì)自動(dòng)重啟fastcgi處理器。因此，推薦使用Nginx+PHP/PHP-FPM這個(gè)組合對(duì)PHP進(jìn)行解析。

相對(duì)Spawn-FCGI，PHP-FPM在CPU和內(nèi)存方面的控制都更勝一籌，而且前者很容易崩潰，必須用crontab進(jìn)行監(jiān)控，而PHP-FPM則沒(méi)有這種煩惱。

FastCGI 的主要優(yōu)點(diǎn)是把動(dòng)態(tài)語(yǔ)言和HTTP Server分離開(kāi)來(lái)，所以Nginx與PHP/PHP-FPM經(jīng)常被部署在不同的服務(wù)器上，以分擔(dān)前端Nginx服務(wù)器的壓力，使Nginx專一處理靜態(tài)請(qǐng)求和轉(zhuǎn)發(fā)動(dòng)態(tài)請(qǐng)求，而PHP/PHP-FPM服務(wù)器專一解析PHP動(dòng)態(tài)請(qǐng)求。

4.4Nginx+PHP-FPM

PHP-FPM是管理FastCGI的一個(gè)管理器，它作為PHP的插件存在，在安裝PHP要想使用PHP-FPM時(shí)在老php的老版本（php5.3.3之前）就需要把PHP-FPM以補(bǔ)丁的形式安裝到PHP中，而且PHP要與PHP-FPM版本一致，這是必須的）

PHP-FPM其實(shí)是PHP源代碼的一個(gè)補(bǔ)丁，旨在將FastCGI進(jìn)程管理整合進(jìn)PHP包中。必須將它patch到你的PHP源代碼中，在編譯安裝PHP后才可以使用。

PHP5.3.3已經(jīng)集成php-fpm了，不再是第三方的包了。PHP-FPM提供了更好的PHP進(jìn)程管理方式，可以有效控制內(nèi)存和進(jìn)程、可以平滑重載PHP配置，比spawn-fcgi具有更多優(yōu)點(diǎn)，所以被PHP官方收錄了。在./configure的時(shí)候帶 –enable-fpm參數(shù)即可開(kāi)啟PHP-FPM。

fastcgi已經(jīng)在php5.3.5的core中了，不必在configure時(shí)添加 --enable-fastcgi了。老版本如php5.2的需要加此項(xiàng)。

當(dāng)我們安裝Nginx和PHP-FPM完后，配置信息：

PHP-FPM的默認(rèn)配置php-fpm.conf：

     listen_address  127.0.0.1:9000 #這個(gè)表示php的fastcgi進(jìn)程監(jiān)聽(tīng)的ip地址以及端口

      start_servers

      min_spare_servers

      max_spare_servers

      Nginx配置運(yùn)行php：編輯nginx.conf加入如下語(yǔ)句：

      location ~ \.php$ {
            root html;   
            fastcgi_pass 127.0.0.1:9000; 指定了fastcgi進(jìn)程偵聽(tīng)的端口,nginx就是通過(guò)這里與php交互的
            fastcgi_index index.php;
            include fastcgi_params;
             fastcgi_param SCRIPT_FILENAME   /usr/local/nginx/html$fastcgi_script_name;
    }

Nginx通過(guò)location指令，將所有以php為后綴的文件都交給127.0.0.1:9000來(lái)處理，而這里的IP地址和端口就是FastCGI進(jìn)程監(jiān)聽(tīng)的IP地址和端口。

其整體工作流程：

1)、FastCGI進(jìn)程管理器php-fpm自身初始化，啟動(dòng)主進(jìn)程php-fpm和啟動(dòng)start_servers個(gè)CGI 子進(jìn)程。主進(jìn)程php-fpm主要是管理fastcgi子進(jìn)程，監(jiān)聽(tīng)9000端口。fastcgi子進(jìn)程等待來(lái)自Web Server的連接。

2)、當(dāng)客戶端請(qǐng)求到達(dá)Web Server Nginx是時(shí)，Nginx通過(guò)location指令，將所有以php為后綴的文件都交給127.0.0.1:9000來(lái)處理，即Nginx通過(guò)location指令，將所有以php為后綴的文件都交給127.0.0.1:9000來(lái)處理。

3）FastCGI進(jìn)程管理器PHP-FPM選擇并連接到一個(gè)子進(jìn)程CGI解釋器。Web server將CGI環(huán)境變量和標(biāo)準(zhǔn)輸入發(fā)送到FastCGI子進(jìn)程。

4)、FastCGI子進(jìn)程完成處理后將標(biāo)準(zhǔn)輸出和錯(cuò)誤信息從同一連接返回Web Server。當(dāng)FastCGI子進(jìn)程關(guān)閉連接時(shí)，請(qǐng)求便告處理完成。

5)、FastCGI子進(jìn)程接著等待并處理來(lái)自FastCGI進(jìn)程管理器（運(yùn)行在 WebServer中）的下一個(gè)連接。

五、Nginx+PHP正確配置

一般web都做統(tǒng)一入口：把PHP請(qǐng)求都發(fā)送到同一個(gè)文件上，然后在此文件里通過(guò)解析「REQUEST_URI」實(shí)現(xiàn)路由。

Nginx配置文件分為好多塊，常見(jiàn)的從外到內(nèi)依次是「http」、「server」、「location」等等，缺省的繼承關(guān)系是從外到內(nèi)，也就是說(shuō)內(nèi)層塊會(huì)自動(dòng)獲取外層塊的值作為缺省值。

例如：

server {
    listen 80;
    server_name foo.com;
    root /path;
    location / {
        index index.html index.htm index.php;
        if (!-e $request_filename) {
            rewrite . /index.php last;
        }
    }
    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME /path$fastcgi_script_name;
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
    }
}

1. 不應(yīng)該在location 模塊定義index

一旦未來(lái)需要加入新的「location」，必然會(huì)出現(xiàn)重復(fù)定義的「index」指令，這是因?yàn)槎鄠€(gè)「location」是平級(jí)的關(guān)系，不存在繼承，此時(shí)應(yīng)該在「server」里定義「index」，借助繼承關(guān)系，「index」指令在所有的「location」中都能生效。

1. 使用try_files

接下來(lái)看看「if」指令，說(shuō)它是大家誤解最深的Nginx指令毫不為過(guò)：

if (!-e $request_filename) {
    rewrite . /index.php last;
}

很多人喜歡用「if」指令做一系列的檢查，不過(guò)這實(shí)際上是「try_files」指令的職責(zé)：

try_files $uri $uri/ /index.php;

除此以外，初學(xué)者往往會(huì)認(rèn)為「if」指令是內(nèi)核級(jí)的指令，但是實(shí)際上它是rewrite模塊的一部分，加上Nginx配置實(shí)際上是聲明式的，而非過(guò)程式的，所以當(dāng)其和非rewrite模塊的指令混用時(shí)，結(jié)果可能會(huì)非你所愿。

3）fastcgi_params」配置文件：

include fastcgi_params;

Nginx有兩份fastcgi配置文件，分別是「fastcgi_params」和「fastcgi.conf」，它們沒(méi)有太大的差異，唯一的區(qū)別是后者比前者多了一行「SCRIPT_FILENAME」的定義：

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

注意：和fastcgi_script_name 之間沒(méi)有 /。

原本Nginx只有「fastcgi_params」，后來(lái)發(fā)現(xiàn)很多人在定義「SCRIPT_FILENAME」時(shí)使用了硬編碼的方式，于是為了規(guī)范用法便引入了「fastcgi.conf」。

不過(guò)這樣的話就產(chǎn)生一個(gè)疑問(wèn)：為什么一定要引入一個(gè)新的配置文件，而不是修改舊的配置文件？這是因?yàn)椤竑astcgi_param」指令是數(shù)組型的，和普通指令相同的是：內(nèi)層替換外層；和普通指令不同的是：當(dāng)在同級(jí)多次使用的時(shí)候，是新增而不是替換。換句話說(shuō)，如果在同級(jí)定義兩次「SCRIPT_FILENAME」，那么它們都會(huì)被發(fā)送到后端，這可能會(huì)導(dǎo)致一些潛在的問(wèn)題，為了避免此類情況，便引入了一個(gè)新的配置文件。

此外，我們還需要考慮一個(gè)安全問(wèn)題：在PHP開(kāi)啟「cgi.fix_pathinfo」的情況下，PHP可能會(huì)把錯(cuò)誤的文件類型當(dāng)作PHP文件來(lái)解析。如果Nginx和PHP安裝在同一臺(tái)服務(wù)器上的話，那么最簡(jiǎn)單的解決方法是用「try_files」指令做一次過(guò)濾：

try_files $uri =404;

依照前面的分析，給出一份改良后的版本，是不是比開(kāi)始的版本清爽了很多：

server {
    listen 80;
    server_name foo.com;
    root /path;
    index index.html index.htm index.php;
    location / {
        try_files $uri $uri/ /index.php;
    }
    location ~ \.php$ {
       try_files $uri =404;
       include fastcgi.conf;
       fastcgi_pass 127.0.0.1:9000;
   }
}

六、Nginx優(yōu)化

6.1編譯安裝過(guò)程優(yōu)化

1）減小Nginx編譯后的文件大小

在編譯Nginx時(shí)，默認(rèn)以debug模式進(jìn)行，而在debug模式下會(huì)插入很多跟蹤和ASSERT之類的信息，編譯完成后，一個(gè)Nginx要有好幾兆字節(jié)。而在編譯前取消Nginx的debug模式，編譯完成后Nginx只有幾百千字節(jié)。因此可以在編譯之前，修改相關(guān)源碼，取消debug模式。具體方法如下：

在Nginx源碼文件被解壓后，找到源碼目錄下的auto/cc/gcc文件，在其中找到如下幾行：

 # debug  
CFLAGS=”$CFLAGS -g”

注釋掉或刪掉這兩行，即可取消debug模式。

2）為特定的CPU指定CPU類型編譯優(yōu)化

在編譯Nginx時(shí)，默認(rèn)的GCC編譯參數(shù)是“-O”，要優(yōu)化GCC編譯，可以使用以下兩個(gè)參數(shù)：

--with-cc-opt='-O3' 
--with-cpu-opt=CPU  #為特定的 CPU 編譯，有效的值包括：

pentium, pentiumpro, pentium3, # pentium4, athlon, opteron, amd64, sparc32, sparc64, ppc64

要確定CPU類型，可以通過(guò)如下命令：#cat /proc/cpuinfo | grep 'model name'

6.2利用TCMalloc優(yōu)化Nginx的性能

TCMalloc的全稱為T(mén)hread-Caching Malloc，是谷歌開(kāi)發(fā)的開(kāi)源工具google-perftools中的一個(gè)成員。與標(biāo)準(zhǔn)的glibc庫(kù)的Malloc相比，TCMalloc庫(kù)在內(nèi)存分配效率和速度上要高很多，這在很大程度上提高了服務(wù)器在高并發(fā)情況下的性能，從而降低了系統(tǒng)的負(fù)載。下面簡(jiǎn)單介紹如何為Nginx添加TCMalloc庫(kù)支持。

要安裝TCMalloc庫(kù)，需要安裝libunwind（32位操作系統(tǒng)不需要安裝）和google-perftools兩個(gè)軟件包，libunwind庫(kù)為基于64位CPU和操作系統(tǒng)的程序提供了基本函數(shù)調(diào)用鏈和函數(shù)調(diào)用寄存器功能。下面介紹利用TCMalloc優(yōu)化Nginx的具體操作過(guò)程。

1).安裝libunwind庫(kù)

可以從http://download.savannah.gnu.org/releases/libunwind下載相應(yīng)的libunwind版本，這里下載的是libunwind-0.99-alpha.tar.gz。安裝過(guò)程如下：

#tar zxvf libunwind-0.99-alpha.tar.gz  
# cd libunwind-0.99-alpha/  
#CFLAGS=-fPIC ./configure  
#make CFLAGS=-fPIC  
#make CFLAGS=-fPIC install

2).安裝google-perftools

可以從http://google-perftools.googlecode.com下載相應(yīng)的google-perftools版本，這里下載的是google-perftools-1.8.tar.gz。安裝過(guò)程如下：

[root@localhost home]#tar zxvf google-perftools-1.8.tar.gz  
[root@localhost home]#cd google-perftools-1.8/  
[root@localhost google-perftools-1.8]# ./configure  
[root@localhost google-perftools-1.8]#make && make install  
[root@localhost google-perftools-1.8]#echo '/usr/
local/lib' > /etc/ld.so.conf.d/usr_local_lib.conf  
[root@localhost google-perftools-1.8]# ldconfig

至此，google-perftools安裝完成。

3)重新編譯Nginx

為了使Nginx支持google-perftools，需要在安裝過(guò)程中添加“–with-google_perftools_module”選項(xiàng)重新編譯Nginx。安裝代碼如下：

[[email protected]]#./configure \  
>--with-google_perftools_module --with-http_stub_status_module  --prefix=/opt/nginx  
[root@localhost nginx-0.7.65]#make  
[root@localhost nginx-0.7.65]#make install

到這里Nginx安裝完成。

4)為google-perftools添加線程目錄

創(chuàng)建一個(gè)線程目錄，這里將文件放在/tmp/tcmalloc下。操作如下：

[root@localhost home]#mkdir /tmp/tcmalloc  
[root@localhost home]#chmod 0777 /tmp/tcmalloc

5)修改Nginx主配置文件

修改nginx.conf文件，在pid這行的下面添加如下代碼：

#pid        logs/nginx.pid;  
google_perftools_profiles /tmp/tcmalloc;

接著，重啟Nginx即可完成google-perftools的加載。

6)驗(yàn)證運(yùn)行狀態(tài)

為了驗(yàn)證google-perftools已經(jīng)正常加載，可通過(guò)如下命令查看：

[root@ localhost home]# lsof -n | grep tcmalloc  
nginx      2395 nobody   9w  REG    8,8       0    1599440 /tmp/tcmalloc.2395  
nginx      2396 nobody   11w REG   8,8       0    1599443 /tmp/tcmalloc.2396  
nginx      2397 nobody   13w REG  8,8        0    1599441  /tmp/tcmalloc.2397  
nginx     2398 nobody    15w REG  8,8     0    1599442 /tmp/tcmalloc.2398

由于在Nginx配置文件中設(shè)置worker_processes的值為4，因此開(kāi)啟了4個(gè)Nginx線程，每個(gè)線程會(huì)有一行記錄。每個(gè)線程文件后面的數(shù)字值就是啟動(dòng)的Nginx的pid值。

至此，利用TCMalloc優(yōu)化Nginx的操作完成。

6.3Nginx內(nèi)核參數(shù)優(yōu)化

內(nèi)核參數(shù)的優(yōu)化，主要是在Linux系統(tǒng)中針對(duì)Nginx應(yīng)用而進(jìn)行的系統(tǒng)內(nèi)核參數(shù)優(yōu)化。

下面給出一個(gè)優(yōu)化實(shí)例以供參考：

net.ipv4.tcp_max_tw_buckets = 6000
net.ipv4.ip_local_port_range = 1024 65000  
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_syncookies = 1
net.core.somaxconn = 262144
net.core.netdev_max_backlog = 262144
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_fin_timeout = 1
net.ipv4.tcp_keepalive_time = 30

將上面的內(nèi)核參數(shù)值加入/etc/sysctl.conf文件中，然后執(zhí)行如下命令使之生效：

[root@ localhost home]#/sbin/sysctl -p

下面對(duì)實(shí)例中選項(xiàng)的含義進(jìn)行介紹

TCP參數(shù)設(shè)置：

net.ipv4.tcp_max_tw_buckets ：選項(xiàng)用來(lái)設(shè)定timewait的數(shù)量，默認(rèn)是180 000，這里設(shè)為6000。
net.ipv4.ip_local_port_range:選項(xiàng)用來(lái)設(shè)定允許系統(tǒng)打開(kāi)的端口范圍。在高并發(fā)情況否則端口號(hào)會(huì)不夠用。當(dāng)NGINX充當(dāng)代理時(shí)，每個(gè)到上游服務(wù)器的連接都使用一個(gè)短暫或臨時(shí)端口。
net.ipv4.tcp_tw_recycle:選項(xiàng)用于設(shè)置啟用timewait快速回收.
net.ipv4.tcp_tw_reuse:選項(xiàng)用于設(shè)置開(kāi)啟重用，允許將TIME-WAIT sockets重新用于新的TCP連接。
net.ipv4.tcp_syncookies:選項(xiàng)用于設(shè)置開(kāi)啟SYN Cookies，當(dāng)出現(xiàn)SYN等待隊(duì)列溢出時(shí)，啟用cookies進(jìn)行處理。
net.ipv4.tcp_max_orphans:選項(xiàng)用于設(shè)定系統(tǒng)中最多有多少個(gè)TCP套接字不被關(guān)聯(lián)到任何一個(gè)用戶文件句柄上。如果超過(guò)這個(gè)數(shù)字，孤立連接將立即被復(fù)位并打印出警告信息。這個(gè)限制只是為了防止簡(jiǎn)單的DoS攻擊。不能過(guò)分依靠這個(gè)限制甚至人為減小這個(gè)值，更多的情況下應(yīng)該增加這個(gè)值。
net.ipv4.tcp_max_syn_backlog:選項(xiàng)用于記錄那些尚未收到客戶端確認(rèn)信息的連接請(qǐng)求的最大值。對(duì)于有128MB內(nèi)存的系統(tǒng)而言，此參數(shù)的默認(rèn)值是1024，對(duì)小內(nèi)存的系統(tǒng)則是128。
net.ipv4.tcp_synack_retries參數(shù)的值決定了內(nèi)核放棄連接之前發(fā)送SYN+ACK包的數(shù)量。
net.ipv4.tcp_syn_retries選項(xiàng)表示在內(nèi)核放棄建立連接之前發(fā)送SYN包的數(shù)量。
net.ipv4.tcp_fin_timeout選項(xiàng)決定了套接字保持在FIN-WAIT-2狀態(tài)的時(shí)間。默認(rèn)值是60秒。正確設(shè)置這個(gè)值非常重要，有時(shí)即使一個(gè)負(fù)載很小的Web服務(wù)器，也會(huì)出現(xiàn)大量的死套接字而產(chǎn)生內(nèi)存溢出的風(fēng)險(xiǎn)。
net.ipv4.tcp_syn_retries選項(xiàng)表示在內(nèi)核放棄建立連接之前發(fā)送SYN包的數(shù)量。

如果發(fā)送端要求關(guān)閉套接字
net.ipv4.tcp_fin_timeout選項(xiàng)決定了套接字保持在FIN-WAIT-2狀態(tài)的時(shí)間。接收端可以出錯(cuò)并永遠(yuǎn)不關(guān)閉連接，甚至意外宕機(jī)。
net.ipv4.tcp_fin_timeout的默認(rèn)值是60秒。需要注意的是，即使一個(gè)負(fù)載很小的Web服務(wù)器，也會(huì)出現(xiàn)因?yàn)榇罅康乃捞捉幼侄a(chǎn)生內(nèi)存溢出的風(fēng)險(xiǎn)。FIN-WAIT-2的危險(xiǎn)性比FIN-WAIT-1要小，因?yàn)樗疃嘀荒芟?.5KB的內(nèi)存，但是其生存期長(zhǎng)些。
net.ipv4.tcp_keepalive_time選項(xiàng)表示當(dāng)keepalive啟用的時(shí)候，TCP發(fā)送keepalive消息的頻度。默認(rèn)值是2（單位是小時(shí)）。

緩沖區(qū)隊(duì)列：

net.core.somaxconn:選項(xiàng)的默認(rèn)值是128， 這個(gè)參數(shù)用于調(diào)節(jié)系統(tǒng)同時(shí)發(fā)起的tcp連接數(shù)，在高并發(fā)的請(qǐng)求中，默認(rèn)的值可能會(huì)導(dǎo)致鏈接超時(shí)或者重傳，因此，需要結(jié)合并發(fā)請(qǐng)求數(shù)來(lái)調(diào)節(jié)此值。
由NGINX可接受的數(shù)目決定。默認(rèn)值通常很低，但可以接受，因?yàn)镹GINX 接收連接非?？?，但如果網(wǎng)站流量大時(shí)，就應(yīng)該增加這個(gè)值。內(nèi)核日志中的錯(cuò)誤消息會(huì)提醒這個(gè)值太小了，把值改大，直到錯(cuò)誤提示消失。
注意：如果設(shè)置這個(gè)值大于512，相應(yīng)地也要改變NGINX listen指令的backlog參數(shù)。

net.core.netdev_max_backlog:選項(xiàng)表示當(dāng)每個(gè)網(wǎng)絡(luò)接口接收數(shù)據(jù)包的速率比內(nèi)核處理這些包的速率快時(shí)，允許發(fā)送到隊(duì)列的數(shù)據(jù)包的最大數(shù)目。

6.4PHP-FPM的優(yōu)化

如果您高負(fù)載網(wǎng)站使用PHP-FPM管理FastCGI，這些技巧也許對(duì)您有用

1）增加FastCGI進(jìn)程數(shù)

把PHP FastCGI子進(jìn)程數(shù)調(diào)到100或以上，在4G內(nèi)存的服務(wù)器上200就可以建議通過(guò)壓力測(cè)試獲取最佳值。

2）增加 PHP-FPM打開(kāi)文件描述符的限制

標(biāo)簽rlimit_files用于設(shè)置PHP-FPM對(duì)打開(kāi)文件描述符的限制，默認(rèn)值為1024。這個(gè)標(biāo)簽的值必須和Linux內(nèi)核打開(kāi)文件數(shù)關(guān)聯(lián)起來(lái)，例如，要將此值設(shè)置為65 535，就必須在Linux命令行執(zhí)行“ulimit -HSn 65536”。

然后 增加 PHP-FPM打開(kāi)文件描述符的限制:

# vi /path/to/php-fpm.conf
找到“<valuename='rlimit_files'>1024</value>”
把1024更改為 4096或者更高.
重啟 PHP-FPM
ulimit -n 要調(diào)整為65536甚至更大。如何調(diào)這個(gè)參數(shù)，可以參考網(wǎng)上的一些文章。
命令行下執(zhí)行 ulimit -n 65536即可修改。如果不能修改，需要設(shè)置  /etc/security/limits.conf，加入
* hard nofile65536
* soft nofile 65536

3）適當(dāng)增加max_requests

標(biāo)簽max_requests指明了每個(gè)children最多處理多少個(gè)請(qǐng)求后便會(huì)被關(guān)閉，默認(rèn)的設(shè)置是500。

 <value name='max_requests'> 500 </value>

6.5nginx.conf的參數(shù)優(yōu)化

nginx要開(kāi)啟的進(jìn)程數(shù) 一般等于cpu的總核數(shù) 其實(shí)一般情況下開(kāi)4個(gè)或8個(gè)就可以。每個(gè)nginx進(jìn)程消耗的內(nèi)存10兆的模樣worker_cpu_affinity，僅適用于linux，使用該選項(xiàng)可以綁定worker進(jìn)程和CPU（2.4內(nèi)核的機(jī)器用不了）

假如是8 cpu 分配如下：

 worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000
00100000 01000000 10000000

nginx可以使用多個(gè)worker進(jìn)程，原因如下：

to use SMP 
to decrease latency when workers blockend on disk I/O 
to limit number of connections per process when select()/poll() is
used The worker_processes and worker_connections from the event sections
allows you to calculate maxclients value: k max_clients = worker_processes * worker_connections
worker_rlimit_nofile 102400;

每個(gè)nginx進(jìn)程打開(kāi)文件描述符最大數(shù)目 配置要和系統(tǒng)的單進(jìn)程打開(kāi)文件數(shù)一致,linux 2.6內(nèi)核下開(kāi)啟文件打開(kāi)數(shù)為65535，worker_rlimit_nofile就相應(yīng)應(yīng)該填寫(xiě)65535 nginx調(diào)度時(shí)分配請(qǐng)求到進(jìn)程并不是那么的均衡，假如超過(guò)會(huì)返回502錯(cuò)誤。我這里寫(xiě)的大一點(diǎn)

use epoll

Nginx使用了最新的epoll（Linux 2.6內(nèi)核）和kqueue（freebsd）網(wǎng)絡(luò)I/O模型，而Apache則使用的是傳統(tǒng)的select模型。

處理大量的連接的讀寫(xiě)，Apache所采用的select網(wǎng)絡(luò)I/O模型非常低效。在高并發(fā)服務(wù)器中，輪詢I/O是最耗時(shí)間的操作 目前Linux下能夠承受高并發(fā)

訪問(wèn)的Squid、Memcached都采用的是epoll網(wǎng)絡(luò)I/O模型。

worker_processes

NGINX工作進(jìn)程數(shù)（默認(rèn)值是1）。在大多數(shù)情況下，一個(gè)CPU內(nèi)核運(yùn)行一個(gè)工作進(jìn)程最好，建議將這個(gè)指令設(shè)置成自動(dòng)就可以。有時(shí)可能想增大這個(gè)值，比如當(dāng)工作進(jìn)程需要做大量的磁盤(pán)I/O。

worker_connections 65535

每個(gè)工作進(jìn)程允許最大的同時(shí)連接數(shù) （Maxclient = work_processes *　worker_connections）

keepalive_timeout 75

keepalive超時(shí)時(shí)間

這里需要注意官方的一句話：
The parameters can differ from each other. Line Keep-Alive:
timeout=time understands Mozilla and Konqueror. MSIE itself shuts
keep-alive connection approximately after 60 seconds.

client_header_buffer_size 16k

large_client_header_buffers 4 32k

客戶請(qǐng)求頭緩沖大小

nginx默認(rèn)會(huì)用client_header_buffer_size這個(gè)buffer來(lái)讀取header值，如果header過(guò)大，它會(huì)使用large_client_header_buffers來(lái)讀取

如果設(shè)置過(guò)小HTTP頭/Cookie過(guò)大 會(huì)報(bào)400 錯(cuò)誤 nginx 400 bad request

求行如果超過(guò)buffer，就會(huì)報(bào)HTTP 414錯(cuò)誤(URI Too Long) nginx接受最長(zhǎng)的HTTP頭部大小必須比其中一個(gè)buffer大，否則就會(huì)報(bào)400的HTTP錯(cuò)誤(Bad Request)。

open_file_cache max 102400

使用字段:http, server, location 這個(gè)指令指定緩存是否啟用,如果啟用,將記錄文件以下信息: ·打開(kāi)的文件描述符,大小信息和修改時(shí)間. ·存在的目錄信息. ·在搜索文件過(guò)程中的錯(cuò)誤信息 -- 沒(méi)有這個(gè)文件,無(wú)法正確讀取,參考o(jì)pen_file_cache_errors 指令選項(xiàng):

·max - 指定緩存的最大數(shù)目,如果緩存溢出,最長(zhǎng)使用過(guò)的文件(LRU)將被移除

例: open_file_cache max=1000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on;

open_file_cache_errors

語(yǔ)法:open_file_cache_errors on | off 默認(rèn)值:open_file_cache_errors off 使用字段:http, server, location 這個(gè)指令指定是否在搜索一個(gè)文件是記錄cache錯(cuò)誤.

open_file_cache_min_uses

語(yǔ)法:open_file_cache_min_uses number 默認(rèn)值:open_file_cache_min_uses 1 使用字段:http, server, location 這個(gè)指令指定了在open_file_cache指令無(wú)效的參數(shù)中一定的時(shí)間范圍內(nèi)可以使用的最小文件數(shù),如 果使用更大的值,文件描述符在cache中總是打開(kāi)狀態(tài).

open_file_cache_valid

語(yǔ)法:open_file_cache_valid time 默認(rèn)值:open_file_cache_valid 60 使用字段:http, server, location 這個(gè)指令指定了何時(shí)需要檢查open_file_cache中緩存項(xiàng)目的有效信息.

開(kāi)啟gzip
gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_types text/plain application/x-javascript text/css

application/xml;
gzip_vary on;

緩存靜態(tài)文件：

location ~* ^.+\.(swf|gif|png|jpg|js|css)$ {
    root /usr/local/ku6/ktv/show.ku6.com/;
    expires 1m;
}

響應(yīng)緩沖區(qū)：比如我們Nginx+Tomcat 代理訪問(wèn)JS無(wú)法完全加載，這幾個(gè)參數(shù)影響。

proxy_buffer_size 128k;
proxy_buffers   32 128k;
proxy_busy_buffers_size 128k;

Nginx在代理了相應(yīng)服務(wù)后或根據(jù)我們配置的UpStream和location來(lái)獲取相應(yīng)的文件，首先文件會(huì)被解析到nginx的內(nèi)存或者臨時(shí)文件目錄中，然后由nginx再來(lái)響應(yīng)。那么當(dāng)proxy_buffers和proxy_buffer_size以及proxy_busy_buffers_size 都太小時(shí)，會(huì)將內(nèi)容根據(jù)nginx的配置生成到臨時(shí)文件中，但是臨時(shí)文件的大小也有默認(rèn)值。所以當(dāng)這四個(gè)值都過(guò)小時(shí)就會(huì)導(dǎo)致部分文件只加載一部分。所以要根據(jù)我們的服務(wù)器情況適當(dāng)?shù)恼{(diào)整proxy_buffers和proxy_buffer_size以及proxy_busy_buffers_size、proxy_temp_file_write_size。具體幾個(gè)參數(shù)的詳細(xì)如下：

proxy_buffers   32 128k;  設(shè)置了32個(gè)緩存區(qū)，每個(gè)的大小是128k
proxy_buffer_size 128k; 每個(gè)緩存區(qū)的大小是128k，當(dāng)兩個(gè)值不一致時(shí)沒(méi)有找到具體哪個(gè)有效，建議和上面的設(shè)置一致。
proxy_busy_buffers_size 128k;設(shè)置使用中的緩存區(qū)的大小，控制傳輸至客戶端的緩存的最大
proxy_temp_file_write_size 緩存文件的大小

優(yōu)化訪問(wèn)日志

記錄每個(gè)請(qǐng)求會(huì)消耗CPU和I/O周期，一種降低這種影響的方式是緩沖訪問(wèn)日志。使用緩沖，而不是每條日志記錄都單獨(dú)執(zhí)行寫(xiě)操作，NGINX會(huì)緩沖一連串的日志記錄，使用單個(gè)操作把它們一起寫(xiě)到文件中。

要啟用訪問(wèn)日志的緩存，就涉及到在access_log指令中buffer=size這個(gè)參數(shù)。當(dāng)緩沖區(qū)達(dá)到size值時(shí)，NGINX會(huì)把緩沖區(qū)的內(nèi)容寫(xiě)到日志中。讓NGINX在指定的一段時(shí)間后寫(xiě)緩存，就包含flush=time參數(shù)。當(dāng)兩個(gè)參數(shù)都設(shè)置了，當(dāng)下個(gè)日志條目超出緩沖區(qū)值或者緩沖區(qū)中日志條目存留時(shí)間超過(guò)設(shè)定的時(shí)間值，NGINX都會(huì)將條目寫(xiě)入日志文件。當(dāng)工作進(jìn)程重新打開(kāi)它的日志文件或退出時(shí)，也會(huì)記錄下來(lái)。要完全禁用訪問(wèn)日志記錄的功能，將access_log 指令設(shè)置成off參數(shù)。

限流

你可以設(shè)置多個(gè)限制，防止用戶消耗太多的資源，避免影響系統(tǒng)性能和用戶體驗(yàn)及安全。以下是相關(guān)的指令：

limit_conn and limit_conn_zone：NGINX接受客戶連接的數(shù)量限制，例如單個(gè)IP地址的連接。設(shè)置這些指令可以防止單個(gè)用戶打開(kāi)太多的連接，消耗超出自己的資源。

limit_rate：傳輸?shù)娇蛻舳隧憫?yīng)速度的限制（每個(gè)打開(kāi)多個(gè)連接的客戶消耗更多的帶寬）。設(shè)置這個(gè)限制防止系統(tǒng)過(guò)載，確保所有客戶端更均勻的服務(wù)質(zhì)量。

limit_req and limit_req_zone：NGINX處理請(qǐng)求的速度限制，與limit_rate有相同的功能?？梢蕴岣甙踩裕绕涫菍?duì)登錄頁(yè)面，通過(guò)對(duì)用戶限制請(qǐng)求速率設(shè)置一個(gè)合理的值，避免太慢的程序覆蓋你的應(yīng)用請(qǐng)求（比如DDoS攻擊)。

max_conns：上游配置塊中服務(wù)器指令參數(shù)。在上游服務(wù)器組中單個(gè)服務(wù)器可接受最大并發(fā)數(shù)量。使用這個(gè)限制防止上游服務(wù)器過(guò)載。設(shè)置值為0（默認(rèn)值）表示沒(méi)有限制。

queue (NGINX Plus) ：創(chuàng)建一個(gè)隊(duì)列，用來(lái)存放在上游服務(wù)器中超出他們最大max_cons限制數(shù)量的請(qǐng)求。這個(gè)指令可以設(shè)置隊(duì)列請(qǐng)求的最大值，還可以選擇設(shè)置在錯(cuò)誤返回之前最大等待時(shí)間（默認(rèn)值是60秒）。如果忽略這個(gè)指令，請(qǐng)求不會(huì)放入隊(duì)列。

七、錯(cuò)誤排查

所有錯(cuò)誤的都在錯(cuò)誤文件error.log里面

1、400 bad request錯(cuò)誤的原因和解決辦法

配置nginx.conf相關(guān)設(shè)置如下.
client_header_buffer_size 16k;
large_client_header_buffers 4 64k;
根據(jù)具體情況調(diào)整，一般適當(dāng)調(diào)整值就可以。

2、Nginx出現(xiàn)的413 Request Entity Too Large錯(cuò)誤

這個(gè)錯(cuò)誤一般在上傳文件的時(shí)候會(huì)出現(xiàn)，

        client intended to send too large body: 23937077 bytes, client: 10.45.142.41, server: localhost, request

        服務(wù)器拒絕處理當(dāng)前請(qǐng)求，因?yàn)樵撜?qǐng)求提交的實(shí)體數(shù)據(jù)大小超過(guò)了服務(wù)器愿意或者能夠處理的范圍。此種情況下，服務(wù)器可以關(guān)閉連接以免客戶端繼續(xù)發(fā)送此請(qǐng)求。
  如果這個(gè)狀況是臨時(shí)的，服務(wù)器應(yīng)當(dāng)返回一個(gè) Retry-After 的響應(yīng)頭，以告知客戶端可以在多少時(shí)間以后重新嘗試。

         編輯Nginx主配置文件Nginx.conf，找到http{}段，添加

        client_max_body_size 10m; //設(shè)置多大根據(jù)自己的需求作調(diào)整.

        如果運(yùn)行php的話這個(gè)大小client_max_body_size要和php.ini中的如下值的最大值一致或者稍大，這樣就不會(huì)因?yàn)樘峤粩?shù)據(jù)大         小不一致出現(xiàn)的錯(cuò)誤。

        post_max_size = 10M
        upload_max_filesize = 2M

1、Nginx 502 Bad Gateway：

作為網(wǎng)關(guān)或者代理工作的服務(wù)器嘗試執(zhí)行請(qǐng)求時(shí)，從上游服務(wù)器接收到無(wú)效的響應(yīng)。

常見(jiàn)原因：

1、后端服務(wù)掛了的情況,直接502 （nginx error日志：connect() failed (111: Connection refused) ）

2、后端服務(wù)在重啟

實(shí)例：將后端服務(wù)關(guān)掉，然后向nginx發(fā)送請(qǐng)求后端接口，nginx日志可以看到502錯(cuò)誤。

如果nginx+php出現(xiàn)502, 錯(cuò)誤分析：

php-cgi進(jìn)程數(shù)不夠用、php執(zhí)行時(shí)間長(zhǎng)（mysql慢）、或者是php-cgi進(jìn)程死掉，都會(huì)出現(xiàn)502錯(cuò)誤

一般來(lái)說(shuō)Nginx 502 Bad Gateway和php-fpm.conf的設(shè)置有關(guān)，而Nginx 504 Gateway Time-out則是與nginx.conf的設(shè)置有關(guān)

1）、查看當(dāng)前的PHP FastCGI進(jìn)程數(shù)是否夠用：

netstat -anpo | grep 'php-cgi' | wc -l

如果實(shí)際使用的“FastCGI進(jìn)程數(shù)”接近預(yù)設(shè)的“FastCGI進(jìn)程數(shù)”，那么，說(shuō)明“FastCGI進(jìn)程數(shù)”不夠用，需要增大。

2）、部分PHP程序的執(zhí)行時(shí)間超過(guò)了Nginx的等待時(shí)間，可以適當(dāng)增加

nginx.conf配置文件中FastCGI的timeout時(shí)間，例如：

http {
    ......
    fastcgi_connect_timeout 300;
    fastcgi_send_timeout 300;
    fastcgi_read_timeout 300;
    ......
}

2、504 Gateway Timeout :

nginx作為網(wǎng)關(guān)或者代理工作的服務(wù)器嘗試執(zhí)行請(qǐng)求時(shí)，未能及時(shí)從上游服務(wù)器（URI標(biāo)識(shí)出的服務(wù)器，例如HTTP、FTP、LDAP）收到響應(yīng)。

常見(jiàn)原因：
該接口太耗時(shí)，后端服務(wù)接收到請(qǐng)求，開(kāi)始執(zhí)行，未能在設(shè)定時(shí)間返回?cái)?shù)據(jù)給nginx
后端服務(wù)器整體負(fù)載太高，接受到請(qǐng)求之后，由于線程繁忙，未能安排給請(qǐng)求的接口，導(dǎo)致未能在設(shè)定時(shí)間返回?cái)?shù)據(jù)給nginx

3、413 Request Entity Too Large

解決：增大client_max_body_size
client_max_body_size:指令指定允許客戶端連接的最大請(qǐng)求實(shí)體大小,它出現(xiàn)在請(qǐng)求頭部的Content-Length字段. 如果請(qǐng)求大于指定的值,客戶端將收到一個(gè)'Request Entity Too Large' (413)錯(cuò)誤. 記住,瀏覽器并不知道怎樣顯示這個(gè)錯(cuò)誤.
php.ini中增大
post_max_size 和upload_max_filesize

4、 Ngnix error.log出現(xiàn)：upstream sent too big header while reading response header from upstream錯(cuò)誤

1)如果是nginx反向代理

proxy是nginx作為client轉(zhuǎn)發(fā)時(shí)使用的，如果header過(guò)大，超出了默認(rèn)的1k，就會(huì)引發(fā)上述的upstream sent too big header （說(shuō)白了就是nginx把外部請(qǐng)求給后端server，后端server返回的header 太大nginx處理不過(guò)來(lái)就導(dǎo)致了。

server {
        listen       80;
        server_name  *.xywy.com ;

        large_client_header_buffers 4 16k;

        location / {

          #添加這3行 
           proxy_buffer_size 64k;
           proxy_buffers   32 32k;
           proxy_busy_buffers_size 128k;

           proxy_set_header Host $host;
           proxy_set_header X-Real-IP       $remote_addr;
           proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;

    }

}

\2) 如果是 nginx+PHPcgi

錯(cuò)誤帶有 upstream: 'fastcgi://127.0.0.1:9000'。就該 

  多加：

  fastcgi_buffer_size 128k;
  fastcgi_buffers 4 128k;

server {
        listen       80;
        server_name  ddd.com;
        index index.html index.htm index.php;
   
        client_header_buffer_size 128k;
        large_client_header_buffers 4 128k;
        proxy_buffer_size 64k;
        proxy_buffers 8 64k;
        fastcgi_buffer_size 128k;
        fastcgi_buffers 4 128k;

        location / {

          ......

        }

}

八、 Nginx的php漏洞

漏洞介紹：nginx是一款高性能的web服務(wù)器，使用非常廣泛，其不僅經(jīng)常被用作反向代理，也可以非常好的支持PHP的運(yùn)行。80sec發(fā)現(xiàn)其中存在一個(gè)較為嚴(yán)重的安全問(wèn)題，默認(rèn)情況下可能導(dǎo)致服務(wù)器錯(cuò)誤的將任何類型的文件以PHP的方式進(jìn)行解析，這將導(dǎo)致嚴(yán)重的安全問(wèn)題，使得惡意的攻擊者可能攻陷支持php的nginx服務(wù)器。

漏洞分析：nginx默認(rèn)以cgi的方式支持php的運(yùn)行，譬如在配置文件當(dāng)中可以以

location ~ .php$ {
    root html;
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
    include fastcgi_params;
}

的方式支持對(duì)php的解析，location對(duì)請(qǐng)求進(jìn)行選擇的時(shí)候會(huì)使用URI環(huán)境變量進(jìn)行選擇，其中傳遞到后端Fastcgi的關(guān)鍵變量SCRIPT_FILENAME由nginx生成的fastcgi_script_name是直接由URI環(huán)境變量控制的，這里就是產(chǎn)生問(wèn)題的點(diǎn)。而為了較好的支持PATH_INFO的提取，在PHP的配置選項(xiàng)里存在cgi.fix_pathinfo選項(xiàng)，其目的是為了從SCRIPT_FILENAME里取出真正的腳本名。

那么假設(shè)存在一個(gè)/80sec.php

將會(huì)得到一個(gè)URI/80sec.jpg/80sec.php

經(jīng)過(guò)location指令，該請(qǐng)求將會(huì)交給后端的fastcgi處理，nginx為其設(shè)置環(huán)境變量SCRIPT_FILENAME，內(nèi)容為

/scripts/80sec.jpg/80sec.php

而在其他的webserver如lighttpd當(dāng)中，我們發(fā)現(xiàn)其中的SCRIPT_FILENAME被正確的設(shè)置為

/scripts/80sec.jpg

所以不存在此問(wèn)題。

后端的fastcgi在接受到該選項(xiàng)時(shí)，會(huì)根據(jù)fix_pathinfo配置決定是否對(duì)SCRIPT_FILENAME進(jìn)行額外的處理，一般情況下如果不對(duì)fix_pathinfo進(jìn)行設(shè)置將影響使用PATH_INFO進(jìn)行路由選擇的應(yīng)用，所以該選項(xiàng)一般配置開(kāi)啟。Php通過(guò)該選項(xiàng)之后將查找其中真正的腳本文件名字，查找的方式也是查看文件是否存在，這個(gè)時(shí)候?qū)⒎蛛x出SCRIPT_FILENAME和PATH_INFO分別為

/scripts/80sec.jpg和80sec.php

最后，以/scripts/80sec.jpg作為此次請(qǐng)求需要執(zhí)行的腳本，攻擊者就可以實(shí)現(xiàn)讓nginx以php來(lái)解析任何類型的文件了。

POC：訪問(wèn)一個(gè)nginx來(lái)支持php的站點(diǎn)，在一個(gè)任何資源的文件如robots.txt后面加上/80sec.php，這個(gè)時(shí)候你可以看到如下的區(qū)別：

訪問(wèn)http://www.80sec.com/robots.txtTTP/1.1 200 OK

Server: nginx/0.6.32
Date: Thu, 20 May 2010 10:05:30 GMT
Content-Type: text/plain
Content-Length: 18
Last-Modified: Thu, 20 May 2010 06:26:34 GMT
Connection: keep-alive
Keep-Alive: timeout=20
Accept-Ranges: bytes

訪問(wèn)訪問(wèn)http://www.80sec.com/robots.txt/80sec.php

HTTP/1.1 200 OK
Server: nginx/0.6.32
Date: Thu, 20 May 2010 10:06:49 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=20
X-Powered-By: PHP/5.2.6

其中的Content-Type的變化說(shuō)明了后端負(fù)責(zé)解析的變化，該站點(diǎn)就可能存在漏洞。

漏洞廠商：http://www.nginx.org

解決方案：

我們已經(jīng)嘗試聯(lián)系官方，但是此前你可以通過(guò)以下的方式來(lái)減少損失

關(guān)閉cgi.fix_pathinfo為0

或者

if ( $fastcgi_script_name ~ ..*/.*php ) {
  return 403;
}

?? 歡迎加入小哈的星球，你將獲得: 專屬的項(xiàng)目實(shí)戰(zhàn) / 1v1 提問(wèn) / Java 學(xué)習(xí)路線 / 學(xué)習(xí)打卡 / 每月贈(zèng)書(shū) / 社群討論

• 新項(xiàng)目:《從零手?jǐn)]：仿小紅書(shū)（微服務(wù)架構(gòu)）》 正在持續(xù)爆肝中，基于 Spring Cloud Alibaba + Spring Boot 3.x + JDK 17..., 點(diǎn)擊查看項(xiàng)目介紹；
• 《從零手?jǐn)]：前后端分離博客項(xiàng)目（全棧開(kāi)發(fā)）》 2期已完結(jié),演示鏈接：http://116.62.199.48/;

截止目前，累計(jì)輸出 54w+ 字，講解圖 2330+ 張，還在持續(xù)爆肝中.. 后續(xù)還會(huì)上新更多項(xiàng)目，目標(biāo)是將 Java 領(lǐng)域典型的項(xiàng)目都整一波，如秒殺系統(tǒng), 在線商城, IM 即時(shí)通訊，Spring Cloud Alibaba 等等，戳我加入學(xué)習(xí)，解鎖全部項(xiàng)目，已有1900+小伙伴加入

    
       

        

         

          

           
1. 我的私密學(xué)習(xí)小圈子~
           
2. 效率爆表！EasyExcel合并單元格這樣實(shí)現(xiàn)才是yyds
           
3. 微服務(wù)之間的數(shù)據(jù)依賴問(wèn)題，該如何解決？
           
4. 使用 Java + WebSocket 實(shí)現(xiàn)簡(jiǎn)單實(shí)時(shí)雙人協(xié)同 pk 答題
           

          
         
        
       

最近面試BAT，整理一份面試資料《Java面試BATJ通關(guān)手冊(cè)》，覆蓋了Java核心技術(shù)、JVM、Java并發(fā)、SSM、微服務(wù)、數(shù)據(jù)庫(kù)、數(shù)據(jù)結(jié)構(gòu)等等。
獲取方式：點(diǎn)“在看”，關(guān)注公眾號(hào)并回復(fù) Java 領(lǐng)取，更多內(nèi)容陸續(xù)奉上。
PS：因公眾號(hào)平臺(tái)更改了推送規(guī)則，如果不想錯(cuò)過(guò)內(nèi)容，記得讀完點(diǎn)一下“在看”，加個(gè)“星標(biāo)”，這樣每次新文章推送才會(huì)第一時(shí)間出現(xiàn)在你的訂閱列表里。
點(diǎn)“在看”支持小哈呀，謝謝啦