對Nginx的理解
- -相對於Apache
概要：nginx的源碼安裝，參數配置，make，nginx與Apache的區別，四層均衡負載均衡，七層負載均衡。線程與進程
首先，我們還是通過實驗對Nginx的配置進行剖析，瞭解Nginx都可以實現什麼功能。
第一部分：實驗
##獲得nginx包，並解壓：
README文件是自述文件。也就是服務該如何配置的文件，相當於使用指南:
他說要到網上查看如何安裝和配置：
首先指導我們進行源代碼安裝：
解壓後文件是6.2M：
用幫助查看怎麼用源代碼安裝：
幫助裏會告訴我們怎麼安裝我們需要的服務，比如ssl，和http
還可以指定nginx的用戶和組：
還有安裝路徑的前綴：
然後就可以開始安裝：
安裝完成後會顯示需要依賴軟件，所以，我們要安裝依賴軟件，並且結尾應該是devel：
再安裝，再查看依賴性,解決依賴：
直到解決所有依賴性，然後就完成了第一步，接下來是
Make make install
當然 這三步也可以一次完成：
在第一步完成後會生成makefiel文件，指導make的運行：
我們現在安裝的nginx是5.5M，是因爲debug（排除程序故障，是及其重要的編譯操作）的原因。
開啓nginx，查看端口：
用命令和瀏覽器可以查看現在nginx開啓:
關閉並且刪除nginx：
Make clean 相當於刪除makefiel然後把解壓包也刪了，從頭開始做，
解壓，進入解壓包:
之前我們做的安裝完成後，會有nginx的版本號，這樣很不安全，下面是在安裝時去除版本號：
在下面的文件中編輯GCC，在安裝過程中不進行Debug，這樣nginx將會很小。
然後就是源碼安裝：
進入安裝位置，查看端口：
檢查，可以訪問，並且包很小：
安裝好之後，我們必須在nginx下的sbin下執行./nginx才能開啓nginx，爲了不麻煩，我們可以將要執行的目錄鏈接到環境變量下，這樣就可以在任何位置執行並開啓nginx了
當你再查詢nginx的位置時顯示的是鏈接的位置：
這樣我們就可以在任何位置進行nginx的開啓，關閉看，重新加載。
下面來配置nginx的動態模塊，這樣在你安裝nginx的時候，如果是動態模塊，那麼你就可以在需要的時候打開，不需要的時候關閉。然而它支持的動態模塊有限，這裏我們以mail爲例，相對於這一點，Apache的配置文件中是已經內置了動態模塊：
一個安裝包可以安裝多次但每次都必須make clean，目的是刷新刪除makefile這個文件（這個文件是每次在第一步後在安裝包中生成的，用來指導make，而不是在安裝位置）
Nginx --help可以查看怎麼設置安裝：
動態模塊是在靜態模塊後面加上dynamic：
這裏我們安裝兩個動態庫，並解決依賴性：
Make && make install
這樣在安裝的目錄下就會有modules的目錄,並且在modules中有剛剛我們增加的動態模塊，當我們需要啓動服務時，就可以在nginx的主配置文件中加入：
並且只能增加在第一行，否則 ./nginx -t 會有語法錯誤。
這樣檢測語法，重新加載就可以使用mail服務了。
##修改nginx的用戶：
默認是nobody
在配置文件第一行修改：
###限制用戶訪問資源數：
如果不限制用戶訪問資源數，會把內存消耗完，這樣系統就會崩潰。
把內存資源消耗完的命令：
意思是一個請求接着一個請求。
Ulimit：限制用戶的最大進程數，
Ulimit -a顯示當前的所有用戶的進程限制。
現在一個進程打開的文件個數是默認的1024個。
我們新增一個用戶，查看他的進程限制，還是 默認一個進程可以打開1024個文件。
##wxh可以打開最大的進程相互爲100，當然，我們也可以設置最大的文件數：
查看：
再用shell×××去測，發現他是一個循環，最多佔用100個進程，然後就退出，然後再進行×××。
##統計訪問次數:
##手寫網頁跳轉：
生成證書:
###網頁重定向：
修改發佈目錄
在主機上增加解析：
有時會不停閃爍，加上<noscript >就行了
###網頁重寫
還要把之前做的重定向註釋掉：
###虛擬主機
##負載均衡：
對westos.org做負載均衡
在server3中開啓http，將昨天vanish做的虛擬主機刪除，修改發佈目錄：
Server2也要修改發佈目錄：
重啓兩個http，檢測發佈目錄沒錯：
這是在虛擬主機的基礎上加了負載均衡，兩者不牽扯：
檢測：
負載均衡可以加權重:
加完權重後的效果：
Backup表示此臺主機並不是負載均衡主機，而是當所有其他主機都掛掉後，顯示這臺主機的發佈目錄，我們可以在這一頁寫上“系統正在維護”等
Nginx的發佈目錄是在nginx下的html下的index.html：
還可以使用IP hash 和將某一臺負載均衡器關了。
增加sticky模塊，把之前做的nginx刪了，重新安裝：
這樣就增加了一個sticky模塊。
第二部分:相關知識的補充
##GUN的相關知識:
GUN計劃，又叫做革奴計劃，目標是創建一套完全自由的操作系統，爲保證GUN軟件可以自由的使用，複製修改傳播，就有了GUN通用公共許可證。
GUN計劃首先完成的是開發出了許多軟件包，包括強大的文字編輯器emacs，GCC（GUN編譯器集合，是一套由GUN開發的編程語言編譯器），以及大部分UNIX系統的程序庫和工具。唯一沒有完成的就是操作系統與內核。
然後李納斯托沃茲開發出來linux操作系統內核，並與其它GUN軟件結合，儘管如此，GUN計劃還是開發出自己內核。
##Make理解:
在我們用源碼安裝nginx時只需三步就可以，這裏就用到了GUN的make工具，我們在shell提示符下只需要輸入make命令就可以完成自動編譯，極大的提高了效率，這是因爲有makefile文件，makefile文件指出了整個工程所有文件的編譯順序，編譯規則（哪些文件先編譯，哪些文件後編譯哪些需要重新編譯），makefile有自己的書寫格式，關鍵字，函數。
只有linux中才有makefile，window中IDE（集成開發環境）已經將makefile這個工作給做了。在UNIX下的軟件編譯，就需要自己寫makefile。
Makefile就像shell腳本一樣，其中也可以執行操作系統的命令。
關於程序的編譯（compile）連接（link）：
編譯時，編譯器只檢測程序的語法，和函數，變量是否被聲明，如果函數未被聲明，會警告，但是，仍然會生成object file（-o在window中是obj）而在連接程序時，連接器會在所有的object file中找尋函數的實現，如果找不到，就會報錯。
我們在命令行輸入make，他會在當前目錄下找makefiel文件或Makefile。
下面是makefiel的詳細講解：
http://sc.qq.com/fx/u?r=PPKILEA
##一線互聯網公司所使用的web服務器：
網易（163，com），新浪（sina），360用的就是nginx
百度用的是Apache
基本篩選引擎（BFE)是一種管理防火牆internet協議安全（IPsec）策略以及實施用戶模式篩選的服務。停止或禁用BFE服務將大大降低系統的安全。
騰訊用的是squid：
淘寶用的是自己阿里的tengine
##Nginx的master和worker的淺析：
Nginx開啓後會在後臺運行，包括一個master進程和多個worker進程。可以讓他前臺運行也可以關掉master進程，讓其以單進程方式運行。
Nginx有single和master兩種進程模塊，single模型是單進程的，容錯能力差，不適合生產場景，生產場景用的master模型，即一個master進程加上N個worker進程。Master進程負責管理worker進程是master進程fork出來的，用來處理請求。
Worker數最多隻能和CPU 數相等，查看系統CPU個數用licpu.
Nginx之所以快是因爲master-worker模塊和七層負載均衡。
七層負載均衡是vanish和nginx常用的。
###DNS四層負載均衡與nginx七層負載均衡的異同：
四層負載均衡是用戶將數據包發到四層服務器，然後到後端服務器，後端服務器直接將數據包返回給用戶，並且更改了IP數據包的地址，實現分流。四層均衡器只是起到一個轉發的作用，以TCP爲例，三次握手但是建立在client和server上的， 七層是後端機器要將數據包先返回給七層服務器，在返回給用戶，這樣效率會差一點。Client和七層服務器之間，七層服務器和server指間都會有三次握手，七層服務器相當於一個代理。
當有***時，四層會直接發送給後端，而七層會過濾掉，這樣七層就比較安全。
七層可以實現對流量的統計，能夠將訪問不同內容（文字or圖片）的包分發給不同的服務器。
下面是對四層和七層的詳細講解：
http://shikezhi.com/html/2016/nginx_0407/1099813.html
##同步阻塞與異步非阻塞：
Apache 本身採用同步阻塞，也有異步非阻塞，但是與自身衝突，所以不常用。
Nginx採用異步非阻塞：一個線程註冊多個IO事件，IO事件準備完就處理，如果如果沒有準備完，則阻塞一段時間，在這段是間內，如果準備問就直接處理。提升了CPU利用率和高併發的處理能力。
總得來說就是：
同步阻塞：是CPU處理一個進程完後才能進行下一請求。
非阻塞：是開多個線程，但是這樣會在內存佔用和線程切換之間浪費開銷。
異步非阻塞：一個線程上註冊多個IO，一完就處理，如果沒完就阻塞一段時間，再處理。不是在線程之間切換而是在請求之間切換，就不存在線程之間切換的開銷。
在傳統的同步阻塞IO模型下，七層服務器每次向後端服務器發送請求需要等待響應結果，這樣CPU大部分時間都在等待IO完成，效率非常低。爲了解決這個問題可以採用非阻塞的方式，七層服務器開多個工作線程，每個工作線程通過輪詢的方式去檢查IO事件是否完成，如果沒有完成則讓出CPU讓其他工作線程處理。這種方式比同步阻塞的方式要好，但是只有在工作線程很多的情況下效率才比較高，而工作線程一多帶來的內存開銷以及線程切換的開銷也非常大，阻礙了進一步提升併發處理能力。這時可以採用異步非阻塞IO模型，也就是說不再開很多個工作線程，而是由一個工作線程註冊很多個IO事件，如果有IO事件準備完畢，則可以直接處理。如果沒有準備完畢，則阻塞一個固定超時時間，在這個時間之內如果有多個IO事件都準備完畢了，則可以依次處理這些IO事件。從整體上來看節省了上下文切換的開銷，提升了CPU的利用率，因此也提升了併發處理能力。這也是當前select/poll/epoll/kqueue這些機制的基本原理。
在傳統的同步阻塞IO模型下，七層服務器每次向後端服務器發送請求需要等待響應結果，這樣CPU大部分時間都在等待IO完成，效率非常低。爲了解決這個問題可以採用非阻塞的方式，七層服務器開多個工作線程，每個工作線程通過輪詢的方式去檢查IO事件是否完成，如果沒有完成則讓出CPU讓其他工作線程處理。這種方式比同步阻塞的方式要好，但是只有在工作線程很多的情況下效率才比較高，而工作線程一多帶來的內存開銷以及線程切換的開銷也非常大，阻礙了進一步提升併發處理能力。這時可以採用異步非阻塞IO模型，也就是說不再開很多個工作線程，而是由一個工作線程註冊很多個IO事件，如果有IO事件準備完畢，則可以直接處理。如果沒有準備完畢，則阻塞一個固定超時時間，在這個時間之內如果有多個IO事件都準備完畢了，則可以依次處理這些IO事件。從整體上來看節省了上下文切換的開銷，提升了CPU的利用率，因此也提升了併發處理能力。這也是當前select/poll/epoll/kqueue這些機制的基本原理。
Nginx與七層負載均衡參考:
http://blog.csdn.net/xiaoao89757/article/details/450582
21
四七層代理區別：
http://hi.baidu.com/aking_roc/item/3f62cb0f57b49736a3332a9e
Nginx平臺初探：
http://tengine.taobao.org/book/chapter_02.html
第三部分：原理講解
Nginx與Apache的區別：
最大的區別是nginx佔用資源少，可處理高併發，epoll的IO模型使nginx性能更高，是異步非阻塞處理請求，還是高度模塊化的，配置簡潔，靜態性能好，本身就是就是一個反向代理器，七層負載均衡。
而Apache能夠更加穩定，少BUG模塊超級多，select的IO模型使他吃力請求相對較慢，配置相對麻煩，處理動態好，rewrite功能強。
最核心的區別在於apache是同步多進程模型，一個連接對應一個進程；nginx是異步的，多個連接（萬級別）可以對應一個進程 。
好的模型是前端nginx抗高併發，後端Apache是Apache集羣。
下面是兩者區別的詳細介紹：
1、nginx相對於apache的優點：
輕量級，同樣起web 服務，比apache 佔用更少的內存及資源.
抗併發，nginx 處理請求是異步非阻塞的，而apache 則是阻塞型的，在高併發下nginx 能保持低資源低消耗高性能.
高度模塊化的設計，編寫模塊相對簡單.
社區活躍，各種高性能模塊出品迅速啊.
apache 相對於nginx 的優點：
rewrite ，比nginx 的rewrite 強大.
模塊超多，基本想到的都可以找到.
少bug ，nginx 的bug 相對較多.
超穩定.
存在就是理由，一般來說，需要性能的web 服務，用nginx 。如果不需要性能只求穩定，那就apache 吧。後者的各種功能模塊實現得比前者，例如ssl 的模塊就比前者好，可配置項多。這裏要注意一點，epoll(freebsd 上是 kqueue )網絡IO 模型是nginx 處理性能高的根本理由，但並不是所有的情況下都是epoll 大獲全勝的，如果本身提供靜態服務的就只有寥寥幾個文件，apache 的select 模型或許比epoll 更高性能。當然，這只是根據網絡IO 模型的原理作的一個假設，真正的應用還是需要實測了再說的。
2、作爲 Web 服務器：相比 Apache，Nginx 使用更少的資源，支持更多的併發連接，體現更高的效率，這點使 Nginx 尤其受到虛擬主機提供商的歡迎。在高連接併發的情況下，Nginx是Apache服務器不錯的替代品: Nginx在美國是做虛擬主機生意的老闆們經常選擇的軟件平臺之一. 能夠支持高達 50,000 個併發連接數的響應, 感謝Nginx爲我們選擇了 epoll and kqueue 作爲開發模型.
Nginx作爲負載均衡服務器: Nginx 既可以在內部直接支持 Rails 和 PHP 程序對外進行服務, 也可以支持作爲 HTTP代理 服務器對外進行服務. Nginx採用C進行編寫, 不論是系統資源開銷還是CPU使用效率都比 Perlbal 要好很多.
作爲郵件代理服務器: Nginx 同時也是一個非常優秀的郵件代理服務器（最早開發這個產品的目的之一也是作爲郵件代理服務器）, Last.fm 描述了成功並且美妙的使用經驗.
Nginx 是一個安裝非常的簡單 , 配置文件非常簡潔（還能夠支持perl語法）, Bugs 非常少的服務器: Nginx 啓動特別容易, 並且幾乎可以做到7*24不間斷運行，即使運行數個月也不需要重新啓動. 你還能夠不間斷服務的情況下進行軟件版本的升級 .
3、Nginx 配置簡潔, Apache 複雜
Nginx 靜態處理性能比 Apache 高 3倍以上
Apache 對 PHP 支持比較簡單，Nginx 需要配合其他後端用
Apache 的組件比 Nginx 多
現在 Nginx 纔是 Web 服務器的首選
4、最核心的區別在於apache是同步多進程模型，一個連接對應一個進程；nginx是異步的，多個連接（萬級別）可以對應一個進程
5、nginx處理靜態文件好,耗費內存少.但無疑apache仍然是目前的主流,有很多豐富的特性.所以還需要搭配着來.當然如果能確定nginx就適合需求,那麼使用nginx會是更經濟的方式.
6、從個人過往的使用情況來看，nginx的負載能力比apache高很多。最新的服務器也改用nginx了。而且nginx改完配置能-t測試一下配置有沒有問題，apache重啓的時候發現配置出錯了，會很崩潰，改的時候都會非常小心翼翼現在看有好多集羣站，前端nginx抗併發，後端apache集羣，配合的也不錯。
7、nginx處理動態請求是雞肋，一般動態請求要apache去做，nginx只適合靜態和反向。
8、從我個人的經驗來看，nginx是很不錯的前端服務器，負載性能很好，在老奔上開nginx，用webbench模擬10000個靜態文件請求毫不吃力。apache對php等語言的支持很好，此外apache有強大的支持網路，發展時間相對nginx更久，bug少但是apache有先天不支持多核心處理負載雞肋的缺點，建議使用nginx做前端，後端用apache。大型網站建議用nginx自代的集羣功能
9、Nginx優於apache的主要兩點：1.Nginx本身就是一個反向代理服務器 2.Nginx支持7層負載均衡；其他的當然，Nginx可能會比apache支持更高的併發，但是根據NetCraft的統計，2011年4月的統計數據，Apache依然佔有62.71%，而Nginx是7.35%，因此總得來說，Aapche依然是大部分公司的首先，因爲其成熟的技術和開發社區已經也是非常不錯的性能。
10、你對web server的需求決定你的選擇。大部分情況下nginx都優於APACHE，比如說靜態文件處理、PHP-CGI的支持、反向代理功能、前端Cache、維持連接等等。在Apache+PHP（prefork）模式下，如果PHP處理慢或者前端壓力很大的情況下，很容易出現Apache進程數飆升，從而拒絕服務的現象。
11、可以看一下nginx lua模塊：https://github.com/chaoslaw...apache比nginx多的模塊，可直接用lua實現apache是最流行的，why？大多數人懶得更新到nginx或者學新事物
12、對於nginx，我喜歡它配置文件寫的很簡潔，正則配置讓很多事情變得簡單運行效率高，佔用資源少，代理功能強大，很適合做前端響應服務器
13、Apache在處理動態有優勢，Nginx併發性比較好，CPU內存佔用低，如果rewrite頻繁，那還是Apache吧
Ulimit的講解：
http://www.linuxidc.com/Linux/2012-10/72782.htm
線程與進程的區別：
鏈接：
來源：luoweifu
鏈接：blog.csdn.net/luoweifu/article/details/46595285