Nginx基礎知識點總結和優化項

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模型，提供了一個隊列，排隊解決

四、爲何不使用多線程？
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的指令數等等。

 

五、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併發鏈接數量