深入理解Nginx（模塊開(kāi)發(fā)與架構(gòu)解析）

深入理解Nginx模塊開(kāi)發(fā)與架構(gòu)解析目錄\h第一部分Nginx能幫我們做什么\h第1章研究Nginx前的準(zhǔn)備工作\h1.1Nginx是什么\h1.2為什么選擇Nginx\h1.3準(zhǔn)備工作\h1.4編譯安裝Nginx\h1.5configure詳解\h1.6Nginx的命令行控制\h1.7小結(jié)\h第2章Nginx的配置\h2.1運(yùn)行中的Nginx進(jìn)程間的關(guān)系\h2.2Nginx配置的通用語(yǔ)法\h2.3Nginx服務(wù)的基本配置\h2.4用HTTP核心模塊配置一個(gè)靜態(tài)Web服務(wù)器\h2.5用HTTPproxymodule配置一個(gè)反向代理服務(wù)器\h2.6小結(jié)\h第二部分如何編寫(xiě)HTTP模塊\h第3章開(kāi)發(fā)一個(gè)簡(jiǎn)單的HTTP模塊\h3.1如何調(diào)用HTTP模塊\h3.2準(zhǔn)備工作\h3.3如何將自己的HTTP模塊編譯進(jìn)Nginx\h3.4HTTP模塊的數(shù)據(jù)結(jié)構(gòu)\h3.5定義自己的HTTP模塊\h3.6處理用戶請(qǐng)求\h3.7發(fā)送響應(yīng)\h3.8將磁盤文件作為包體發(fā)送\h3.9用C++語(yǔ)言編寫(xiě)HTTP模塊\h3.10小結(jié)\h第4章配置、error日志和請(qǐng)求上下文\h4.1http配置項(xiàng)的使用場(chǎng)景\h4.2怎樣使用http配置\h4.3HTTP配置模型\h4.4error日志的用法\h4.5請(qǐng)求的上下文\h4.6小結(jié)\h第5章訪問(wèn)第三方服務(wù)\h5.1upstream的使用方式\h5.2回調(diào)方法的執(zhí)行場(chǎng)景\h5.3使用upstream的示例\h5.4subrequest的使用方式\h5.5subrequest執(zhí)行過(guò)程中的主要場(chǎng)景\h5.6subrequest使用的例子\h5.7小結(jié)\h第6章開(kāi)發(fā)一個(gè)簡(jiǎn)單的HTTP過(guò)濾模塊\h6.1過(guò)濾模塊的意義\h6.2過(guò)濾模塊的調(diào)用順序\h6.3HTTP過(guò)濾模塊的開(kāi)發(fā)步驟\h6.4HTTP過(guò)濾模塊的簡(jiǎn)單例子\h6.5小結(jié)\h第7章Nginx提供的高級(jí)數(shù)據(jù)結(jié)構(gòu)\h7.1Nginx提供的高級(jí)數(shù)據(jù)結(jié)構(gòu)概述\h7.2ngx_queue_t雙向鏈表\h7.3ngx_array_t動(dòng)態(tài)數(shù)組\h7.4ngx_list_t單向鏈表\h7.5ngx_rbtree_t紅黑樹(shù)\h7.6ngx_radix_tree_t基數(shù)樹(shù)\h7.7支持通配符的散列表\h7.8小結(jié)\h第三部分深入Nginx\h第8章Nginx基礎(chǔ)架構(gòu)\h8.1Web服務(wù)器設(shè)計(jì)中的關(guān)鍵約束\h8.2Nginx的架構(gòu)設(shè)計(jì)\h8.3Nginx框架中的核心結(jié)構(gòu)體ngx_cycle_t\h8.4Nginx啟動(dòng)時(shí)框架的處理流程\h8.5worker進(jìn)程是如何工作的\h8.6master進(jìn)程是如何工作的\h8.7ngx_pool_t內(nèi)存池\h8.8小結(jié)\h第9章事件模塊\h9.1事件處理框架概述\h9.2Nginx事件的定義\h9.3Nginx連接的定義\h9.4ngx_events_module核心模塊\h9.5ngx_event_core_module事件模塊\h9.6epoll事件驅(qū)動(dòng)模塊\h9.7定時(shí)器事件\h9.8事件驅(qū)動(dòng)框架的處理流程\h9.9文件的異步I/O\h9.10TCP協(xié)議與Nginx\h9.11小結(jié)\h第10章HTTP框架的初始化\h10.1HTTP框架概述\h10.2管理HTTP模塊的配置項(xiàng)\h10.3監(jiān)聽(tīng)端口的管理\h10.4server的快速檢索\h10.5location的快速檢索\h10.6HTTP請(qǐng)求的11個(gè)處理階段\h10.7HTTP框架的初始化流程\h10.8小結(jié)\h第11章HTTP框架的執(zhí)行流程\h11.1HTTP框架執(zhí)行流程概述\h11.2新連接建立時(shí)的行為\h11.3第一次可讀事件的處理\h11.4接收HTTP請(qǐng)求行\(zhòng)h11.5接收HTTP頭部\h11.6處理HTTP請(qǐng)求\h11.7subrequest與post請(qǐng)求\h11.8處理HTTP包體\h11.9發(fā)送HTTP響應(yīng)\h11.10結(jié)束HTTP請(qǐng)求\h11.11小結(jié)\h第12章upstream機(jī)制的設(shè)計(jì)與實(shí)現(xiàn)\h12.1upstream機(jī)制概述\h12.2啟動(dòng)upstream\h12.3與上游服務(wù)器建立連接\h12.4發(fā)送請(qǐng)求到上游服務(wù)器\h12.5接收上游服務(wù)器的響應(yīng)頭部\h12.6不轉(zhuǎn)發(fā)響應(yīng)時(shí)的處理流程\h12.7以下游網(wǎng)速優(yōu)先來(lái)轉(zhuǎn)發(fā)響應(yīng)\h12.8以上游網(wǎng)速優(yōu)先來(lái)轉(zhuǎn)發(fā)響應(yīng)\h12.9結(jié)束upstream請(qǐng)求\h12.10小結(jié)\h第13章郵件代理模塊\h13.1郵件代理服務(wù)器的功能\h13.2郵件模塊的處理框架\h13.3初始化請(qǐng)求\h13.4接收并解析客戶端請(qǐng)求\h13.5郵件認(rèn)證\h13.6與上游郵件服務(wù)器間的認(rèn)證交互\h13.7透?jìng)魃嫌梧]件服務(wù)器與客戶端間的流\h13.8小結(jié)\h第14章進(jìn)程間的通信機(jī)制\h14.1概述\h14.2共享內(nèi)存\h14.3原子操作\h14.4Nginx頻道\h14.5信號(hào)\h14.6信號(hào)量\h14.7文件鎖\h14.8互斥鎖\h14.9小結(jié)\h第15章變量\h15.1使用內(nèi)部變量開(kāi)發(fā)模塊\h15.2內(nèi)部變量工作原理\h15.3定義內(nèi)部變量\h15.4外部變量與腳本引擎\h15.5小結(jié)\h第16章slab共享內(nèi)存\h16.1操作slab共享內(nèi)存的方法\h16.2使用slab共享內(nèi)存池的例子\h16.3slab內(nèi)存管理的實(shí)現(xiàn)原理\h16.4小結(jié)注：原文檔電子版（非掃描），需要的請(qǐng)下載本文檔后留言謝謝。第一部分Nginx能幫我們做什么·第1章研究Nginx前的準(zhǔn)備工作·第2章Nginx的配置第1章研究Nginx前的準(zhǔn)備工作2012年，Nginx榮獲年度云計(jì)算開(kāi)發(fā)獎(jiǎng)（2012CloudAwardforDeveloperoftheYear），并成長(zhǎng)為世界第二大Web服務(wù)器。全世界流量最高的前1000名網(wǎng)站中，超過(guò)25%都使用Nginx來(lái)處理海量的互聯(lián)網(wǎng)請(qǐng)求。Nginx已經(jīng)成為業(yè)界高性能Web服務(wù)器的代名詞。那么，什么是Nginx？它有哪些特點(diǎn)？我們選擇Nginx的理由是什么？如何編譯安裝Nginx？這種安裝方式背后隱藏的又是什么樣的思想呢？本章將會(huì)回答上述問(wèn)題。1.1Nginx是什么人們?cè)诹私庑率挛飼r(shí)，往往習(xí)慣通過(guò)類比來(lái)幫助自己理解事物的概貌。那么，我們?cè)趯W(xué)習(xí)Nginx時(shí)也采用同樣的方式，先來(lái)看看Nginx的競(jìng)爭(zhēng)對(duì)手——Apache、Lighttpd、Tomcat、Jetty、IIS，它們都是Web服務(wù)器，或者叫做WWW（WorldWideWeb）服務(wù)器，相應(yīng)地也都具備Web服務(wù)器的基本功能：基于REST架構(gòu)風(fēng)格，以統(tǒng)一資源描述符（UniformResourceIdentifier，URI）或者統(tǒng)一資源定位符（UniformResourceLocator，URL）作為溝通依據(jù)，通過(guò)HTTP為瀏覽器等客戶端程序提供各種網(wǎng)絡(luò)服務(wù)。然而，由于這些Web服務(wù)器在設(shè)計(jì)階段就受到許多局限，例如當(dāng)時(shí)的互聯(lián)網(wǎng)用戶規(guī)模、網(wǎng)絡(luò)帶寬、產(chǎn)品特點(diǎn)等局限，并且各自的定位與發(fā)展方向都不盡相同，使得每一款Web服務(wù)器的特點(diǎn)與應(yīng)用場(chǎng)合都很鮮明。Tomcat和Jetty面向Java語(yǔ)言，先天就是重量級(jí)的Web服務(wù)器，它的性能與Nginx沒(méi)有可比性，這里略過(guò)。IIS只能在Windows操作系統(tǒng)上運(yùn)行。Windows作為服務(wù)器在穩(wěn)定性與其他一些性能上都不如類UNIX操作系統(tǒng)，因此，在需要高性能Web服務(wù)器的場(chǎng)合下，IIS可能會(huì)被“冷落”。Apache的發(fā)展時(shí)期很長(zhǎng)，而且是目前毫無(wú)爭(zhēng)議的世界第一大Web服務(wù)器，圖1-1中是12年來(lái)（2010~2012年）世界Web服務(wù)器的使用排名情況。圖1-1Netcraft對(duì)于644275754個(gè)站點(diǎn)31.4M個(gè)域名Web服務(wù)器使用情況的調(diào)查結(jié)果（2012年3月）從圖1-1中可以看出，Apache目前處于領(lǐng)先地位。Apache有許多優(yōu)點(diǎn)，如穩(wěn)定、開(kāi)源、跨平臺(tái)等，但它出現(xiàn)的時(shí)間太長(zhǎng)了，在它興起的年代，互聯(lián)網(wǎng)的產(chǎn)業(yè)規(guī)模遠(yuǎn)遠(yuǎn)比不上今天，所以它被設(shè)計(jì)成了一個(gè)重量級(jí)的、不支持高并發(fā)的Web服務(wù)器。在Apache服務(wù)器上，如果有數(shù)以萬(wàn)計(jì)的并發(fā)HTTP請(qǐng)求同時(shí)訪問(wèn)，就會(huì)導(dǎo)致服務(wù)器上消耗大量?jī)?nèi)存，操作系統(tǒng)內(nèi)核對(duì)成百上千的Apache進(jìn)程做進(jìn)程間切換也會(huì)消耗大量CPU資源，并導(dǎo)致HTTP請(qǐng)求的平均響應(yīng)速度降低，這些都決定了Apache不可能成為高性能Web服務(wù)器，這也促使了Lighttpd和Nginx的出現(xiàn)。觀察圖1-1中Nginx成長(zhǎng)的曲線，體會(huì)一下Nginx搶占市場(chǎng)時(shí)的“咄咄逼人”吧。Lighttpd和Nginx一樣，都是輕量級(jí)、高性能的Web服務(wù)器，歐美的業(yè)界開(kāi)發(fā)者比較鐘愛(ài)Lighttpd，而國(guó)內(nèi)的公司更青睞Nginx，Lighttpd使用得比較少。在了解了Nginx的競(jìng)爭(zhēng)對(duì)手之后，相信大家對(duì)Nginx也有了直觀感受，下面讓我們來(lái)正式地認(rèn)識(shí)一下Nginx吧。提示Nginx發(fā)音：engine。來(lái)自俄羅斯的IgorSysoev在為RamblerMedia（http://www.rambler.ru/）工作期間，使用C語(yǔ)言開(kāi)發(fā)了Nginx。Nginx作為Web服務(wù)器，一直為俄羅斯著名的門戶網(wǎng)站RamblerMedia提供著出色、穩(wěn)定的服務(wù)。IgorSysoev將Nginx的代碼開(kāi)源，并且賦予其最自由的2-clauseBSD-likelicense許可證。由于Nginx使用基于事件驅(qū)動(dòng)的架構(gòu)能夠并發(fā)處理百萬(wàn)級(jí)別的TCP連接，高度模塊化的設(shè)計(jì)和自由的許可證使得擴(kuò)展Nginx功能的第三方模塊層出不窮，而且優(yōu)秀的設(shè)計(jì)帶來(lái)了極佳的穩(wěn)定性，因此其作為Web服務(wù)器被廣泛應(yīng)用到大流量的網(wǎng)站上，包括騰訊、新浪、網(wǎng)易、淘寶等訪問(wèn)量巨大的網(wǎng)站。2012年2月和3月Netcraft對(duì)Web服務(wù)器的調(diào)查如表1-1所示，可以看出，Nginx的市場(chǎng)份額越來(lái)越大。表1-1Netcraft對(duì)于Web服務(wù)器市場(chǎng)占有率前4位軟件的調(diào)查（2012年2月和3月）Nginx是一個(gè)跨平臺(tái)的Web服務(wù)器，可運(yùn)行在Linux、FreeBSD、Solaris、AIX、MacOS、Windows等操作系統(tǒng)上，并且它還可以使用當(dāng)前操作系統(tǒng)特有的一些高效API來(lái)提高自己的性能。例如，對(duì)于高效處理大規(guī)模并發(fā)連接，它支持Linux上的epoll（epoll是Linux上處理大并發(fā)網(wǎng)絡(luò)連接的利器，9.6.1節(jié)中將會(huì)詳細(xì)說(shuō)明epoll的工作原理）、Solaris上的eventports和FreeBSD上的kqueue等。又如，對(duì)于Linux，Nginx支持其獨(dú)有的sendfile系統(tǒng)調(diào)用，這個(gè)系統(tǒng)調(diào)用可以高效地把硬盤中的數(shù)據(jù)發(fā)送到網(wǎng)絡(luò)上（不需要先把硬盤數(shù)據(jù)復(fù)制到用戶態(tài)內(nèi)存上再發(fā)送），這極大地減少了內(nèi)核態(tài)與用戶態(tài)數(shù)據(jù)間的復(fù)制動(dòng)作。種種跡象都表明，Nginx以性能為王。2011年7月，Nginx正式成立公司，由IgorSysoev擔(dān)任CTO，立足于提供商業(yè)級(jí)的Web服務(wù)器。1.2為什么選擇Nginx為什么選擇Nginx？因?yàn)樗哂幸韵绿攸c(diǎn)：（1）更快這表現(xiàn)在兩個(gè)方面：一方面，在正常情況下，單次請(qǐng)求會(huì)得到更快的響應(yīng)；另一方面，在高峰期（如有數(shù)以萬(wàn)計(jì)的并發(fā)請(qǐng)求），Nginx可以比其他Web服務(wù)器更快地響應(yīng)請(qǐng)求。實(shí)際上，本書(shū)第三部分中大量的篇幅都是在說(shuō)明Nginx是如何做到這兩點(diǎn)的。（2）高擴(kuò)展性Nginx的設(shè)計(jì)極具擴(kuò)展性，它完全是由多個(gè)不同功能、不同層次、不同類型且耦合度極低的模塊組成。因此，當(dāng)對(duì)某一個(gè)模塊修復(fù)Bug或進(jìn)行升級(jí)時(shí)，可以專注于模塊自身，無(wú)須在意其他。而且在HTTP模塊中，還設(shè)計(jì)了HTTP過(guò)濾器模塊：一個(gè)正常的HTTP模塊在處理完請(qǐng)求后，會(huì)有一串HTTP過(guò)濾器模塊對(duì)請(qǐng)求的結(jié)果進(jìn)行再處理。這樣，當(dāng)我們開(kāi)發(fā)一個(gè)新的HTTP模塊時(shí)，不但可以使用諸如HTTP核心模塊、events模塊、log模塊等不同層次或者不同類型的模塊，還可以原封不動(dòng)地復(fù)用大量已有的HTTP過(guò)濾器模塊。這種低耦合度的優(yōu)秀設(shè)計(jì)，造就了Nginx龐大的第三方模塊，當(dāng)然，公開(kāi)的第三方模塊也如官方發(fā)布的模塊一樣容易使用。Nginx的模塊都是嵌入到二進(jìn)制文件中執(zhí)行的，無(wú)論官方發(fā)布的模塊還是第三方模塊都是如此。這使得第三方模塊一樣具備極其優(yōu)秀的性能，充分利用Nginx的高并發(fā)特性，因此，許多高流量的網(wǎng)站都傾向于開(kāi)發(fā)符合自己業(yè)務(wù)特性的定制模塊。（3）高可靠性高可靠性是我們選擇Nginx的最基本條件，因?yàn)镹ginx的可靠性是大家有目共睹的，很多家高流量網(wǎng)站都在核心服務(wù)器上大規(guī)模使用Nginx。Nginx的高可靠性來(lái)自于其核心框架代碼的優(yōu)秀設(shè)計(jì)、模塊設(shè)計(jì)的簡(jiǎn)單性；另外，官方提供的常用模塊都非常穩(wěn)定，每個(gè)worker進(jìn)程相對(duì)獨(dú)立，master進(jìn)程在1個(gè)worker進(jìn)程出錯(cuò)時(shí)可以快速“拉起”新的worker子進(jìn)程提供服務(wù)。（4）低內(nèi)存消耗一般情況下，10000個(gè)非活躍的HTTPKeep-Alive連接在Nginx中僅消耗2.5MB的內(nèi)存，這是Nginx支持高并發(fā)連接的基礎(chǔ)。從第3章開(kāi)始，我們會(huì)接觸到Nginx在內(nèi)存中為了維護(hù)一個(gè)HTTP連接所分配的對(duì)象，屆時(shí)將會(huì)看到，實(shí)際上Nginx一直在為用戶考慮（尤其是在高并發(fā)時(shí)）如何使得內(nèi)存的消耗更少。（5）單機(jī)支持10萬(wàn)以上的并發(fā)連接這是一個(gè)非常重要的特性！隨著互聯(lián)網(wǎng)的迅猛發(fā)展和互聯(lián)網(wǎng)用戶數(shù)量的成倍增長(zhǎng)，各大公司、網(wǎng)站都需要應(yīng)付海量并發(fā)請(qǐng)求，一個(gè)能夠在峰值期頂住10萬(wàn)以上并發(fā)請(qǐng)求的Server，無(wú)疑會(huì)得到大家的青睞。理論上，Nginx支持的并發(fā)連接上限取決于內(nèi)存，10萬(wàn)遠(yuǎn)未封頂。當(dāng)然，能夠及時(shí)地處理更多的并發(fā)請(qǐng)求，是與業(yè)務(wù)特點(diǎn)緊密相關(guān)的，本書(shū)第8~11章將會(huì)詳細(xì)說(shuō)明如何實(shí)現(xiàn)這個(gè)特點(diǎn)。（6）熱部署master管理進(jìn)程與worker工作進(jìn)程的分離設(shè)計(jì)，使得Nginx能夠提供熱部署功能，即可以在7×24小時(shí)不間斷服務(wù)的前提下，升級(jí)Nginx的可執(zhí)行文件。當(dāng)然，它也支持不停止服務(wù)就更新配置項(xiàng)、更換日志文件等功能。（7）最自由的BSD許可協(xié)議這是Nginx可以快速發(fā)展的強(qiáng)大動(dòng)力。BSD許可協(xié)議不只是允許用戶免費(fèi)使用Nginx，它還允許用戶在自己的項(xiàng)目中直接使用或修改Nginx源碼，然后發(fā)布。這吸引了無(wú)數(shù)開(kāi)發(fā)者繼續(xù)為Nginx貢獻(xiàn)自己的智慧。以上7個(gè)特點(diǎn)當(dāng)然不是Nginx的全部，擁有無(wú)數(shù)個(gè)官方功能模塊、第三方功能模塊使得Nginx能夠滿足絕大部分應(yīng)用場(chǎng)景，這些功能模塊間可以疊加以實(shí)現(xiàn)更加強(qiáng)大、復(fù)雜的功能，有些模塊還支持Nginx與Perl、Lua等腳本語(yǔ)言集成工作，大大提高了開(kāi)發(fā)效率。這些特點(diǎn)促使用戶在尋找一個(gè)Web服務(wù)器時(shí)更多考慮Nginx。當(dāng)然，選擇Nginx的核心理由還是它能在支持高并發(fā)請(qǐng)求的同時(shí)保持高效的服務(wù)。如果Web服務(wù)器的業(yè)務(wù)訪問(wèn)量巨大，就需要保證在數(shù)以百萬(wàn)計(jì)的請(qǐng)求同時(shí)訪問(wèn)服務(wù)時(shí)，用戶可以獲得良好的體驗(yàn)，不會(huì)出現(xiàn)并發(fā)訪問(wèn)量達(dá)到一個(gè)數(shù)字后，新的用戶無(wú)法獲取服務(wù)，或者雖然成功地建立起了TCP連接，但大部分請(qǐng)求卻得不到響應(yīng)的情況。通常，高峰期服務(wù)器的訪問(wèn)量可能是正常情況下的許多倍，若有熱點(diǎn)事件的發(fā)生，可能會(huì)導(dǎo)致正常情況下非常順暢的服務(wù)器直接“掛死”。然而，如果在部署服務(wù)器時(shí)，就預(yù)先針對(duì)這種情況進(jìn)行擴(kuò)容，又會(huì)使得正常情況下所有服務(wù)器的負(fù)載過(guò)低，這會(huì)造成大量的資源浪費(fèi)。因此，我們會(huì)希望在這之間取得平衡，也就是說(shuō)，在低并發(fā)壓力下，用戶可以獲得高速體驗(yàn)，而在高并發(fā)壓力下，更多的用戶都能接入，可能訪問(wèn)速度會(huì)下降，但這只應(yīng)受制于帶寬和處理器的速度，而不應(yīng)該是服務(wù)器設(shè)計(jì)導(dǎo)致的軟件瓶頸。事實(shí)上，由于中國(guó)互聯(lián)網(wǎng)用戶群體的數(shù)量巨大，致使對(duì)Web服務(wù)器的設(shè)計(jì)往往要比歐美公司更加困難。例如，對(duì)于全球性的一些網(wǎng)站而言，歐美用戶分布在兩個(gè)半球，歐洲用戶活躍時(shí)，美洲用戶通常在休息，反之亦然。而國(guó)內(nèi)巨大的用戶群體則對(duì)業(yè)界的程序員提出更高的挑戰(zhàn)，早上9點(diǎn)和晚上20點(diǎn)到24點(diǎn)這些時(shí)間段的并發(fā)請(qǐng)求壓力是非常巨大的。尤其節(jié)假日、寒暑假到來(lái)之時(shí)，更會(huì)對(duì)服務(wù)器提出極高的要求。另外，國(guó)內(nèi)業(yè)務(wù)上的特性，也會(huì)引導(dǎo)用戶在同一時(shí)間大并發(fā)地訪問(wèn)服務(wù)器。例如，許多SNS網(wǎng)頁(yè)游戲會(huì)在固定的時(shí)間點(diǎn)刷新游戲資源或者允許“偷菜”等好友互動(dòng)操作。這些會(huì)導(dǎo)致服務(wù)器處理高并發(fā)請(qǐng)求的壓力增大。上述情形都對(duì)我們的互聯(lián)網(wǎng)服務(wù)在大并發(fā)壓力下是否還能夠給予用戶良好的體驗(yàn)提出了更高的要求。若要提供更好的服務(wù)，那么可以從多方面入手，例如，修改業(yè)務(wù)特性、引導(dǎo)用戶從高峰期分流或者把服務(wù)分層分級(jí)、對(duì)于不同并發(fā)壓力給用戶提供不同級(jí)別的服務(wù)等。但最根本的是，Web服務(wù)器要能支持大并發(fā)壓力下的正常服務(wù)，這才是關(guān)鍵?？焖僭鲩L(zhǎng)的互聯(lián)網(wǎng)用戶群以及業(yè)內(nèi)所有互聯(lián)網(wǎng)服務(wù)提供商越來(lái)越好的用戶體驗(yàn)，都促使我們?cè)诖罅髁糠?wù)中用Nginx取代其他Web服務(wù)器。Nginx先天的事件驅(qū)動(dòng)型設(shè)計(jì)、全異步的網(wǎng)絡(luò)I/O處理機(jī)制、極少的進(jìn)程間切換以及許多優(yōu)化設(shè)計(jì)，都使得Nginx天生善于處理高并發(fā)壓力下的互聯(lián)網(wǎng)請(qǐng)求，同時(shí)Nginx降低了資源消耗，可以把服務(wù)器硬件資源“壓榨”到極致。1.3準(zhǔn)備工作由于Linux具有免費(fèi)、使用廣泛、商業(yè)支持越來(lái)越完善等特點(diǎn)，本書(shū)將主要針對(duì)Linux上運(yùn)行的Nginx來(lái)進(jìn)行介紹。需要說(shuō)明的是，本書(shū)不是使用手冊(cè)，而是介紹Nginx作為Web服務(wù)器的設(shè)計(jì)思想，以及如何更有效地使用Nginx達(dá)成目的，而這些內(nèi)容在各操作系統(tǒng)上基本是相通的（除了第9章關(guān)于事件驅(qū)動(dòng)方式以及第14章的進(jìn)程間同步方式在類UNIX操作系統(tǒng)上略有不同以外）。1.3.1Linux操作系統(tǒng)首先我們需要一個(gè)內(nèi)核為L(zhǎng)inux2.6及以上版本的操作系統(tǒng)，因?yàn)長(zhǎng)inux2.6及以上內(nèi)核才支持epoll，而在Linux上使用select或poll來(lái)解決事件的多路復(fù)用，是無(wú)法解決高并發(fā)壓力問(wèn)題的。我們可以使用uname-a命令來(lái)查詢Linux內(nèi)核版本，例如：:wehf2wng001:root>uname-aLinuxwehf2wng0012.6.18-128.el5#1SMPWedJan2110:41:14EST2009x86_64x86_64x86_64GNU/Linux執(zhí)行結(jié)果表明內(nèi)核版本是2.6.18，符合我們的要求。1.3.2使用Nginx的必備軟件如果要使用Nginx的常用功能，那么首先需要確保該操作系統(tǒng)上至少安裝了如下軟件。（1）GCC編譯器GCC（GNUCompilerCollection）可用來(lái)編譯C語(yǔ)言程序。Nginx不會(huì)直接提供二進(jìn)制可執(zhí)行程序（1.2.x版本中已經(jīng)開(kāi)始提供某些操作系統(tǒng)上的二進(jìn)制安裝包了，不過(guò)，本書(shū)探討如何開(kāi)發(fā)Nginx模塊是必須通過(guò)直接編譯源代碼進(jìn)行的），這有許多原因，本章后面會(huì)詳述。我們可以使用最簡(jiǎn)單的yum方式安裝GCC，例如：yuminstall-ygccGCC是必需的編譯工具。在第3章會(huì)提到如何使用C++來(lái)編寫(xiě)NginxHTTP模塊，這時(shí)就需要用到G++編譯器了。G++編譯器也可以用yum安裝，例如：yuminstall-ygcc-c++Linux上有許多軟件安裝方式，yum只是其中比較方便的一種，其他方式這里不再贅述。（2）PCRE庫(kù)PCRE（PerlCompatibleRegularExpressions，Perl兼容正則表達(dá)式）是由PhilipHazel開(kāi)發(fā)的函數(shù)庫(kù)，目前為很多軟件所使用，該庫(kù)支持正則表達(dá)式。它由RegEx演化而來(lái)，實(shí)際上，Perl正則表達(dá)式也是源自于HenrySpencer寫(xiě)的RegEx。如果我們?cè)谂渲梦募ginx.conf里使用了正則表達(dá)式，那么在編譯Nginx時(shí)就必須把PCRE庫(kù)編譯進(jìn)Nginx，因?yàn)镹ginx的HTTP模塊要靠它來(lái)解析正則表達(dá)式。當(dāng)然，如果你確認(rèn)不會(huì)使用正則表達(dá)式，就不必安裝它。其yum安裝方式如下：yuminstall-ypcrepcre-develpcre-devel是使用PCRE做二次開(kāi)發(fā)時(shí)所需要的開(kāi)發(fā)庫(kù)，包括頭文件等，這也是編譯Nginx所必須使用的。（3）zlib庫(kù)zlib庫(kù)用于對(duì)HTTP包的內(nèi)容做gzip格式的壓縮，如果我們?cè)趎ginx.conf里配置了gzipon，并指定對(duì)于某些類型（content-type）的HTTP響應(yīng)使用gzip來(lái)進(jìn)行壓縮以減少網(wǎng)絡(luò)傳輸量，那么，在編譯時(shí)就必須把zlib編譯進(jìn)Nginx。其yum安裝方式如下：yuminstall-yzlibzlib-devel同理，zlib是直接使用的庫(kù)，zlib-devel是二次開(kāi)發(fā)所需要的庫(kù)。（4）OpenSSL開(kāi)發(fā)庫(kù)如果我們的服務(wù)器不只是要支持HTTP，還需要在更安全的SSL協(xié)議上傳輸HTTP，那么就需要擁有OpenSSL了。另外，如果我們想使用MD5、SHA1等散列函數(shù)，那么也需要安裝它。其yum安裝方式如下：yuminstall-yopensslopenssl-devel上面所列的4個(gè)庫(kù)只是完成Web服務(wù)器最基本功能所必需的。Nginx是高度自由化的Web服務(wù)器，它的功能是由許多模塊來(lái)支持的。而這些模塊可根據(jù)我們的使用需求來(lái)定制，如果某些模塊不需要使用則完全不必理會(huì)它。同樣，如果使用了某個(gè)模塊，而這個(gè)模塊使用了一些類似zlib或OpenSSL等的第三方庫(kù)，那么就必須先安裝這些軟件。1.3.3磁盤目錄要使用Nginx，還需要在Linux文件系統(tǒng)上準(zhǔn)備以下目錄。（1）Nginx源代碼存放目錄該目錄用于放置從官網(wǎng)上下載的Nginx源碼文件，以及第三方或我們自己所寫(xiě)的模塊源代碼文件。（2）Nginx編譯階段產(chǎn)生的中間文件存放目錄該目錄用于放置在configure命令執(zhí)行后所生成的源文件及目錄，以及make命令執(zhí)行后生成的目標(biāo)文件和最終連接成功的二進(jìn)制文件。默認(rèn)情況下，configure命令會(huì)將該目錄命名為objs，并放在Nginx源代碼目錄下。（3）部署目錄該目錄存放實(shí)際Nginx服務(wù)運(yùn)行期間所需要的二進(jìn)制文件、配置文件等。默認(rèn)情況下，該目錄為/usr/local/nginx。（4）日志文件存放目錄日志文件通常會(huì)比較大，當(dāng)研究Nginx的底層架構(gòu)時(shí)，需要打開(kāi)debug級(jí)別的日志，這個(gè)級(jí)別的日志非常詳細(xì)，會(huì)導(dǎo)致日志文件的大小增長(zhǎng)得極快，需要預(yù)先分配一個(gè)擁有更大磁盤空間的目錄。1.3.4Linux內(nèi)核參數(shù)的優(yōu)化由于默認(rèn)的Linux內(nèi)核參數(shù)考慮的是最通用的場(chǎng)景，這明顯不符合用于支持高并發(fā)訪問(wèn)的Web服務(wù)器的定義，所以需要修改Linux內(nèi)核參數(shù)，使得Nginx可以擁有更高的性能。在優(yōu)化內(nèi)核時(shí)，可以做的事情很多，不過(guò)，我們通常會(huì)根據(jù)業(yè)務(wù)特點(diǎn)來(lái)進(jìn)行調(diào)整，當(dāng)Nginx作為靜態(tài)Web內(nèi)容服務(wù)器、反向代理服務(wù)器或是提供圖片縮略圖功能（實(shí)時(shí)壓縮圖片）的服務(wù)器時(shí)，其內(nèi)核參數(shù)的調(diào)整都是不同的。這里只針對(duì)最通用的、使Nginx支持更多并發(fā)請(qǐng)求的TCP網(wǎng)絡(luò)參數(shù)做簡(jiǎn)單說(shuō)明。首先，需要修改/etc/sysctl.conf來(lái)更改內(nèi)核參數(shù)。例如，最常用的配置：fs.file-max=999999net.ipv4.tcp_tw_reuse=1net.ipv4.tcp_keepalive_time=600net.ipv4.tcp_fin_timeout=30net.ipv4.tcp_max_tw_buckets=5000net.ipv4.ip_local_port_range=102461000net.ipv4.tcp_rmem=409632768262142net.ipv4.tcp_wmem=409632768262142dev_max_backlog=8096net.core.rmem_default=262144net.core.wmem_default=262144net.core.rmem_max=2097152net.core.wmem_max=2097152net.ipv4.tcp_syncookies=1net.ipv4.tcp_max_syn.backlog=1024然后執(zhí)行sysctl-p命令，使上述修改生效。上面的參數(shù)意義解釋如下：·file-max：這個(gè)參數(shù)表示進(jìn)程（比如一個(gè)worker進(jìn)程）可以同時(shí)打開(kāi)的最大句柄數(shù)，這個(gè)參數(shù)直接限制最大并發(fā)連接數(shù)，需根據(jù)實(shí)際情況配置?！cp_tw_reuse：這個(gè)參數(shù)設(shè)置為1，表示允許將TIME-WAIT狀態(tài)的socket重新用于新的TCP連接，這對(duì)于服務(wù)器來(lái)說(shuō)很有意義，因?yàn)榉?wù)器上總會(huì)有大量TIME-WAIT狀態(tài)的連接。·tcp_keepalive_time：這個(gè)參數(shù)表示當(dāng)keepalive啟用時(shí)，TCP發(fā)送keepalive消息的頻度。默認(rèn)是2小時(shí)，若將其設(shè)置得小一些，可以更快地清理無(wú)效的連接?！cp_fin_timeout：這個(gè)參數(shù)表示當(dāng)服務(wù)器主動(dòng)關(guān)閉連接時(shí)，socket保持在FIN-WAIT-2狀態(tài)的最大時(shí)間?！cp_max_tw_buckets：這個(gè)參數(shù)表示操作系統(tǒng)允許TIME_WAIT套接字?jǐn)?shù)量的最大值，如果超過(guò)這個(gè)數(shù)字，TIME_WAIT套接字將立刻被清除并打印警告信息。該參數(shù)默認(rèn)為180000，過(guò)多的TIME_WAIT套接字會(huì)使Web服務(wù)器變慢?！cp_max_syn_backlog：這個(gè)參數(shù)表示TCP三次握手建立階段接收SYN請(qǐng)求隊(duì)列的最大長(zhǎng)度，默認(rèn)為1024，將其設(shè)置得大一些可以使出現(xiàn)Nginx繁忙來(lái)不及accept新連接的情況時(shí)，Linux不至于丟失客戶端發(fā)起的連接請(qǐng)求?！p_local_port_range：這個(gè)參數(shù)定義了在UDP和TCP連接中本地（不包括連接的遠(yuǎn)端）端口的取值范圍?！et.ipv4.tcp_rmem：這個(gè)參數(shù)定義了TCP接收緩存（用于TCP接收滑動(dòng)窗口）的最小值、默認(rèn)值、最大值。·net.ipv4.tcp_wmem：這個(gè)參數(shù)定義了TCP發(fā)送緩存（用于TCP發(fā)送滑動(dòng)窗口）的最小值、默認(rèn)值、最大值。·netdev_max_backlog：當(dāng)網(wǎng)卡接收數(shù)據(jù)包的速度大于內(nèi)核處理的速度時(shí)，會(huì)有一個(gè)隊(duì)列保存這些數(shù)據(jù)包。這個(gè)參數(shù)表示該隊(duì)列的最大值?！mem_default：這個(gè)參數(shù)表示內(nèi)核套接字接收緩存區(qū)默認(rèn)的大小?！mem_default：這個(gè)參數(shù)表示內(nèi)核套接字發(fā)送緩存區(qū)默認(rèn)的大小?！mem_max：這個(gè)參數(shù)表示內(nèi)核套接字接收緩存區(qū)的最大大小?！mem_max：這個(gè)參數(shù)表示內(nèi)核套接字發(fā)送緩存區(qū)的最大大小。注意滑動(dòng)窗口的大小與套接字緩存區(qū)會(huì)在一定程度上影響并發(fā)連接的數(shù)目。每個(gè)TCP連接都會(huì)為維護(hù)TCP滑動(dòng)窗口而消耗內(nèi)存，這個(gè)窗口會(huì)根據(jù)服務(wù)器的處理速度收縮或擴(kuò)張。參數(shù)wmem_max的設(shè)置，需要平衡物理內(nèi)存的總大小、Nginx并發(fā)處理的最大連接數(shù)量（由nginx.conf中的worker_processes和worker_connections參數(shù)決定）而確定。當(dāng)然，如果僅僅為了提高并發(fā)量使服務(wù)器不出現(xiàn)OutOfMemory問(wèn)題而去降低滑動(dòng)窗口大小，那么并不合適，因?yàn)榛瑒?dòng)窗口過(guò)小會(huì)影響大數(shù)據(jù)量的傳輸速度。rmem_default、wmem_default、rmem_max、wmem_max這4個(gè)參數(shù)的設(shè)置需要根據(jù)我們的業(yè)務(wù)特性以及實(shí)際的硬件成本來(lái)綜合考慮?！cp_syncookies：該參數(shù)與性能無(wú)關(guān)，用于解決TCP的SYN攻擊。1.3.5獲取Nginx源碼可以在Nginx官方網(wǎng)站（/en/download.html）獲取Nginx源碼包。將下載的nginx-1.0.14.tar.gz源碼壓縮包放置到準(zhǔn)備好的Nginx源代碼目錄中，然后解壓。例如：tar-zxvfnginx-1.0.14.tar.gz本書(shū)編寫(xiě)時(shí)的Nginx最新穩(wěn)定版本為1.0.14（如圖1-2所示），本書(shū)后續(xù)部分都將以此版本作為基準(zhǔn)。當(dāng)然，本書(shū)將要說(shuō)明的Nginx核心代碼一般不會(huì)有改動(dòng)（否則大量第三方模塊的功能就無(wú)法保證了），即使下載其他版本的Nginx源碼包也不會(huì)影響閱讀本書(shū)。圖1-2Nginx的不同版本1.4編譯安裝Nginx安裝Nginx最簡(jiǎn)單的方式是，進(jìn)入nginx-1.0.14目錄后執(zhí)行以下3行命令：./configuremakemakeinstallconfigure命令做了大量的“幕后”工作，包括檢測(cè)操作系統(tǒng)內(nèi)核和已經(jīng)安裝的軟件，參數(shù)的解析，中間目錄的生成以及根據(jù)各種參數(shù)生成一些C源碼文件、Makefile文件等。make命令根據(jù)configure命令生成的Makefile文件編譯Nginx工程，并生成目標(biāo)文件、最終的二進(jìn)制文件。makeinstall命令根據(jù)configure執(zhí)行時(shí)的參數(shù)將Nginx部署到指定的安裝目錄，包括相關(guān)目錄的建立和二進(jìn)制文件、配置文件的復(fù)制。1.5configure詳解可以看出，configure命令至關(guān)重要，下文將詳細(xì)介紹如何使用configure命令，并分析configure到底是如何工作的，從中我們也可以看出Nginx的一些設(shè)計(jì)思想。1.5.1configure的命令參數(shù)使用help命令可以查看configure包含的參數(shù)。./configure--help這里不一一列出help的結(jié)果，只是把它的參數(shù)分為了四大類型，下面將會(huì)詳述各類型下所有參數(shù)的用法和意義。1.路徑相關(guān)的參數(shù)表1-2列出了Nginx在編譯期、運(yùn)行期中與路徑相關(guān)的各種參數(shù)。表1-2configure支持的路徑相關(guān)參數(shù)2.編譯相關(guān)的參數(shù)表1-3列出了編譯Nginx時(shí)與編譯器相關(guān)的參數(shù)。表1-3configure支持的編譯相關(guān)參數(shù)3.依賴軟件的相關(guān)參數(shù)表1-4~表1-8列出了Nginx依賴的常用軟件支持的參數(shù)。表1-4PCRE的設(shè)置參數(shù)表1-5OpenSSL的設(shè)置參數(shù)表1-6原子庫(kù)的設(shè)置參數(shù)表1-7散列函數(shù)庫(kù)的設(shè)置參數(shù)表1-8zlib庫(kù)的設(shè)置參數(shù)4.模塊相關(guān)的參數(shù)除了少量核心代碼外，Nginx完全是由各種功能模塊組成的。這些模塊會(huì)根據(jù)配置參數(shù)決定自己的行為，因此，正確地使用各個(gè)模塊非常關(guān)鍵。在configure的參數(shù)中，我們把它們分為五大類?！な录K?！つJ(rèn)即編譯進(jìn)入Nginx的HTTP模塊?！つJ(rèn)不會(huì)編譯進(jìn)入Nginx的HTTP模塊。·郵件代理服務(wù)器相關(guān)的mail模塊?！て渌K。（1）事件模塊表1-9中列出了Nginx可以選擇哪些事件模塊編譯到產(chǎn)品中。表1-9configure支持的事件模塊參數(shù)（2）默認(rèn)即編譯進(jìn)入Nginx的HTTP模塊表1-10列出了默認(rèn)就會(huì)編譯進(jìn)Nginx的核心HTTP模塊，以及如何把這些HTTP模塊從產(chǎn)品中去除。表1-10configure中默認(rèn)編譯到Nginx中的HTTP模塊參數(shù)（3）默認(rèn)不會(huì)編譯進(jìn)入Nginx的HTTP模塊表1-11列出了默認(rèn)不會(huì)編譯至Nginx中的HTTP模塊以及把它們加入產(chǎn)品中的方法。表1-11configure中默認(rèn)不會(huì)編譯到Nginx中的HTTP模塊參數(shù)（4）郵件代理服務(wù)器相關(guān)的mail模塊表1-12列出了把郵件模塊編譯到產(chǎn)品中的參數(shù)。表1-12configure提供的郵件模塊參數(shù)5.其他參數(shù)configure還接收一些其他參數(shù)，表1-13中列出了相關(guān)參數(shù)的說(shuō)明。表1-13configure提供的其他參數(shù)1.5.2configure執(zhí)行流程我們看到configure命令支持非常多的參數(shù)，讀者可能會(huì)好奇它在執(zhí)行時(shí)到底做了哪些事情，本節(jié)將通過(guò)解析configure源碼來(lái)對(duì)它有一個(gè)感性的認(rèn)識(shí)。configure由Shell腳本編寫(xiě)，中間會(huì)調(diào)用/auto/目錄下的腳本。這里將只對(duì)configure腳本本身做分析，對(duì)于它所調(diào)用的auto目錄下的其他工具腳本則只做功能性的說(shuō)明。configure腳本的內(nèi)容如下：#!/bin/sh#Copyright(C)IgorSysoev#Copyright(C)Nginx,Inc.#auto/options腳本處理configure命令的參數(shù)。例如，如果參數(shù)是--help，那么顯示支持的所有參數(shù)格式。options腳本會(huì)定義后續(xù)工作將要用到的變量，然后根據(jù)本次參數(shù)以及默認(rèn)值設(shè)置這些變量.auto/options#auto/init腳本初始化后續(xù)將產(chǎn)生的文件路徑。例如，Makefile、ngx_modules.c等文件默認(rèn)情況下將會(huì)在/objs/.auto/init#auto/sources腳本將分析Nginx的源碼結(jié)構(gòu)，這樣才能構(gòu)造后續(xù)的Makefile文件.auto/sources#編譯過(guò)程中所有目標(biāo)文件生成的路徑由—builddir=DIR參數(shù)指定，默認(rèn)情況下為/objs，此時(shí)這個(gè)目錄將會(huì)被創(chuàng)建test-d$NGX_OBJS||mkdir$NGX_OBJS#開(kāi)始準(zhǔn)備建立ngx_auto_headers.h、autoconf.err等必要的編譯文件echo>$NGX_AUTO_HEADERS_Hecho>$NGX_AUTOCONF_ERR#向objs/ngx_auto_config.h寫(xiě)入命令行帶的參數(shù)echo"#defineNGX_CONFIGURE\"$NGX_CONFIGURE\"">$NGX_AUTO_CONFIG_H#判斷DEBUG標(biāo)志，如果有，那么在objs/ngx_auto_config.h文件中寫(xiě)入DEBUG宏if[$NGX_DEBUG=YES];thenhave=NGX_DEBUG.auto/havefi#現(xiàn)在開(kāi)始檢查操作系統(tǒng)參數(shù)是否支持后續(xù)編譯iftest-z"$NGX_PLATFORM";thenecho"checkingforOS"NGX_SYSTEM=`uname-s2>/dev/null`NGX_RELEASE=`uname-r2>/dev/null`NGX_MACHINE=`uname-m2>/dev/null`#屏幕上輸出OS名稱、內(nèi)核版本、32位/64位內(nèi)核echo"+$NGX_SYSTEM$NGX_RELEASE$NGX_MACHINE"NGX_PLATFORM="$NGX_SYSTEM:$NGX_RELEASE:$NGX_MACHINE";case"$NGX_SYSTEM"inMINGW32_*)NGX_PLATFORM=win32;;esacelseecho"buildingfor$NGX_PLATFORM"NGX_SYSTEM=$NGX_PLATFORMfi#檢查并設(shè)置編譯器，如GCC是否安裝、GCC版本是否支持后續(xù)編譯nginx.auto/cc/conf#對(duì)非Windows操作系統(tǒng)定義一些必要的頭文件，并檢查其是否存在，以此決定configure后續(xù)步驟是否可以成功if["$NGX_PLATFORM"!=win32];then.auto/headersfi#對(duì)于當(dāng)前操作系統(tǒng)，定義一些特定的操作系統(tǒng)相關(guān)的方法并檢查當(dāng)前環(huán)境是否支持。例如，對(duì)于Linux，在這里使用sched_setaffinity設(shè)置進(jìn)程優(yōu)先級(jí)，使用Linux特有的sendfile系統(tǒng)調(diào)用來(lái)加速向網(wǎng)絡(luò)中發(fā)送文件塊.auto/os/conf#定義類UNIX操作系統(tǒng)中通用的頭文件和系統(tǒng)調(diào)用等，并檢查當(dāng)前環(huán)境是否支持if["$NGX_PLATFORM"!=win32];then.auto/unixfi#最核心的構(gòu)造運(yùn)行期modules的腳本。它將會(huì)生成ngx_modules.c文件，這個(gè)文件會(huì)被編譯進(jìn)Nginx中，其中它所做的唯一的事情就是定義了ngx_modules數(shù)組。ngx_modules指明Nginx運(yùn)行期間有哪些模塊會(huì)參與到請(qǐng)求的處理中，包括HTTP請(qǐng)求可能會(huì)使用哪些模塊處理，因此，它對(duì)數(shù)組元素的順序非常敏感，也就是說(shuō)，絕大部分模塊在ngx_modules數(shù)組中的順序其實(shí)是固定的。例如，一個(gè)請(qǐng)求必須先執(zhí)行ngx_http_gzip_filter_module模塊重新修改HTTP響應(yīng)中的頭部后，才能使用ngx_http_header_filter模塊按照headers_in結(jié)構(gòu)體里的成員構(gòu)造出以TCP流形式發(fā)送給客戶端的HTTP響應(yīng)頭部。注意，我們?cè)?-add-module=參數(shù)里加入的第三方模塊也在此步驟寫(xiě)入到ngx_modules.c文件中了.auto/modules#conf腳本用來(lái)檢查Nginx在鏈接期間需要鏈接的第三方靜態(tài)庫(kù)、動(dòng)態(tài)庫(kù)或者目標(biāo)文件是否存在.auto/lib/conf#處理Nginx安裝后的路徑case".$NGX_PREFIX"in.)NGX_PREFIX=${NGX_PREFIX:-/usr/local/nginx}have=NGX_PREFIXvalue="\"$NGX_PREFIX/\"".auto/define;;.!)NGX_PREFIX=;;*)have=NGX_PREFIXvalue="\"$NGX_PREFIX/\"".auto/define;;esac#處理Nginx安裝后conf文件的路徑if[".$NGX_CONF_PREFIX"!="."];thenhave=NGX_CONF_PREFIXvalue="\"$NGX_CONF_PREFIX/\"".auto/definefi#處理Nginx安裝后，二進(jìn)制文件、pid、lock等其他文件的路徑可參見(jiàn)configure參數(shù)中路徑類選項(xiàng)的說(shuō)明have=NGX_SBIN_PATHvalue="\"$NGX_SBIN_PATH\"".auto/definehave=NGX_CONF_PATHvalue="\"$NGX_CONF_PATH\"".auto/definehave=NGX_PID_PATHvalue="\"$NGX_PID_PATH\"".auto/definehave=NGX_LOCK_PATHvalue="\"$NGX_LOCK_PATH\"".auto/definehave=NGX_ERROR_LOG_PATHvalue="\"$NGX_ERROR_LOG_PATH\"".auto/definehave=NGX_HTTP_LOG_PATHvalue="\"$NGX_HTTP_LOG_PATH\"".auto/definehave=NGX_HTTP_CLIENT_TEMP_PATHvalue="\"$NGX_HTTP_CLIENT_TEMP_PATH\"".auto/definehave=NGX_HTTP_PROXY_TEMP_PATHvalue="\"$NGX_HTTP_PROXY_TEMP_PATH\"".auto/definehave=NGX_HTTP_FASTCGI_TEMP_PATHvalue="\"$NGX_HTTP_FASTCGI_TEMP_PATH\"".auto/definehave=NGX_HTTP_UWSGI_TEMP_PATHvalue="\"$NGX_HTTP_UWSGI_TEMP_PATH\"".auto/definehave=NGX_HTTP_SCGI_TEMP_PATHvalue="\"$NGX_HTTP_SCGI_TEMP_PATH\"".auto/define#創(chuàng)建編譯時(shí)使用的objs/Makefile文件.auto/make#為objs/Makefile加入需要連接的第三方靜態(tài)庫(kù)、動(dòng)態(tài)庫(kù)或者目標(biāo)文件.auto/lib/make#為objs/Makefile加入install功能，當(dāng)執(zhí)行makeinstall時(shí)將編譯生成的必要文件復(fù)制到安裝路徑，建立必要的目錄.auto/install#在ngx_auto_config.h文件中加入NGX_SUPPRESS_WARN宏、NGX_SMP宏.auto/stubs#在ngx_auto_config.h文件中指定NGX_USER和NGX_GROUP宏，如果執(zhí)行configure時(shí)沒(méi)有參數(shù)指定，默認(rèn)兩者皆為nobody（也就是默認(rèn)以nobody用戶運(yùn)行進(jìn)程）have=NGX_USERvalue="\"$NGX_USER\"".auto/definehave=NGX_GROUPvalue="\"$NGX_GROUP\"".auto/define#顯示configure執(zhí)行的結(jié)果，如果失敗，則給出原因.auto/summary（注：在configure腳本里檢查某個(gè)特性是否存在時(shí)，會(huì)生成一個(gè)最簡(jiǎn)單的只包含main函數(shù)的C程序，該程序會(huì)包含相應(yīng)的頭文件。然后，通過(guò)檢查是否可以編譯通過(guò)來(lái)確認(rèn)特性是否支持，并將結(jié)果記錄在objs/autoconf.err文件中。后續(xù)檢查頭文件、檢查特性的腳本都用了類似的方法。）1.5.3configure生成的文件當(dāng)configure執(zhí)行成功時(shí)會(huì)生成objs目錄，并在該目錄下產(chǎn)生以下目錄和文件：|ngx_auto_headers.h|autoconf.err|ngx_auto_config.h|ngx_modules.c|src||core||event|||modules||os|||unix|||win32||http|||modules||||perl||mail||misc|Makefile上述目錄和文件介紹如下。1）src目錄用于存放編譯時(shí)產(chǎn)生的目標(biāo)文件。2）Makefile文件用于編譯Nginx工程以及在加入install參數(shù)后安裝Nginx。3）autoconf.err保存configure執(zhí)行過(guò)程中產(chǎn)生的結(jié)果。4）ngx_auto_headers.h和ngx_auto_config.h保存了一些宏，這兩個(gè)頭文件會(huì)被src/core/ngx_config.h及src/os/unix/ngx_linux_config.h文件（可將“l(fā)inux”替換為其他UNIX操作系統(tǒng)）引用。5）ngx_modules.c是一個(gè)關(guān)鍵文件，我們需要看看它的內(nèi)部結(jié)構(gòu)。一個(gè)默認(rèn)配置下生成的ngx_modules.c文件內(nèi)容如下：#include#include…ngx_module_t*ngx_modules[]={&ngx_core_module,&ngx_errlog_module,&ngx_conf_module,&ngx_events_module,&ngx_event_core_module,&ngx_epoll_module,&ngx_http_module,&ngx_http_core_module,&ngx_http_log_module,&ngx_http_upstream_module,&ngx_http_static_module,&ngx_http_autoindex_module,&ngx_http_index_module,&ngx_http_auth_basic_module,&ngx_http_access_module,&ngx_http_limit_zone_module,&ngx_http_limit_req_module,&ngx_http_geo_module,&ngx_http_map_module,&ngx_http_split_clients_module,&ngx_http_referer_module,&ngx_http_rewrite_module,&ngx_http_proxy_module,&ngx_http_fastcgi_module,&ngx_http_uwsgi_module,&ngx_http_scgi_module,&ngx_http_memcached_module,&ngx_http_empty_gif_module,&ngx_http_browser_module,&ngx_http_upstream_ip_hash_module,&ngx_http_write_filter_module,&ngx_http_header_filter_module,&ngx_http_chunked_filter_module,&ngx_http_range_header_filter_module,&ngx_http_gzip_filter_module,&ngx_http_postpone_filter_module,&ngx_http_ssi_filter_module,&ngx_http_charset_filter_module,&ngx_http_userid_filter_module,&ngx_http_headers_filter_module,&ngx_http_copy_filter_module,&ngx_http_range_body_filter_module,&ngx_http_not_modified_filter_module,NULL};ngx_modules.c文件就是用來(lái)定義ngx_modules數(shù)組的。ngx_modules是非常關(guān)鍵的數(shù)組，它指明了每個(gè)模塊在Nginx中的優(yōu)先級(jí)，當(dāng)一個(gè)請(qǐng)求同時(shí)符合多個(gè)模塊的處理規(guī)則時(shí)，將按照它們?cè)趎gx_modules數(shù)組中的順序選擇最靠前的模塊優(yōu)先處理。對(duì)于HTTP過(guò)濾模塊而言則是相反的，因?yàn)镠TTP框架在初始化時(shí)，會(huì)在ngx_modules數(shù)組中將過(guò)濾模塊按先后順序向過(guò)濾鏈表中添加，但每次都是添加到鏈表的表頭，因此，對(duì)HTTP過(guò)濾模塊而言，在ngx_modules數(shù)組中越是靠后的模塊反而會(huì)首先處理HTTP響應(yīng)（參見(jiàn)第6章及第11章的11.9節(jié)）。因此，ngx_modules中模塊的先后順序非常重要，不正確的順序會(huì)導(dǎo)致Nginx無(wú)法工作，這是auto/modules腳本執(zhí)行后的結(jié)果。讀者可以體會(huì)一下上面的ngx_modules中同一種類型下（第8章會(huì)介紹模塊類型，第10章、第11章將介紹的HTTP框架對(duì)HTTP模塊的順序是最敏感的）各個(gè)模塊的順序以及這種順序帶來(lái)的意義。可以看出，在安裝過(guò)程中，configure做了大量的幕后工作，我們需要關(guān)注在這個(gè)過(guò)程中Nginx做了哪些事情。configure除了尋找依賴的軟件外，還針對(duì)不同的UNIX操作系統(tǒng)做了許多優(yōu)化工作。這是Nginx跨平臺(tái)的一種具體實(shí)現(xiàn)，也體現(xiàn)了Nginx追求高性能的一貫風(fēng)格。configure除了生成Makefile外，還生成了ngx_modules.c文件，它決定了運(yùn)行時(shí)所有模塊的優(yōu)先級(jí)（在編譯過(guò)程中而不是編碼過(guò)程中）。對(duì)于不需要的模塊，既不會(huì)加入ngx_modules數(shù)組，也不會(huì)編譯進(jìn)Nginx產(chǎn)品中，這也體現(xiàn)了輕量級(jí)的概念。1.6Nginx的命令行控制在Linux中，需要使用命令行來(lái)控制Nginx服務(wù)器的啟動(dòng)與停止、重載配置文件、回滾日志文件、平滑升級(jí)等行為。默認(rèn)情況下，Nginx被安裝在目錄/usr/local/nginx/中，其二進(jìn)制文件路徑為/usr/local/nginc/sbin/nginx，配置文件路徑為/usr/local/nginx/conf/nginx.conf。當(dāng)然，在configure執(zhí)行時(shí)是可以指定把它們安裝在不同目錄的。為了簡(jiǎn)單起見(jiàn)，本節(jié)只說(shuō)明默認(rèn)安裝情況下的命令行的使用情況，如果讀者安裝的目錄發(fā)生了變化，那么替換一下即可。（1）默認(rèn)方式啟動(dòng)直接執(zhí)行Nginx二進(jìn)制程序。例如：/usr/local/nginx/sbin/nginx這時(shí)，會(huì)讀取默認(rèn)路徑下的配置文件：/usr/local/nginx/conf/nginx.conf。實(shí)際上，在沒(méi)有顯式指定nginx.conf配置文件路徑時(shí)，將打開(kāi)在configure命令執(zhí)行時(shí)使用--conf-path=PATH指定的nginx.conf文件（參見(jiàn)1.5.1節(jié)）。（2）另行指定配置文件的啟動(dòng)方式使用-c參數(shù)指定配置文件。例如：/usr/local/nginx/sbin/nginx-c/tmp/nginx.conf這時(shí)，會(huì)讀取-c參數(shù)后指定的nginx.conf配置文件來(lái)啟動(dòng)Nginx。（3）另行指定安裝目錄的啟動(dòng)方式使用-p參數(shù)指定Nginx的安裝目錄。例如：/usr/local/nginx/sbin/nginx-p/usr/local/nginx/（4）另行指定全局配置項(xiàng)的啟動(dòng)方式可以通過(guò)-g參數(shù)臨時(shí)指定一些全局配置項(xiàng)，以使新的配置項(xiàng)生效。例如：/usr/local/nginx/sbin/nginx-g"pid/var/nginx/test.pid;"上面這行命令意味著會(huì)把pid文件寫(xiě)到/var/nginx/test.pid中。-g參數(shù)的約束條件是指定的配置項(xiàng)不能與默認(rèn)路徑下的nginx.conf中的配置項(xiàng)相沖突，否則無(wú)法啟動(dòng)。就像上例那樣，類似這樣的配置項(xiàng)：pidlogs/nginx.pid，是不能存在于默認(rèn)的nginx.conf中的。另一個(gè)約束條件是，以-g方式啟動(dòng)的Nginx服務(wù)執(zhí)行其他命令行時(shí)，需要把-g參數(shù)也帶上，否則可能出現(xiàn)配置項(xiàng)不匹配的情形。例如，如果要停止Nginx服務(wù)，那么需要執(zhí)行下面代碼：/usr/local/nginx/sbin/nginx-g"pid/var/nginx/test.pid;"-sstop如果不帶上-g"pid/var/nginx/test.pid;"，那么找不到pid文件，也會(huì)出現(xiàn)無(wú)法停止服務(wù)的情況。（5）測(cè)試配置信息是否有錯(cuò)誤在不啟動(dòng)Nginx的情況下，使用-t參數(shù)僅測(cè)試配置文件是否有錯(cuò)誤。例如：/usr/local/nginx/sbin/nginx-t執(zhí)行結(jié)果中顯示配置是否正確。（6）在測(cè)試配置階段不輸出信息測(cè)試配置選項(xiàng)時(shí)，使用-q參數(shù)可以不把error級(jí)別以下的信息輸出到屏幕。例如：/usr/local/nginx/sbin/nginx-t-q（7）顯示版本信息使用-v參數(shù)顯示Nginx的版本信息。例如：/usr/local/nginx/sbin/nginx-v（8）顯示編譯階段的參數(shù)使用-V參數(shù)除了可以顯示Nginx的版本信息外，還可以顯示配置編譯階段的信息，如GCC編譯器的版本、操作系統(tǒng)的版本、執(zhí)行configure時(shí)的參數(shù)等。例如：/usr/local/nginx/sbin/nginx-V（9）快速地停止服務(wù)使用-sstop可以強(qiáng)制停止Nginx服務(wù)。-s參數(shù)其實(shí)是告訴Nginx程序向正在運(yùn)行的Nginx服務(wù)發(fā)送信號(hào)量，Nginx程序通過(guò)nginx.pid文件中得到master進(jìn)程的進(jìn)程ID，再向運(yùn)行中的master進(jìn)程發(fā)送TERM信號(hào)來(lái)快速地關(guān)閉Nginx服務(wù)。例如：/usr/local/nginx/sbin/nginx-sstop實(shí)際上，如果通過(guò)kill命令直接向nginxmaster進(jìn)程發(fā)送TERM或者INT信號(hào)，效果是一樣的。例如，先通過(guò)ps命令來(lái)查看nginxmaster的進(jìn)程ID：:ahf5wapi001:root>ps-ef|grepnginxroot108001002:27?00:00:00nginx:masterprocess./nginxroot1080110800002:27?00:00:00nginx:workerprocess接下來(lái)直接通過(guò)kill命令來(lái)發(fā)送信號(hào)：kill-sSIGTERM10800或者：kill-sSIGINT10800上述兩條命令的效果與執(zhí)行/usr/local/nginx/sbin/nginx-sstop是完全一樣的。（10）“優(yōu)雅”地停止服務(wù)如果希望Nginx服務(wù)可以正常地處理完當(dāng)前所有請(qǐng)求再停止服務(wù)，那么可以使用-squit參數(shù)來(lái)停止服務(wù)。例如：/usr/local/nginx/sbin/nginx-squit該命令與快速停止Nginx服務(wù)是有區(qū)別的。當(dāng)快速停止服務(wù)時(shí)，worker進(jìn)程與master進(jìn)程在收到信號(hào)后會(huì)立刻跳出循環(huán)，退出進(jìn)程。而“優(yōu)雅”地停止服務(wù)時(shí)，首先會(huì)關(guān)閉監(jiān)聽(tīng)端口，停止接收新的連接，然后把當(dāng)前正在處理的連接全部處理完，最后再退出進(jìn)程。與快速停止服務(wù)相似，可以直接發(fā)送QUIT信號(hào)給master進(jìn)程來(lái)停止服務(wù)，其效果與執(zhí)行-squit命令是一樣的。例如：kill-sSIGQUIT如果希望“優(yōu)雅”地停止某個(gè)worker進(jìn)程，那么可以通過(guò)向該進(jìn)程發(fā)送WINCH信號(hào)來(lái)停止服務(wù)。例如：kill-sSIGWINCH（11）使運(yùn)行中的Nginx重讀配置項(xiàng)并生效使用-sreload參數(shù)可以使運(yùn)行中的Nginx服務(wù)重新加載nginx.conf文件。例如：/usr/local/nginx/sbin/nginx-sreload事實(shí)上，Nginx會(huì)先檢查新的配置項(xiàng)是否有誤，如果全部正確就以“優(yōu)雅”的方式關(guān)閉，再重新啟動(dòng)Nginx來(lái)實(shí)現(xiàn)這個(gè)目的。類似的，-s是發(fā)送信號(hào)，仍然可以用kill命令發(fā)送HUP信號(hào)來(lái)達(dá)到相同的效果。kill-sSIGHUP（12）日志文件回滾使用-sreopen參數(shù)可以重新打開(kāi)日志文件，這樣可以先把當(dāng)前日志文件改名或轉(zhuǎn)移到其他目錄中進(jìn)行備份，再重新打開(kāi)時(shí)就會(huì)生成新的日志文件。這個(gè)功能使得日志文件不至于過(guò)大。例如：/usr/local/nginx/sbin/nginx-sreopen當(dāng)然，這與使用kill命令發(fā)送USR1信號(hào)效果相同。kill-sSIGUSR1（13）平滑升級(jí)Nginx當(dāng)Nginx服務(wù)升級(jí)到新的版本時(shí)，必須要將舊的二進(jìn)制文件Nginx替換掉，通常情況下這是需要重啟服務(wù)的，但Nginx支持不重啟服務(wù)來(lái)完成新版本的平滑升級(jí)。升級(jí)時(shí)包括以下步驟：1）通知正在運(yùn)行的舊版本Nginx準(zhǔn)備升級(jí)。通過(guò)向master進(jìn)程發(fā)送USR2信號(hào)可達(dá)到目的。例如：kill-sSIGUSR2這時(shí)，運(yùn)行中的Nginx會(huì)將pid文件重命名，如將/usr/local/nginx/logs/nginx.pid重命名為/usr/local/nginx/logs/nginx.pid.oldbin，這樣新的Nginx才有可能啟動(dòng)成功。2）啟動(dòng)新版本的Nginx，可以使用以上介紹過(guò)的任意一種啟動(dòng)方法。這時(shí)通過(guò)ps命令可以發(fā)現(xiàn)新舊版本的Nginx在同時(shí)運(yùn)行。3）通過(guò)kill命令向舊版本的master進(jìn)程發(fā)送SIGQUIT信號(hào)，以“優(yōu)雅”的方式關(guān)閉舊版本的Nginx。隨后將只有新版本的Nginx服務(wù)運(yùn)行，此時(shí)平滑升級(jí)完畢。（14）顯示命令行幫助使用-h或者-?參數(shù)會(huì)顯示支持的所有命令行參數(shù)。1.7小結(jié)本章介紹了Nginx的特點(diǎn)以及在什么場(chǎng)景下需要使用Nginx，同時(shí)介紹了如何獲取Nginx以及如何配置、編譯、安裝運(yùn)行Nginx。本章還深入介紹了最為復(fù)雜的configure過(guò)程，這部分內(nèi)容是學(xué)習(xí)本書(shū)第二部分和第三部分的基礎(chǔ)。第2章Nginx的配置Nginx擁有大量官方發(fā)布的模塊和第三方模塊，這些已有的模塊可以幫助我們實(shí)現(xiàn)Web服務(wù)器上很多的功能。使用這些模塊時(shí)，僅僅需要增加、修改一些配置項(xiàng)即可。因此，本章的目的是熟悉Nginx的配置文件，包括配置文件的語(yǔ)法格式、運(yùn)行所有Nginx服務(wù)必須具備的基礎(chǔ)配置以及使用HTTP核心模塊配置靜態(tài)Web服務(wù)器的方法，最后還會(huì)介紹反向代理服務(wù)器。通過(guò)本章的學(xué)習(xí)，讀者可以：熟練地配置一個(gè)靜態(tài)Web服務(wù)器；對(duì)影響Web服務(wù)器性能的各個(gè)配置項(xiàng)有深入的理解；對(duì)配置語(yǔ)法有全面的了解。通過(guò)互聯(lián)網(wǎng)或其他途徑得到任意模塊的配置說(shuō)明，然后可通過(guò)修改nginx.conf文件來(lái)使用這些模塊的功能。2.1運(yùn)行中的Nginx進(jìn)程間的關(guān)系在正式提供服務(wù)的產(chǎn)品環(huán)境下，部署Nginx時(shí)都是使用一個(gè)master進(jìn)程來(lái)管理多個(gè)worker進(jìn)程，一般情況下，worker進(jìn)程的數(shù)量與服務(wù)器上的CPU核心數(shù)相等。每一個(gè)worker進(jìn)程都是繁忙的，它們?cè)谡嬲靥峁┗ヂ?lián)網(wǎng)服務(wù)，master進(jìn)程則很“清閑”，只負(fù)責(zé)監(jiān)控管理worker進(jìn)程。worker進(jìn)程之間通過(guò)共享內(nèi)存、原子操作等一些進(jìn)程間通信機(jī)制來(lái)實(shí)現(xiàn)負(fù)載均衡等功能（第9章將會(huì)介紹負(fù)載均衡機(jī)制，第14章將會(huì)介紹負(fù)載均衡鎖的實(shí)現(xiàn)）。部署后Nginx進(jìn)程間的關(guān)系如圖2-1所示。Nginx是支持單進(jìn)程（master進(jìn)程）提供服務(wù)的，那么為什么產(chǎn)品環(huán)境下要按照master-worker方式配置同時(shí)啟動(dòng)多個(gè)進(jìn)程呢？這樣做的好處主要有以下兩點(diǎn)：·由于master進(jìn)程不會(huì)對(duì)用戶請(qǐng)求提供服務(wù)，只用于管理真正提供服務(wù)的worker進(jìn)程，所以master進(jìn)程可以是唯一的，它僅專注于自己的純管理工作，為管理員提供命令行服務(wù)，包括諸如啟動(dòng)服務(wù)、停止服務(wù)、重載配置文件、平滑升級(jí)程序等。master進(jìn)程需要擁有較大的權(quán)限，例如，通常會(huì)利用root用戶啟動(dòng)master進(jìn)程。worker進(jìn)程的權(quán)限要小于或等于master進(jìn)程，這樣master進(jìn)程才可以完全地管理worker進(jìn)程。當(dāng)任意一個(gè)worker進(jìn)程出現(xiàn)錯(cuò)誤從而導(dǎo)致coredump時(shí)，master進(jìn)程會(huì)立刻啟動(dòng)新的worker進(jìn)程繼續(xù)服務(wù)。·多個(gè)worker進(jìn)程處理互聯(lián)網(wǎng)請(qǐng)求不但可以提高服務(wù)的健壯性（一個(gè)worker進(jìn)程出錯(cuò)后，其他worker進(jìn)程仍然可以正常提供服務(wù)），最重要的是，這樣可以充分利用現(xiàn)在常見(jiàn)的SMP多核架構(gòu)，從而實(shí)現(xiàn)微觀上真正的多核并發(fā)處理。因此，用一個(gè)進(jìn)程（master進(jìn)程）來(lái)處理互聯(lián)網(wǎng)請(qǐng)求肯定是不合適的。另外，為什么要把worker進(jìn)程數(shù)量設(shè)置得與CPU核心數(shù)量一致呢？這正是Nginx與Apache服務(wù)器的不同之處。在Apache上每個(gè)進(jìn)程在一個(gè)時(shí)刻只處理一個(gè)請(qǐng)求，因此，如果希望Web服務(wù)器擁有并發(fā)處理的請(qǐng)求數(shù)更多，就要把Apache的進(jìn)程或線程數(shù)設(shè)置得更多，通常會(huì)達(dá)到一臺(tái)服務(wù)器擁有幾百個(gè)工作進(jìn)程，這樣大量的進(jìn)程間切換將帶來(lái)無(wú)謂的系統(tǒng)資源消耗。而Nginx則不然，一個(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à)是最小的。圖2-1部署后Nginx進(jìn)程間的關(guān)系舉例來(lái)說(shuō)，如果產(chǎn)品中的服務(wù)器CPU核心數(shù)為8，那么就需要配置8個(gè)worker進(jìn)程（見(jiàn)圖2-2）。圖2-2worker進(jìn)程的數(shù)量盡量與CPU核心數(shù)相等如果對(duì)路徑部分都使用默認(rèn)配置，那么Nginx運(yùn)行目錄為/usr/local/nginx，其目錄結(jié)構(gòu)如下。|sbin||nginx|conf||koi-win||koi-utf||win-utf||mime.types||mime.types.default||fastcgi_params||fastcgi_params.default||fastcgi.conf||fastcgi.conf.default||uwsgi_params||uwsgi_params.default||scgi_params||scgi_params.default||nginx.conf||nginx.conf.default|logs||error.log||access.log||nginx.pid|html||50x.html||index.html|client_body_temp|proxy_temp|fastcgi_temp|uwsgi_temp|scgi_temp2.2Nginx配置的通用語(yǔ)法Nginx的配置文件其實(shí)是一個(gè)普通的文本文件。下面來(lái)看一個(gè)簡(jiǎn)單的例子。usernobody;worker_processes8;error_log/var/log/nginx/error.logerror;#pidlogs/nginx.pid;events{useepoll;worker_connections50000;}http{includemime.types;default_typeapplication/octet-stream;log_formatmain'$remote_addr[$time_local]"$request"''$status$bytes_sent"$http_referer"''"$http_user_agent""$http_x_forwarded_for"';access_loglogs/access.logmainbuffer=32k;…｝在這段簡(jiǎn)短的配置代碼中，每一行配置項(xiàng)的語(yǔ)法格式都將在2.2.2節(jié)介紹，出現(xiàn)的events和http塊配置項(xiàng)將在2.2.1節(jié)介紹，以#符號(hào)開(kāi)頭的注釋將在2.2.3節(jié)介紹，類似“buffer=32k”這樣的配置項(xiàng)的單位將在2.2.4節(jié)介紹。2.2.1塊配置項(xiàng)塊配置項(xiàng)由一個(gè)塊配置項(xiàng)名和一對(duì)大括號(hào)組成。具體示例如下：events{…}http{upstreambackend{server:8080;}gzipon;server{…location/webstatic{gzipoff;}}}上面代碼段中的events、http、server、location、upstream等都是塊配置項(xiàng)，塊配置項(xiàng)之后是否如“l(fā)ocation/webstatic{...}”那樣在后面加上參數(shù)，取決于解析這個(gè)塊配置項(xiàng)的模塊，不能一概而論，但塊配置項(xiàng)一定會(huì)用大括號(hào)把一系列所屬的配置項(xiàng)全包含進(jìn)來(lái)，表示大括號(hào)內(nèi)的配置項(xiàng)同時(shí)生效。所有的事件類配置都要在events塊中，http、server等配置也遵循這個(gè)規(guī)定。塊配置項(xiàng)可以嵌套。內(nèi)層塊直接繼承外層塊，例如，上例中，server塊里的任意配置都是基于http塊里的已有配置的。當(dāng)內(nèi)外層塊中的配置發(fā)生沖突時(shí)，究竟是以內(nèi)層塊還是外層塊的配置為準(zhǔn)，取決于解析這個(gè)配置項(xiàng)的模塊，第4章將會(huì)介紹http塊內(nèi)配置項(xiàng)沖突的處理方法。例如，上例在http模塊中已經(jīng)打開(kāi)了“gzipon;”，但其下的location/webstatic又把gzip關(guān)閉了：gzipoff;，最終，在/webstatic的處理模塊中，gzip模塊是按照gzipoff來(lái)處理請(qǐng)求的。2.2.2配置項(xiàng)的語(yǔ)法格式從上文的示例可以看出，最基本的配置項(xiàng)語(yǔ)法格式如下：配置項(xiàng)名配置項(xiàng)值1配置項(xiàng)值2…;下面解釋一下配置項(xiàng)的構(gòu)成部分。首先，在行首的是配置項(xiàng)名，這些配置項(xiàng)名必須是Nginx的某一個(gè)模塊想要處理的，否則Nginx會(huì)認(rèn)為配置文件出現(xiàn)了非法的配置項(xiàng)名。配置項(xiàng)名輸入結(jié)束后，將以空格作為分隔符。其次是配置項(xiàng)值，它可以是數(shù)字或字符串（當(dāng)然也包括正則表達(dá)式）。針對(duì)一個(gè)配置項(xiàng)，既可以只有一個(gè)值，也可以包含多個(gè)值，配置項(xiàng)值之間仍然由空格符來(lái)分隔。當(dāng)然，一個(gè)配置項(xiàng)對(duì)應(yīng)的值究竟有多少個(gè)，取決于解析這個(gè)配置項(xiàng)的模塊。我們必須根據(jù)某個(gè)Nginx模塊對(duì)一個(gè)配置項(xiàng)的約定來(lái)更改配置項(xiàng)，第4章將會(huì)介紹模塊是如何約定一個(gè)配置項(xiàng)的格式。最后，每行配置的結(jié)尾需要加上分號(hào)。注意如果配置項(xiàng)值中包括語(yǔ)法符號(hào)，比如空格符，那么需要使用單引號(hào)或雙引號(hào)括住配置項(xiàng)值，否則Nginx會(huì)報(bào)語(yǔ)法錯(cuò)誤。例如：log_formatmain'$remote_addr-$remote_user[$time_local]"$request"';2.2.3配置項(xiàng)的注釋如果有一個(gè)配置項(xiàng)暫時(shí)需要注釋掉，那么可以加“#”注釋掉這一行配置。例如：#pidlogs/nginx.pid;2.2.4配置項(xiàng)的單位大部分模塊遵循一些通用的規(guī)定，如指定空間大小時(shí)不用每次都定義到字節(jié)、指定時(shí)間時(shí)不用精確到毫