Nginx之一nginx特性及基礎概念

Nginx的官方站點：www.nginx.org

Nginx：是engine X的簡寫

　　有兩個分支比較流行：

•    Tengine：淘寶對Nginx作了不少改進，作了不少研發。並且將其開源了，這個項目就是Tengine。
•    Registry

　　Nginx在研發時調用了libevent這個組件，libevent是一個通用的高性能的網絡庫。它裏邊實現了epoil()這麼一個調用，epoil()其實就是基於事件驅動的event模型的一個開發好的庫文件。所以咱們要想實現事件驅動模型，直接調用epoil()就能夠了。而Nginx就調用了libevent這個高性能網絡庫中的epoil()，雖然咱們說調用epoil()，事實上Nginx對這些衆多的網絡併發編程庫支持的普遍程度還應該是超出想象的。

 

1、Nginx的特性

• 模塊化設計、較好的擴展性；

    所以做爲程序員能夠爲Nginx設計第三方模塊，不過與httpd不一樣的是，Nginx早期包括如今的版本雖然是模塊化的，也就意味着說咱們能夠自行開發第三方模塊對Nginx進行擴展，可是Nginx不支持模塊動態裝卸載的，也就是說編譯的時候只能靜態直接編譯進Nginx並且隨Nginx的啓動而啓動，即模塊編譯好以後能夠直接使用，但只能直接編譯成Nginx組成部分，只要Nginx啓動，那麼這個模塊就必定會啓動，它不支持動態裝卸載。可是Tengine對Nginx的改進使得Tengine支持模塊動態裝卸載。

• 高可靠性

    這是已經通過市場普遍驗證的；它的高可靠性是靠其特殊的工做機制來實現的，其高可靠性依賴於主控進程與工做進程或工做線程的架構來實現的。雖然形容爲特殊可是其實httpd也是這麼工做的。Nginx的組成部分其實是由一個主控進程master加多個子進程worker共同組成的，它有一個主控進程master，主控進程並不負責接收並響應任何用戶請求，主控進程負責生成多個工做進程worker。其主控進程主要負責讀取並驗證即解析配置文件、建立綁定或關閉套接字、以及啓動或終止維護worker進程的個數、還有無需重啓進程讓新配置文件中的新配置加載甚至於完成平滑版本升級等等。而worker子進程有多種種類，有的worker是實現緩存加載的，這在其反向代理模式中才有用、而有些是負責響應用戶請求說白了就是接收傳入並處理客戶端的鏈接請求的、此外worker進程中還有一種進程叫作Cache Manager用來實現緩存管理。

• 低內存消耗

    因爲Nginx是使用一個內存響應n個請求的，因此它對內存的消耗很是低，有人作過統計說1w個保持鏈接keep-alive狀態或模式下的connection，Nginx只須要消耗2.5M內存來維護；

• 支持熱部署

    所謂熱部署指的是若是咱們的配置文件更新了不用重啓Nginx，新配置文件就可以生效了。甚至於Nginx的版本更新了，如如今用的是1.4的版本想升級到1.6，1.4的版本不用停機，1.6的慢慢就會切上去了。事後等1.6的切換完成了可讓1.4的再下線。

    因此他支持熱部署，所以這裏的熱部署指的是不停機而更新配置文件或者是更換日誌文件即日誌文件的滾動也包括升級程序版本等等都能實現。這就是熱部署的功能。

• 支持事件驅動機制、AIO（異步IO）、mmap（內存映射機制）；

 

2、Nginx的基本功能

　　雖然稱Nginx爲一個Web服務器，可是事實上它能支持多種功能，如：

• 靜態資源的web服務器，能緩存打開的文件描述符；

    最根本的它是靜態資源的web服務器而不是一個應用程序服務器。說白了若是打開一個文件這個文件對應的描述符信息它可以緩存下來，因此從而使得咱們再次訪問同一個文件時打開的性能會被提高。

• http、smtp、pop3協議的反向代理服務器；

    所以它既能夠做爲一個WEB服務器工做也能夠做爲一個WEB服務器的反向代理服務器工做。那反向代理服務器是什麼呢？咱們簡單作一下介紹。

    原本咱們Web服務器的工做模式是在瀏覽器或客戶端（User Agent）和服務器端之間直接進行的，全部的用戶請求是直接從User Agent經過網絡提交給Web服務器的。響應也是由Web服務器直接響應給客戶端瀏覽器的。可是這樣一來，用戶將直接面對Web服務器，或者換句話來說，Web服務器將直接面對衆多的客戶端，那也就意味着Web服務器本身記得負責創建鏈接維持鏈接還得負責處理用戶請求，這樣會使得Web服務器壓力過大。

　　更重要的是，有些用戶可能會攻擊Web服務器。就像此前作nat同樣，若是咱們可以把用戶和服務器之間加一個隔離層也照樣能讓用戶請求可以到達Web服務器是否是可能會更好？所以這樣一來咱們能夠再Web服務器的前端放一個主機，咱們能夠把這個主機稱爲代理。

　　什麼叫代理呢？代理即它把本身聲稱爲叫Web服務器，可是事實上它不是。全部用戶請求直接到達給這個代理主機，這個主機本身也監聽在80端口上也可以接受http的請求，但它本身並不負責提供任何內容，而是當用戶請求到達這個服務器後，這個服務器本身負責把用戶請求接進用戶空間，由於他有一個進程，注意，它也有一個服務進程。這個服務進程稱爲代理進程，他解析用戶請求而且判斷一下這個客戶端是否是容許訪問的，若是不是，一解析以後直接拒絕了。這個請求甚至就不能到達Web服務器的。若是咱們容許它訪問，這個時候它也不會把用戶的請求直接扔給後端服務器，而是它本身把用戶的請求再改成封裝成另一種樣子然後再向後端服務器發送。好比咱們要發一個快遞因而咱們本身作了一個包裝，這個包裝扔給快遞公司了，好比像什麼順豐，扔給快遞公司以後快遞公司須要打包，空運也好陸運也罷反正得幫你運過去，可是順豐認爲你的包裝不夠安全，運輸過程中可能會致使郵件損壞因此它把你的封裝通通拆掉，再從新打包成它們認爲安全可靠的封裝，因此就這樣作了改換。

　　所以當用戶請求到達之後，這個服務器把用戶請求分析完之後發現是可靠的，沒問題，我能夠幫你發給Web服務器讓Web服務器進行響應，注意它本身沒有任何內容而是它再一次把用戶請求從新封裝起來發給後端服務器。那這時候在後端服務器看來請求的發出者是中間這臺主機，由於真正的請求是由他發出的，包括源地址也是中間服務器的地址，因此這樣一來它就徹底隔離的客戶端和後端服務器。也就是說，它可以聲稱本身是Web服務器，接收用戶對Web的請求，可是卻又不負責提供任何內容而是轉而把這個用戶請求本身從新封裝後交給後端服務器從後端服務器取回內容。可是各位應該知道，從後端服務器取回內容後，咱們本身對取回的內容沒有任何欲求，因此他帶來的結果就是它會把這個取到的內容再一次把響應報文響應給客戶端。因此客戶端一看它向這個服務器發了請求服務器也響應給它了，可是事實上中間這臺服務器並無響應任何內容，它只是代爲到後端服務器去取相關內容的。可是它把本身扮演成的確是那臺服務器的樣子，因此咱們說這叫作反向代理。

　　而反代是能夠n級的，即反向代理代理的也不是WEB服務器，它是另外更高一級的或更上一層的反向代理，能夠代理n次。可是咱們說過http協議當中有一個請求方法是TRACE，TRACE方法就是探測從請求這到最終服務器之間到底中間通過了哪些代理服務器。這些代理就稱爲反向代理。以下圖：

　　那什麼是正向代理呢？正向代理與反向代理相似，注意，反向代理一般只爲一個或有限的一部分網站提供反代。但正向代理指的是，用戶不管訪問任何網站，都把對網站的請求提交給代理主機，代理主機本身不管用戶請求的是什麼網站，都本身做爲客戶端到互聯網上去聯繫那臺服務器，而且把取到的結果直接在本地封裝之後或者在本地構建之後響應給客戶端。因此所謂正向代理指的是它主要表明客戶端請求任何網站；所謂反向代理服務器指的是它只是代爲接收用戶請求而且自行讓到某些或者某個有限的服務器上去取那個內容的，而不是到任何網站服務器去內容。因此反代主要是把本身扮演成某個特定服務器的樣子，而正向代理是把本身扮演成全部服務器的樣子，能夠這麼去理解。

　　關於代理的目的，不光只是代理、不光是隔離它還有加速的做用，代理服務器還能夠在本地提供緩存，剛纔咱們說過代理服務器本身到原始服務器上取到內容之後就構建了響應報文響應給請求者了。可是這樣子當客戶端請求同一個內容時他還得再來一遍，那爲了不這個過程，對於某靜態內容不常常發生改變的內容，咱們的代理服務器能夠取到內容之後先緩存在本地。注意，緩存在本地的時候它是基於鍵值關係緩存的，有可能直接緩存在內存中，鍵一般是用戶請求的URL，而值一般是對應的數據流，因此當同一個用戶甚至是不一樣用戶來請求同一段內容時，咱們的代理服務器若是發現這個內容是能夠被緩存，並且緩存還沒有失效的話，那麼他就從緩存中直接取得這個結果返回給客戶端了，而不會向上遊服務器或原始服務器發請求的。像這種他可以起到加速的做用而且極大的下降了或者減輕了後端服務器的壓力。這就是所謂的反向代理。而Nginx能做爲http、smtp、pop3這三種協議的反向代理，不光是Web，可是目前來看，衆多的應用場景都是用在http協議上，smtp或POP被Nginx拿來反代的是很鮮見的。

• 支持緩存加速、負載均衡機制

    剛纔說過，緩存是用來加速的。

    同時它還甚至於支持負載均衡機制，所謂負載均衡指的是在反代時後端的主機能夠不止一個。若後端主機只有一個，用戶請求直接交給後端，可是後端服務器實在是太忙了，扛不住，由於它有多是提供動態內容的，基於cgi模塊或fastcgi模型，有多是一個httpd服務器，直接提供動態的腳本，向php內容提供。而前端服務器做爲Nginx來說，能夠輕易扛得住1萬個併發請求，請求鏈接進來它可以幫你接進來。可是它把每個請求都轉發給後端服務器，一個服務器最多併發到1千個就至關不錯了，若是實在扛不住，怎麼辦呢？

    能夠多加幾個後端服務器，所以，它能夠把一部分用戶請求發到第一臺服務器，另一部分發到第二個，在一部分發到第三個服務器上。因此使得衆多前端用戶請求被分發至後端多臺主機上來了，這就是一種負載均衡機制。而前面這臺主機既是代理同時又是一個負載均衡調度器。可是做爲調度器負載均衡時，和只反代一個主機時，它們兩個所須要解決的問題其實它的複雜度是相去甚遠的。

    爲何呢？各位能夠明白，咱們給予負載均衡機制時，若是第一個用戶過來請求時，假設這是一個電商站點，咱們給它轉發到第一臺服務器上去了。它在第一個服務器上登陸了而後再購物車中加了一堆商品，你們知道，http協議是無狀態的，過一會鏈接斷開，他一刷新，又被從新分發至第二臺主機上來了。第二臺主機上沒有它的購物車，也沒有它的相關信息。那所以這顯然是沒辦法接受的，因此一旦要支持負載均衡機制，那麼session保持，就是此前用戶曾經創建的會話如何執行並進行保持將成爲一個很是重要亟待解決的問題。

    那如何解決這個問題，咱們有多種方案，後面講到負載均衡時會詳述這裏的解決方案。但無論怎麼講，各位應該知道，這是Nginx另外的基本功能，它既能實現緩存加速又能實現負載均衡。固然緩存加速也主要是在反代時實現，負載均衡亦是如此。

• 支持fastcgi協議，uWSGI（Python）等

    那也就意味着，可以跟基於fpm模式工做的php服務器結合起來提供LNMP。LNMP指的是Nginx、MariaDB、PHP等相關對應的結合。其實除了fastcgi以外還有像uWSGI協議實現跟Python語言所研發的Web服務器應用程序進行交互等等。

• 支持模塊化（可是是非DSO機制的）、過濾器（用戶能夠定義過濾器只對某些內容進行特殊處理，像zip可以實現對特定文本進行壓縮）、SSI（服務器端包含）機制、圖像的大小調整（在訪問一個電商站點時，它總是給咱們一些圖片，而後將鼠標放上去它可以自動擴大爲一個清晰的高清大圖給咱們展現等等）；
• 支持SSL；

    從而可以提供https服務；

 

3、Nginx的擴展功能

• 基於名稱和IP的虛擬主機；

    固然它也支持基於端口的虛擬主機；

• 支持keepalive；
• 支持平滑升級；
• 定製訪問日誌、支持使用日誌緩衝區提升日誌緩衝性能；
• 支持url rewrite；
• 支持路徑別名；
• 支持基於IP及用戶的訪問控制；

    Nginx基於用戶的訪問控制須要藉助於httpd的htpassword來實現。

• 支持速率限制，支持併發數限制；

    說白了就是來自於同一個IP咱們最多可以發起幾個併發鏈接請求，同時來自於同一個IP最多可以發起多大的訪問速率或者我給你傳輸數據時速率最多爲多少等等。

    事實上，Nginx有的功能，httpd都有，而httpd有的Nginx未必有，因此目前來看，Nginx取代不了httpd。

 

4、Nginx的基本架構（基本架構特性）

• Nginx是由一個master進程，稱爲主進程，負責生成一個或多個worker進程或線程

　　因此它的工做模式咱們能夠理解爲是這樣的：

　　Nginx是由一個master進程，稱爲主進程，負責生成一個或多個worker進程或線程，這些worker進程纔是真正去負責去接收並處理用戶請求的。

    那若是基於反代的話它還可以基於反代的Cache來實現加速，而既然有Cache了，你們知道緩存它總然會有一個時刻會失效的，每個緩存都有一個存活期限，那所以Cache Loader負責加載緩存，而Cache manager負責過時以及清理緩存等。

    那麼事實上worker與本地進程磁盤IO是支持AIO、mmap（內存映射）、各類高級IO機制、甚至還支持sendfile機制。

    另外它還支持http協議、fastcgi協議、memcache等等跟各類後端存儲進行打交道，它還能夠做爲反代向後進行打交道的。

    而此前提到的幾個Nginx特性此處也有展現：事件驅動、異步、非阻塞。

• 支持事件驅動，支持epoll、kqueue、/dev/poll機制，並且支持默認使用邊緣觸發機制；

    epoll機制是Linux上實現的事件驅動，可是若是使用的是BSD或者是Unix的話就不必定了。若是使用的是BSD則使用的是kqueue機制，若是是Servers的話，則用到的是/dev/poll。epoll、kqueue、/dev/poll這三個都是事件驅動模型，第一個是Linux上用的，第二個是BSD上用的，第三個是Servers上用的。但它們都是實現了相似的功能，而Nginx幾乎都支持。

　　另外IO複用的時候，它支持select、poll、rt signal，也叫IO複用器。

• 支持sendfile、sendfile64；

　　sendfile默認狀況下只能發送很小的文件可能最大不會超過幾個K，而sendfile64能夠支持更大的文件，能夠在內核中直接實現響應。它們的大小上限是有要求的。

• 支持AIO；
• 支持mmap

 

sendfile：

　　做爲一個靜態內容來說，當用戶請求進來時它必定要先進入內核，由於用戶的請求要先進入網卡設備。到達網卡設備後這個請求會經過註冊監聽在80端口上的內核套接字綁定，根據用戶請求的目標端口從而使得實現向用戶空間的Web服務器進行轉發。WEB服務器收到請求後發現用戶請求了某一個靜態資源，因而它向內核發起IO請求，內核負責把文件從磁盤加載進內核內存，然後從內核內存複製給進程內存。接着進程接下來就應該響應這個用戶請求了，那怎麼響應啊？

    構建響應報文，內容又從進程內存發往內核內存，由於不發往內存它怎麼可以經過網卡響應給客戶端，而咱們說過能調用網卡的只有內核，因此它又一次發起IO調用，只不過這一次IO是網絡IO而不是磁盤IO。發起調用時會把數據從本身的進程內存空間發往內核內存空間，放到網卡發送隊列中去進而經過網卡設備發出去了。

    在這個過程中，咱們的數據是怎麼走的？數據的走向，首先從磁盤到內核，從內核到用戶空間，從用戶空間又回到內核了。其實沒有作什麼改變，直接響應過去了，除了加了一個響應報文以外就發過去了。咱們能夠發現這兩次IO過程除了白白浪費時間是沒有任何更好的效果的。那咱們能不能這樣，當這個資源從內核取得以後直接就從內核響應給客戶端得了，數據從內核到磁盤內存然後直接構建一個響應報文直接響應給客戶端了。而這種機制就叫作sendfile。

　　固然，sendfile並非一種多麼新鮮的機制，httpd也支持，不光是Nginx。

 

5、Nginx的工做模式

　　它與前面對應的httpd的prefork、worker、event相比較而言，它的模式就是：

　　非阻塞、事件驅動、由一個master進程生成多個worker線程，每一個worker響應n個請求。

    因此若是做爲Web服務器而言，他整體可以支持的響應併發數等於worker * n；若是生成了10個worker，每一個worker能響應1萬個，那一共就能夠響應10萬個。固然了，Nginx沒有這麼大的能力，由於每個請求或鏈接進來咱們都得給它一個套接字，所以套接字所謂TCP來說最大數量端口也只有65535個，在考慮到其它服務在用，它系統在保留一些，因此能使用5萬個就不錯了。所以Nginx沒準在有些極端場景中，聽說有人曾經使用Nginx最大支持單機併發達到5.2萬個。雖然這是理論值，可是國內有人讓它很輕鬆支持3萬個是沒問題的。再多就有困難了。

    不過還有特別強調的是，在反代模型下，有可能會更少。

 

6、Nginx的模塊類型

    Nginx剛纔說過它是模塊化的，所以有衆多模塊，那模塊類型有哪些呢？無非就這樣幾個：（在官方文檔中是這麼分類的）

• 核心模塊
• Standard HTTP modules（標準的http協議模塊）
• Optional HTTP modules（可選的http協議模塊）
• Mail modules
• 3rd party modules

    注意，前四種模塊Nginx都自帶，第五種模塊，也就是所謂的第三方模塊咱們須要在編譯Nginx的時候本身手動指定模塊在何處，本身手動指明模塊文件。然後在編譯時才能把它編譯成Nginx的組成部分。

 

7、Nginx的安裝方法

    Nginx已然成爲一個很是流行的Web服務器解決方案了，因此Nginx自己雖然沒有直接被收入進咱們CentOS系統，但也已經被收入進EPEL源了。

使用yum查看是否有相關的包：

安裝方法：

• 源碼：編譯安裝；
• 製做好的程序包：如rpm包、deb包；

 

    此處先演示一下如何源碼編譯Nginx。由於不一樣的公司對於Nginx的定製安裝是有着不一樣要求的。

下載源碼包：

編譯安裝程序包時，須要提供好最基本的開發環境。

　　注意：Nginx哪怕已經提供了開發環境時，也會有可能不會自動安裝的一個依賴的軟件包叫pcre-devel

　　說明：它要用到pcre-devel來實現poll擴展的這麼一種表達式以實現URL重寫。通常來說，URL重寫的功能若是咱們須要用到，就有可能用到pcre-devel，因此建議把這個安裝上。

 

查看配置選項：

　　選項說明：

--prefix=PATH：默認安裝路徑
--sbin-path=PATH：Nginx主程序的安裝路徑
--conf-path=PATH：主配置文件的路徑
--error-log-path=PATH：錯誤日誌路徑
--pid-path=PATH：pid文件路徑
--lock-path-PATH：鎖文件路徑
--user=USER：Nginx啓動後它的worker會以哪一個普通用戶的身份來運行，通常來說工做線程都應該以普通用戶的身份運行。
--group=GROUP
--with-…：表示啓用這個功能的，須要注意的是，提示爲with表示默承認能沒啓用；要啓用使用with；
--without-…：表示禁用這些功能的，而提示爲without的表示默認啓用了，要想禁用使用without；
--http-client-body-temp-path=PATH：http協議若是對方使用的是PUT或POST方式請求，客戶端會提交一些內容過來，這個內容經過網絡傳輸一些數據它是流式化的，
　　　　　　　　　　　　　　　　　　　　 是一個一個數據傳過來的。所以若是傳輸的數據很大的話，客戶端上傳一個2G的數據咱們不能將其都放在內存中等待接受。
　　　　　　　　　　　　　　　　　　　　 因此咱們能夠把客戶端上傳的內容先放在一個臨時目錄中因此這是咱們定義臨時目錄位置的。因此這是客戶端提交數據時臨時存放的文件的路徑。
--http-proxy-temp-path=PATH：做爲代理服務器時代理內容，由於代理服務器咱們要從服務器取得內容在本地作處理之後在打包給客戶端，他也須要用到一個臨時目錄。
--http-fastcgi-temp-path=PATH：fastcgi協議；
--http-uwsgi-temp-path=PATH：uwsgi協議；
--http-scgi-temp-path=PATH：scgi協議
   注意：上述協議在反代時也都各自須要一些工做空間，咱們能夠指定它們的工做時臨時使用的臨時路徑。不指定也沒有關係，它本身會找一個位置當成臨時路徑的。
--with-pcre：支持URL重寫時，基於pcre可以支持更強大的正則表達式引擎；
--with-openssl=DIR：支持使用openssl，僅用於指明openssl在什麼地方的，其實咱們要啓用對https的支持要是用的是—with-http-ssl_module模塊的，
　　　　　　　　　　　 默認是沒啓用的，須要使用with啓用。

 

編譯安裝

建立用戶用於運行Nginx進程：

[root@localhost nginx-1.6.3]# ./configure --prefix=/usr/local/nginx --conf-path=/etc/nginx/nginx.conf --user=nginx --group=nginx --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx/nginx.pid --lock-path=/var/lock/nginx.lock --with-http_ssl_module --with-http_stub_status_module --with-http_gzip_static_module --with-http_flv_module --with-http_mp4_module --http-client-body-temp-path=/var/tmp/nginx/client --http-proxy-temp-path=/var/tmp/nginx/proxy --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi

　　注意：爲了可以便於實現未來當系統損壞時，重裝系統後配置文件存在有兩種途徑能夠解決這個問題：要麼放在etc下，未來得按期備份；要麼就乾脆不指定了就放在安裝路徑下這是最合理的作法。不少時候咱們未來安裝時並不會把它的配置文件路徑都指到/etc目錄下去，而就放在安裝目錄下。這樣會使得咱們未來遷移整個程序會變得很是容易。那此處仍然遵循風格，好比說爲了咱們未來使用時方便仍然指定爲/etc/nginx/nginx.conf，專門指定一個特定目錄。注意一旦把主配置文件指在此處，那咱們主配置文件所用到的其它輔助配置文件也都會放在同一個目錄下，因此咱們這裏打開一個單獨的目錄來指明。

    查看是否有程序監聽80端口，若沒有直接啓動便可：

測試訪問：

至此，安裝完成！

 

8、Nginx配置文件

　　worker_process：指定啓動的worker進程數；

    有配置指令，並且有些會有花括號，花括號表示這是一個配置段，只對其中一部份內容生效。其中有一部份內容是直接寫在配置文件中，頂格寫的。有一部分是events定義一個容器后里面能夠定義一部份內容；有一個是http甚至還有其它內容。

    因此整個Nginx的配置文件主要由這樣幾部分組成：

• main配置段：全局配置段；

    說白了就是對於其餘配置段都是有效的；

• event{}配置段：定義event模型的工做特性；
• http{}：定義http協議相關的配置；

    全部跟web服務相關的配置都只能定義在http配置段當中；

　　注意：Nginx的全部配置指令通常而言是不區分大小寫的，可是要以分號結尾。不然就是語法錯誤

　　語法格式：

　　directive value1 [value2…]

 

Nginx支持使用變量

    變量分爲兩類：

• 內置變量

　　內置變量是由模塊自帶的，每引入一個模塊，這個模塊都有可能提供一些新變量。因此模塊會提供內建變量的定義；那核心模塊提供一堆變量，其它模塊像標準的TCP/IP模塊也會提供一堆的變量。

• 自定義變量

　　在配置文件中使用set var_name value表示給它定義了一個變量並定義了一個值。然後咱們就能夠在配置文件的其餘位置進行調用了。

 

    其實，咱們要想可以配置Nginx就須要不斷的修改它的配置文件來實現，而它的配置文件剛纔咱們說過有主配置段、event配置段、http配置段組成。main配置段的指令配置很是多，Nginx的指令參數大概有上百個之多，咱們不可能一一去了解它，也不必一一去了解，只瞭解一些關鍵的就行。可是儘管這麼講，它的主配置段的指令大致能夠分爲四類：

• 用於調試、定位問題的指令；
• 正常運行必備的配置；
• 優化性能的配置；
• 事件相關的配置；

    注意：事實上，event也算做是main配置的組成部分，由於event那一段對全部的協議包括http、smtp等等也都同樣是生效的。

 

    接下來就對Nginx的每個指令功用或者是最核心的指令使用機制、功用來作介紹。其中主配置段的指令當中有不少個，講完以後接下來就將Nginx本身的配置，好比如何使用虛擬主機、如何後使用別名、如何定義location、如何定義URL重寫等等。