1.什麼是Nginx？
Nginx是一個高性能的HTTP和反向代理服務器,常用於做負載均衡服務器
2.爲什麼要用Nginx?
跨平臺、配置簡單
非阻塞、高併發連接：
處理2-3萬併發連接數，官方監測能支持5萬併發
內存消耗小：
開啓10個nginx才佔150M內存，Nginx採取了分階段資源分配技術
nginx處理靜態文件好,耗費內存少
內置的健康檢查功能：
如果有一個服務器宕機，會做一個健康檢查，再發送的請求就不會發送到宕機的服務器了。重新將請求提交到其他的節點上。
節省寬帶：
支持GZIP壓縮，可以添加瀏覽器本地緩存
穩定性高：
宕機的概率非常小
master/worker結構：
一個master進程，生成一個或者多個worker進程
接收用戶請求是異步的：
瀏覽器將請求發送到nginx服務器，它先將用戶請求全部接收下來，再一次性發送給後端web服務器，極大減輕了web服務器的壓力,一邊接收web服務器的返回數據，一邊發送給瀏覽器客戶端
網絡依賴性比較低，只要ping通就可以負載均衡
可以有多臺nginx服務器
3.爲什麼Nginx性能這麼高？
得益於它的事件處理機制：
異步非阻塞事件處理機制：運用了epoll模型，提供了一個隊列，排隊解決
4、爲什麼不使用多線程？
Apache Tomcat: 創建多個進程或線程，而每個進程或線程都會爲其分配cpu和內存（線程要比進程小的多，所以worker支持比perfork高的併發），併發過大會榨乾服務器資源。
Nginx: 採用單線程來異步非阻塞處理請求（管理員可以配置Nginx主進程的工作進程的數量）(epoll)，不會爲每個請求分配cpu和內存資源，節省了大量資源，同時也減少了大量的CPU的上下文切換。所以才使得Nginx支持更高的併發。
下面說一下Nginx是如何處理一個請求的呢？
首先，nginx在啓動時，會解析配置文件，得到需要監聽的端口與ip地址，然後在nginx的master進程裏面
先初始化好這個監控的socket(創建socket，設置addrreuse等選項，綁定到指定的ip地址端口，再listen)
然後再fork(一個現有進程可以調用fork函數創建一個新進程。由fork創建的新進程被稱爲子進程 )出多個子進程出來
然後子進程會競爭accept新的連接。此時，客戶端就可以向nginx發起連接了。當客戶端與nginx進行三次握手，與nginx建立好一個連接後
此時，某一個子進程會accept成功，得到這個建立好的連接的socket，然後創建nginx對連接的封裝，即ngx_connection_t結構體
爲什麼nginx可以採用異步非阻塞的方式來處理?
看看一個請求的完整過程:首先，請求過來，要建立連接，然後再接收數據，接收數據後，再發送數據。
具體到系統底層，就是讀寫事件，而當讀寫事件沒有準備好時，必然不可操作，如果不用非阻塞的方式來調用，那就得阻塞調用了，事件沒有準備好，那就只能等了，等事件準備好了，你再繼續吧。阻塞調用會進入內核等待，cpu就會讓出去給別人用了，對單線程的worker來說，顯然不合適，當網絡事件越多時，大家都在等待呢，cpu空閒下來沒人用，cpu利用率自然上不去了，更別談高併發了。好吧，你說加進程數，這跟apache的線程模型有什麼區別，注意，別增加無謂的上下文切換。所以，在nginx裏面，最忌諱阻塞的系統調用了。不要阻塞，那就非阻塞嘍。非阻塞就是，事件沒有準備好，馬上返回EAGAIN，告訴你，事件還沒準備好呢，你慌什麼，過會再來吧。好吧，你過一會，再來檢查一下事件，直到事件準備好了爲止，在這期間，你就可以先去做其它事情，然後再來看看事件好了沒。雖然不阻塞了，但你得不時地過來檢查一下事件的狀態，你可以做更多的事情了，但帶來的開銷也是不小的。
nginx支持的事件模型?
Nginx支持如下處理連接的方法（I/O複用方法），這些方法可以通過use指令指定。
● select– 標準方法。 如果當前平臺沒有更有效的方法，它是編譯時默認的方法。你可以使用配置參數 –with-select_module 和 –without-select_module 來啓用或禁用這個模塊。
● poll– 標準方法。 如果當前平臺沒有更有效的方法，它是編譯時默認的方法。你可以使用配置參數 –with-poll_module 和 –without-poll_module 來啓用或禁用這個模塊。
● kqueue– 高效的方法，使用於 FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X. 使用雙處理器的MacOS X系統使用kqueue可能會造成內核崩潰。
● epoll – 高效的方法，使用於Linux內核2.6版本及以後的系統。在某些發行版本中，如SuSE 8.2, 有讓2.4版本的內核支持epoll的補丁。
● rtsig – 可執行的實時信號，使用於Linux內核版本2.2.19以後的系統。默認情況下整個系統中不能出現大於1024個POSIX實時(排隊)信號。這種情況 對於高負載的服務器來說是低效的；所以有必要通過調節內核參數 /proc/sys/kernel/rtsig-max 來增加隊列的大小。可是從Linux內核版本2.6.6-mm2開始， 這個參數就不再使用了，並且對於每個進程有一個獨立的信號隊列，這個隊列的大小可以用 RLIMIT_SIGPENDING 參數調節。當這個隊列過於擁塞，nginx就放棄它並且開始使用 poll 方法來處理連接直到恢復正常。
● /dev/poll – 高效的方法，使用於 Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+.
● eventport – 高效的方法，使用於 Solaris 10. 爲了防止出現內核崩潰的問題， 有必要安裝這個 安全補丁。
在linux下面，只有epoll是高效的方法,epoll到底是如何高效的
Epoll是Linux內核爲處理大批量句柄而作了改進的poll。 要使用epoll只需要這三個系統調用：epoll_create(2)， epoll_ctl(2)， epoll_wait(2)。它是在2.5.44內核中被引進的(epoll(4) is a new API introduced in Linux kernel 2.5.44)，在2.6內核中得到廣泛應用。
epoll的優點?
● 支持一個進程打開大數目的socket描述符(FD)
select 最不能忍受的是一個進程所打開的FD是有一定限制的，由FD_SETSIZE設置，默認值是2048。對於那些需要支持的上萬連接數目的IM服務器來說顯 然太少了。這時候你一是可以選擇修改這個宏然後重新編譯內核，不過資料也同時指出這樣會帶來網絡效率的下降，二是可以選擇多進程的解決方案(傳統的 Apache方案)，不過雖然linux上面創建進程的代價比較小，但仍舊是不可忽視的，加上進程間數據同步遠比不上線程間同步的高效，所以也不是一種完 美的方案。不過 epoll則沒有這個限制，它所支持的FD上限是最大可以打開文件的數目，這個數字一般遠大於2048,舉個例子,在1GB內存的機器上大約是10萬左 右，具體數目可以cat /proc/sys/fs/file-max察看,一般來說這個數目和系統內存關係很大。
● IO效率不隨FD數目增加而線性下降
傳統的select/poll另一個致命弱點就是當你擁有一個很大的socket集合，不過由於網絡延時，任一時間只有部分的socket是”活躍”的，但 是select/poll每次調用都會線性掃描全部的集合，導致效率呈現線性下降。但是epoll不存在這個問題，它只會對”活躍”的socket進行操 作—這是因爲在內核實現中epoll是根據每個fd上面的callback函數實現的。那麼，只有”活躍”的socket纔會主動的去調用 callback函數，其他idle狀態socket則不會，在這點上，epoll實現了一個”僞”AIO，因爲這時候推動力在os內核。在一些 benchmark中，如果所有的socket基本上都是活躍的—比如一個高速LAN環境，epoll並不比select/poll有什麼效率，相 反，如果過多使用epoll_ctl,效率相比還有稍微的下降。但是一旦使用idle connections模擬WAN環境,epoll的效率就遠在select/poll之上了。
● 使用mmap加速內核與用戶空間的消息傳遞。
這 點實際上涉及到epoll的具體實現了。無論是select,poll還是epoll都需要內核把FD消息通知給用戶空間，如何避免不必要的內存拷貝就很 重要，在這點上，epoll是通過內核於用戶空間mmap同一塊內存實現的。而如果你想我一樣從2.5內核就關注epoll的話，一定不會忘記手工 mmap這一步的。
● 內核微調
這一點其實不算epoll的優點了，而是整個linux平臺的優點。也許你可以懷疑linux平臺，但是你無法迴避linux平臺賦予你微調內核的能力。比如，內核TCP/IP協 議棧使用內存池管理sk_buff結構，那麼可以在運行時期動態調整這個內存pool(skb_head_pool)的大小— 通過echo XXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函數的第2個參數(TCP完成3次握手 的數據包隊列長度)，也可以根據你平臺內存大小動態調整。更甚至在一個數據包面數目巨大但同時每個數據包本身大小卻很小的特殊系統上嘗試最新的NAPI網卡驅動架構。
(epoll內容，參考epoll_互動百科)
推薦設置worker的個數爲cpu的核數，在這裏就很容易理解了，更多的worker數，只會導致進程來競爭cpu資源了，從而帶來不必要的上下文切換。而且，nginx爲了更好的利用多核特性，提供了cpu親緣性的綁定選項，我們可以將某一個進程綁定在某一個核上，這樣就不會因爲進程的切換帶來cache的失效。像這種小的優化在nginx中非常常見，同時也說明了nginx作者的苦心孤詣。比如，nginx在做4個字節的字符串比較時，會將4個字符轉換成一個int型，再作比較，以減少cpu的指令數等等。
5、Nginx是如何處理一個請求的呢？
首先，nginx在啓動時，會解析配置文件，得到需要監聽的端口與ip地址，然後在nginx的master進程裏面,先初始化好這個監控的socket，再進行listen，然後再fork出多個子進程出來, 子進程會競爭accept新的連接。
此時，客戶端就可以向nginx發起連接了。當客戶端與nginx進行三次握手，與nginx建立好一個連接後，某一個子進程會accept成功，然後創建nginx對連接的封裝，即ngx_connection_t結構體，根據事件調用相應的事件處理模塊，如http模塊與客戶端進行數據的交換。
最後，nginx或客戶端來主動關掉連接，到此，一個連接就壽終正寢了
6. 正向代理,反向代理
正向代理總結就一句話：代理端代理的是客戶端
比如,國內訪問google會被牆擋住,但是可以通過訪問其他國家的服務器,達到訪問Google的結果
如果是正向代理的話,就是其他國家的服務器解決了牆的問題,將你的訪問直接轉發到Google上面
一個位於客戶端和原始服務器(origin server)之間的服務器，爲了從原始服務器取得內容，客戶端向代理髮送一個請求並指定目標(原始服務器)，然後代理向原始服務器轉交請求並將獲得的內容返回給客戶端。客戶端才能使用正向代理
反向代理總結就一句話：代理端代理的是服務端
反向代理就是你壓根就不知道你要訪問的地址是哪裏,但是一去訪問一個服務器,但是這個服務器其實是去訪問其他的服務器,得到數據後返回給你,你甚至不知道數據來源
反向代理（Reverse Proxy）方式是指以代理服務器來接受internet上的連接請求，然後將請求，發給內部網絡上的服務器並將從服務器上得到的結果返回給internet上請求連接的客戶端，此時代理服務器對外就表現爲一個反向代理服務器
7.動靜態分離
動態資源、靜態資源分離是讓動態網站裏的動態網頁根據一定規則把不變的資源和經常變的資源區分開來，動靜資源做好了拆分以後，我們就可以根據靜態資源的特點將其做緩存操作，這就是網站靜態化處理的核心思路
動態資源、靜態資源分離簡單的概括是：動態文件與靜態文件的分離
location ~.(png|jpg|css|js|htm|html){
root /home
}
8.爲什麼要做動、靜分離？
在我們的軟件開發中，有些請求是需要後臺處理的（如：.jsp,.do等等），有些請求是不需要經過後臺處理的（如：css、html、jpg、js等等文件）
這些不需要經過後臺處理的文件稱爲靜態文件，否則動態文件。因此我們後臺處理忽略靜態文件。這會有人又說那我後臺忽略靜態文件不就完了嗎
當然這是可以的，但是這樣後臺的請求次數就明顯增多了。在我們對資源的響應速度有要求的時候，我們應該使用這種動靜分離的策略去解決動、靜分離將網站靜態資源（HTML，JavaScript，CSS，img等文件）與後臺應用分開部署，提高用戶訪問靜態代碼的速度，降低對後臺應用訪問
這裏我們將靜態資源放到nginx中，動態資源轉發到tomcat服務器中,畢竟Tomcat的優勢是處理動態請求
9.負載均衡
負載均衡即是代理服務器將接收的請求均衡的分發到各服務器中
負載均衡主要解決網絡擁塞問題，提高服務器響應速度，服務就近提供，達到更好的訪問質量，減少後臺服務器大併發壓力
tomcatlist{ ip+port[weigth=3], ip+port[weigth=1], … } location /{ pass_proxy tomcat }
10.nginx和apache的區別
輕量級，同樣起web 服務，比apache 佔用更少的內存及資源
抗併發，nginx 處理請求是異步非阻塞的，而apache 則是阻塞型的，在高併發下nginx 能保持低資源低消耗高性能
高度模塊化的設計，編寫模塊相對簡單
最核心的區別在於apache是同步多進程模型，一個連接對應一個進程；nginx是異步的，多個連接（萬級別）可以對應一個進程
nginx 優化選項有哪些？
nginx常用優化內容主要包括如下內容：
1.隱藏版本信息
2.隱藏nginx要修改的源代碼
3.更改nginx服務的默認用戶
4.降權啓動nginx
5.優化nginx進程個數
6.綁定不同的nginx進程到不同的CPU上
7.Nginx事件處理模型優化
8.調整nginx單個進程允許的客戶端最大連接數
9.配置nginx worker進程對打打開文件數
10.開啓高效文件傳輸模式
11.Nginx gzip壓縮實現性能優化
12.編寫腳本實現日誌輪詢
13.不記錄不需要的日誌
14.訪問日誌的權限設置
15.根據擴展名限制程序和文件訪問
16.禁止訪問指定目錄下的所有文件和目錄
17.限制網站來源的IP訪問
18.配置nginx禁止非法域名解析訪問企業網站
19.nginx防爬蟲優化
20.控制nginx併發連接數量