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并發連接數量
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/158642.html
標籤：Linux
上一篇：視頻教程匯總