標籤：
繼上一篇《debian+nginx配置初探--php環境、反向 Proxy和負載平衡》成功之後，有點小興奮，終於不用整lvs那麼複雜來搞定負載，但還是有很多概念沒弄清楚。
什麼是CGI、FastCGI、PHP-CGI、PHP-FPM、Spawn-FCGI？
- CGI全稱是“通用閘道介面”(Common Gateway Interface)，其實我理解的是一個協議，它描述了用戶端和HTTP伺服器之間如何傳輸資料，因此它有各種語言的實現如perl、tcl等，php的實現就是php-cgi。而由於CGI的缺點：每一個串連都啟動一個進程這造成CGI的效能低下，因此FastCGI應運而生。
- FastCGI是CGI的一種改進協議，將CGI解譯器進程保持在記憶體中，以此獲得較高的效能。 CGI程式反覆載入是CGI效能低下的主要原因，如果CGI程式保持在記憶體中並接受FastCGI進程管理器調度， 則可以提供良好的效能、伸縮性、Fail-Over特性等。
一般情況下，FastCGI的整個工作流程是這樣的：
- Web Server啟動時載入FastCGI進程管理器（IIS ISAPI或Apache Module)。
- FastCGI進程管理器自身初始化，啟動多個CGI解譯器進程(可見多個php-cgi)並等待來自Web Server的串連。
- 當用戶端請求到達Web Server時，FastCGI進程管理器選擇並串連到一個CGI解譯器。 Web server將CGI環境變數和標準輸入發送到FastCGI子進程php-cgi。
- FastCGI子進程完成處理後將標準輸出和錯誤資訊從同一串連返回Web Server。當FastCGI子進程關閉串連時， 請求便告處理完成。FastCGI子進程接著等待並處理來自FastCGI進程管理器(運行在Web Server中)的下一個串連。 在CGI模式中，php-cgi在此便退出了。
- PHP-FPM和Spawn-FCGI都是FastCGI的PHP實現，前者比後者更優秀，可以有效控制記憶體和進程、可以平滑重載PHP配置。而Spawn-FCGI是lighttpd中的一部份，在PHP-FPM沒出現之前是廣泛使用的。
php-fpm的命令選項：
- start 啟動php的fastcgi進程
- stop 強制終止php的fastcgi進程
- quit 平滑終止php的fastcgi進程
- restart 重啟php的fastcgi進程
- reload 重新平滑載入php的php.ini
- logrotate 重新啟用log檔案
Nginx配置中的Location文法
由前一篇可以感性認識下location的用法，它的文法如下：
location [=|^~|~|~*] /uri/ { … }
- = 開頭表示精確匹配
- ^~ 開頭表示uri以某個常規字串開頭，理解為匹配 url路徑即可。nginx不對url做編碼，因此請求為/static/20%/aa，可以被規則^~ /static/ /aa匹配到（注意是空格）。
- ~ 開頭表示區分大小寫正則匹配
- ~* 開頭表示不區分大小寫正則匹配
- !~和!~*分別為區分大小寫不匹配及不區分大小寫不匹配 的正則
- / 通用匹配，任何請求都會匹配到。
多個location配置的情況下匹配順序為: 首先匹配 =，其次匹配^~, 其次是按檔案中順序的正則匹配，最後是交給 / 通用匹配。當有匹配成功時候，停止匹配，按當前匹配規則處理請求。
樣本：
location = / { #規則A}location = /login { #規則B}location ^~ /static/ { #規則C}location ~ \.(gif|jpg|png|js|css)$ { #規則D}location ~* \.png$ { #規則E}location !~ \.xhtml$ {sudo /etc/init.d/nginx用法: nginx {start|stop|restart|reload|force-reload|status|configtest|rotate|upgrade}start 啟動stop 停止restart 重啟reload 平滑重新載入force-reload 強制重新載入，其實就是restartstatus 查看狀態configtest 測試組態是否正確 #規則F}location !~* \.xhtml$ { #規則G}location / { #規則H}
那麼產生的效果如下：
- 訪問根目錄/， 比如http://localhost/ 將匹配規則A
- 訪問 http://localhost/login 將匹配規則B，http://localhost/register 則匹配規則H
- 訪問 http://localhost/static/a.html 將匹配規則C
- 訪問 http://localhost/a.gif, http://localhost/b.jpg 將匹配規則D和規則E，但是規則D順序優先，規則E不起作用，而 http://localhost/static/c.png 則優先匹配到規則C
- 訪問 http://localhost/a.PNG 則匹配規則E，而不會匹配規則D，因為規則E不區分大小寫。
- 訪問 http://localhost/a.xhtml 不會匹配規則F和規則G，http://localhost/a.XHTML不會匹配規則G，因為不區分大小寫。規則F，規則G屬於排除法，符合匹配規則但是不會匹配到，所以想想看實際應用中哪裡會用到。
- 訪問 http://localhost/category/id/1111 則最終匹配到規則H，因為以上規則都不匹配，這個時候應該是nginx轉寄請求給後端應用伺服器，比如FastCGI（php），tomcat（jsp），nginx作為方向Proxy 伺服器存在。
概念普及
- 代理
- 標準的代理緩衝伺服器
一個標準的代理緩衝服務被用於緩衝靜態網頁（例如：html檔案和圖片檔案等）到本網上的一台主機上（即Proxy 伺服器）。當被緩衝的頁面被第二次訪問的時候，瀏覽器將直接從本地Proxy 伺服器那裡請求資料而不再向原web網站請求資料。這樣就節省了寶貴的網路頻寬，而且提高了訪問速度。但是，要想實現這種方式，必須在每一個內部主機的瀏覽器上明確指明Proxy 伺服器的IP地址和連接埠號碼。用戶端上網時，每次都把請求送給Proxy 伺服器處理，Proxy 伺服器根據請求確定是否串連到遠程web伺服器擷取資料。如果在本地緩衝區有目標檔案，則直接將檔案傳給使用者即可。如果沒有的話則先取迴文件，先在本地儲存一份緩衝，然後將檔案發給用戶端瀏覽器。
- 透明代理緩衝伺服器
透明代理緩衝服務和標準Proxy 伺服器的功能完全相同。但是，代理操作對用戶端的瀏覽器是透明的（即不需指明Proxy 伺服器的IP和連接埠）。透明Proxy 伺服器阻斷網路通訊，並且過濾出訪問外部的HTTP（80連接埠）流量。如果用戶端的請求在本地有緩衝則將緩衝的資料直接發給使用者，如果在本地沒有緩衝則向遠程web伺服器發出請求，其餘操作和標準的Proxy 伺服器完全相同。對於Linux作業系統來說，透明代理使用Iptables或者Ipchains實現。因為不需要對瀏覽器作任何設定，所以，透明代理對於ISP（Internet伺服器供應商）特別有用。
- 反向 Proxy緩衝伺服器
反向 Proxy是和前兩種代理完全不同的一種代理服務。使用它可以降低原始WEB伺服器的負載。反向 Proxy伺服器承擔了對原始WEB伺服器的靜態頁面的請求，防止原始伺服器過載。它位於本地WEB伺服器和Internet之間，處理所有對WEB伺服器的請求，阻止了WEB伺服器和Internet的直接通訊。如果互連網使用者請求的頁面在Proxy 伺服器上有緩衝的話，Proxy 伺服器直接將緩衝內容發送給使用者。如果沒有緩衝則先向WEB伺服器發出請求，取回資料，本機快取後再發送給使用者。這種方式通過降低了向WEB伺服器的請求數從而降低了WEB伺服器的負載。
- 常見的Web負載平衡方法
- 使用者手動選擇方法
這是一種較為古老的方式。通過在主站首頁入口提供不同線路、不同伺服器串連的方式，來實現負載平衡。這種方式在一些提供下載的網站中比較常見。
- DNS輪詢方式
大多網域名稱註冊商都支援對同一主機名稱添加多條A記錄，這就是DNS輪詢，DNS伺服器將解析騎牛按照A記錄的順序，隨機分配到不同的IP上，這樣就完成了簡單的負載平衡。但DNS負載雖然成本低，但可靠性低，而且負載不夠均衡。可以使用linux的dig命令來查看DNS負載。
- 四/七層負載平衡裝置
OSI模型的最低層或第一層：物理層物理層包括物理連網媒介，實際上就是布線、光纖、網卡和其它用來把兩台網路通訊裝置串連在一起的東西。它規定了啟用、維持、關閉通訊端點之間的機械特性、電氣特性、功能特性以及過程特性。雖然物理層不提供錯誤修正服務，但它能夠設定資料轉送速率並監測資料出錯率。物理層定義的標準包括：EIA/TIA RS-232、EIA/TIA RS-449、V.35、RJ-45等。
OSI模型的第二層：資料連結層 資料連結層主要作用是控制網路層與物理層之間的通訊。它保證了資料在不可靠的物理線路上進行可靠的傳遞。它把從網路層接收到的資料分割成特定的可被物理層傳輸的幀，保證了傳輸的可靠性。它的主要作用包括：物理地址定址、資料的成幀、流量控制、資料的檢錯、重發等。它是獨立於網路層和物理層的，工作時無需關心電腦是否正在運行軟體還是其他動作。資料連結層協議的代表包括：SDLC、HDLC、PPP、STP、框架轉送等。
OSI模型的第三層：網路層很多使用者經常混淆2層和3層的相關問題，簡單來說，如果你在談論一個與IP地址、路由協議或位址解析通訊協定（ARP）相關的問題，那麼這就是第三層的問題。網路層負責對子網間的資料包進行路由選擇，它通過綜合考慮發送優先權、網路擁塞程度、服務品質以及可選路由的花費來決定從一個網路中兩個節點的最佳路徑。另外，它還可以實現擁塞控制、網際互連等功能。網路層協議的代表包括：IP、IPX、RIP、OSPF等。
OSI模型的第四層：傳輸層傳輸層是OSI模型中最重要的一層，它是兩台電腦經過網路進行資料通訊時,第一個端到端的層次，起到緩衝作用。當網路層的服務品質不能滿足要求時，它將提高服務，以滿足高層的要求；而當網路層服務品質較好時，它只需進行很少的工作。另外，它還要處理端到端的差錯控制和流量控制等問題，最終為會話提供可靠的,無誤的資料轉送。傳輸層協議的代表包括：TCP、UDP、SPX等。
OSI模型的第五層：會話層會話層負責在網路中的兩節點之間建立和維持通訊，並保持會話獲得同步，它還決定通訊是否被中斷以及通訊中斷時決定從何處重新發送。
OSI模型的第六層：展示層展示層的作用是管理資料的解密與加密，如常見的系統口令處理，當你的賬戶資料在發送前被加密，在網路的另一端，展示層將對接收到的資料解密。另外，展示層還需對圖片和檔案格式資訊進行解碼和編碼。
OSI模型的第七層：應用程式層簡單來說，應用程式層就是為作業系統或網路應用程式提供訪問網路服務的介面，包括檔案傳輸、檔案管理以及電子郵件等的資訊處理。應用程式層協議的代表包括：Telnet、FTP、HTTP、SNMP等。
OSI模型和TCP/IP模型的關係：
硬體四/七層負載交換器一般有F5 BIG-IP、Citrix NetScaler、Radware、Cisco Css、Foundry等；軟體四層負載的代表作是LVS；軟體七層負載大多基於HTTP的反向 Proxy，如Nginx、L7SW、HAProxy等。
- 多線多地區智能DNS解析與混合負載平衡方式
以新浪首頁為例，負載平衡同時用到了“多線多地區智能DNS解析、DNS輪詢、四/七層負載平衡交換器”等技術。智能DNS解析能夠根據使用者本地設定的DNS伺服器線路和地區，將對同一個網域名稱請求解析到不同的IP上。
啟動
可以使用
sudo /etc/init.d/nginx
用法
nginx {start|stop|restart|reload|force-reload|status|configtest|rotate|upgrade}
- start 啟動
- stop 停止
- restart 重啟
- reload 平滑重新載入
- force-reload 強制重新載入，其實就是restart
- status 查看狀態
- configtest 測試組態是否正確
可以查看"/etc/init.d/nginx"看具體含義。
nginx配置之深入理解
