Nginx工做原理和優化、漏洞

時間  2019-11-30
標籤 nginx 原理 優化 漏洞 欄目 Nginx 简体版
原文   原文鏈接

 NGINX以高性能的負載均衡器，緩存，和web服務器聞名，驅動了全球超過 40% 最繁忙的網站。在大多數場景下，默認的 NGINX 和 Linux 設置能夠很好的工做，但要達到最佳性能，有些時候必須作些調整。首先咱們先了解其工做原理。javascript

 

1.  Nginx的模塊與工做原理php

Nginx由內核和模塊組成，其中，內核的設計很是微小和簡潔，完成的工做也很是簡單，僅僅經過查找配置文件將客戶端請求映射到一個location block（location是Nginx配置中的一個指令，用於URL匹配），而在這個location中所配置的每一個指令將會啓動不一樣的模塊去完成相應的工做。css

Nginx的模塊從結構上分爲核心模塊、基礎模塊和第三方模塊：html

核心模塊：HTTP模塊、EVENT模塊和MAIL模塊前端

基礎模塊：HTTP Access模塊、HTTP FastCGI模塊、HTTP Proxy模塊和HTTP Rewrite模塊，java

第三方模塊：HTTP Upstream Request Hash模塊、Notice模塊和HTTP Access Key模塊。mysql

用戶根據本身的須要開發的模塊都屬於第三方模塊。正是有了這麼多模塊的支撐，Nginx的功能纔會如此強大。linux

Nginx的模塊從功能上分爲以下三類。nginx

Handlers（處理器模塊）。此類模塊直接處理請求，並進行輸出內容和修改headers信息等操做。Handlers處理器模塊通常只能有一個。web

Filters （過濾器模塊）。此類模塊主要對其餘處理器模塊輸出的內容進行修改操做，最後由Nginx輸出。

Proxies （代理類模塊）。此類模塊是Nginx的HTTP Upstream之類的模塊，這些模塊主要與後端一些服務好比FastCGI等進行交互，實現服務代理和負載均衡等功能。

圖1-1展現了Nginx模塊常規的HTTP請求和響應的過程。

                       圖1-1展現了Nginx模塊常規的HTTP請求和響應的過程。

Nginx自己作的工做實際不多，當它接到一個HTTP請求時，它僅僅是經過查找配置文件將這次請求映射到一個location block，而此location中所配置的各個指令則會啓動不一樣的模塊去完成工做，所以模塊能夠看作Nginx真正的勞動工做者。一般一個location中的指令會涉及一個handler模塊和多個filter模塊（固然，多個location能夠複用同一個模塊）。handler模塊負責處理請求，完成響應內容的生成，而filter模塊對響應內容進行處理。

Nginx的模塊直接被編譯進Nginx，所以屬於靜態編譯方式。啓動Nginx後，Nginx的模塊被自動加載，不像Apache，首先將模塊編譯爲一個so文件，而後在配置文件中指定是否進行加載。在解析配置文件時，Nginx的每一個模塊都有可能去處理某個請求，可是同一個處理請求只能由一個模塊來完成。 

 

2.  Nginx的進程模型

 

在工做方式上，Nginx分爲單工做進程和多工做進程兩種模式。在單工做進程模式下，除主進程外，還有一個工做進程，工做進程是單線程的；在多工做進程模式下，每一個工做進程包含多個線程。Nginx默認爲單工做進程模式。

Nginx在啓動後，會有一個master進程和多個worker進程。

master進程

主要用來管理worker進程，包含：接收來自外界的信號，向各worker進程發送信號，監控worker進程的運行狀態，當worker進程退出後(異常狀況下)，會自動從新啓動新的worker進程。

master進程充當整個進程組與用戶的交互接口，同時對進程進行監護。它不須要處理網絡事件，不負責業務的執行，只會經過管理worker進程來實現重啓服務、平滑升級、更換日誌文件、配置文件實時生效等功能。

咱們要控制nginx，只須要經過kill向master進程發送信號就好了。好比kill -HUP pid，則是告訴nginx，從容地重啓nginx，咱們通常用這個信號來重啓nginx，或從新加載配置，由於是從容地重啓，所以服務是不中斷的。master進程在接收到HUP信號後是怎麼作的呢？首先master進程在接到信號後，會先從新加載配置文件，而後再啓動新的worker進程，並向全部老的worker進程發送信號，告訴他們能夠光榮退休了。新的worker在啓動後，就開始接收新的請求，而老的worker在收到來自master的信號後，就再也不接收新的請求，而且在當前進程中的全部未處理完的請求處理完成後，再退出。固然，直接給master進程發送信號，這是比較老的操做方式，nginx在0.8版本以後，引入了一系列命令行參數，來方便咱們管理。好比，./nginx -s reload，就是來重啓nginx，./nginx -s stop，就是來中止nginx的運行。如何作到的呢？咱們仍是拿reload來講，咱們看到，執行命令時，咱們是啓動一個新的nginx進程，而新的nginx進程在解析到reload參數後，就知道咱們的目的是控制nginx來從新加載配置文件了，它會向master進程發送信號，而後接下來的動做，就和咱們直接向master進程發送信號同樣了。

worker進程：

而基本的網絡事件，則是放在worker進程中來處理了。多個worker進程之間是對等的，他們同等競爭來自客戶端的請求，各進程互相之間是獨立的。一個請求，只可能在一個worker進程中處理，一個worker進程，不可能處理其它進程的請求。worker進程的個數是能夠設置的，通常咱們會設置與機器cpu核數一致，這裏面的緣由與nginx的進程模型以及事件處理模型是分不開的。

worker進程之間是平等的，每一個進程，處理請求的機會也是同樣的。當咱們提供80端口的http服務時，一個鏈接請求過來，每一個進程都有可能處理這個鏈接，怎麼作到的呢？首先，每一個worker進程都是從master進程fork過來，在master進程裏面，先創建好須要listen的socket（listenfd）以後，而後再fork出多個worker進程。全部worker進程的listenfd會在新鏈接到來時變得可讀，爲保證只有一個進程處理該鏈接，全部worker進程在註冊listenfd讀事件前搶accept_mutex，搶到互斥鎖的那個進程註冊listenfd讀事件，在讀事件裏調用accept接受該鏈接。當一個worker進程在accept這個鏈接以後，就開始讀取請求，解析請求，處理請求，產生數據後，再返回給客戶端，最後才斷開鏈接，這樣一個完整的請求就是這樣的了。咱們能夠看到，一個請求，徹底由worker進程來處理，並且只在一個worker進程中處理。worker進程之間是平等的，每一個進程，處理請求的機會也是同樣的。當咱們提供80端口的http服務時，一個鏈接請求過來，每一個進程都有可能處理這個鏈接，怎麼作到的呢？首先，每一個worker進程都是從master進程fork過來，在master進程裏面，先創建好須要listen的socket（listenfd）以後，而後再fork出多個worker進程。全部worker進程的listenfd會在新鏈接到來時變得可讀，爲保證只有一個進程處理該鏈接，全部worker進程在註冊listenfd讀事件前搶accept_mutex，搶到互斥鎖的那個進程註冊listenfd讀事件，在讀事件裏調用accept接受該鏈接。當一個worker進程在accept這個鏈接以後，就開始讀取請求，解析請求，處理請求，產生數據後，再返回給客戶端，最後才斷開鏈接，這樣一個完整的請求就是這樣的了。咱們能夠看到，一個請求，徹底由worker進程來處理，並且只在一個worker進程中處理。

nginx的進程模型，能夠由下圖來表示：

 

 

 

3.  Nginx+FastCGI運行原理

 

一、什麼是 FastCGI

FastCGI是一個可伸縮地、高速地在HTTP server和動態腳本語言間通訊的接口。多數流行的HTTP server都支持FastCGI，包括Apache、Nginx和lighttpd等。同時，FastCGI也被許多腳本語言支持，其中就有PHP。

FastCGI是從CGI發展改進而來的。傳統CGI接口方式的主要缺點是性能不好，由於每次HTTP服務器遇到動態程序時都須要從新啓動腳本解析器來執行解析，而後將結果返回給HTTP服務器。這在處理高併發訪問時幾乎是不可用的。另外傳統的CGI接口方式安全性也不好，如今已經不多使用了。

FastCGI接口方式採用C/S結構，能夠將HTTP服務器和腳本解析服務器分開，同時在腳本解析服務器上啓動一個或者多個腳本解析守護進程。當HTTP服務器每次遇到動態程序時，能夠將其直接交付給FastCGI進程來執行，而後將獲得的結果返回給瀏覽器。這種方式可讓HTTP服務器專注地處理靜態請求或者將動態腳本服務器的結果返回給客戶端，這在很大程度上提升了整個應用系統的性能。

二、Nginx+FastCGI運行原理

Nginx不支持對外部程序的直接調用或者解析，全部的外部程序（包括PHP）必須經過FastCGI接口來調用。FastCGI接口在Linux下是socket（這個socket能夠是文件socket，也能夠是ip socket）。

wrapper：爲了調用CGI程序，還須要一個FastCGI的wrapper（wrapper能夠理解爲用於啓動另外一個程序的程序），這個wrapper綁定在某個固定socket上，如端口或者文件socket。當Nginx將CGI請求發送給這個socket的時候，經過FastCGI接口，wrapper接收到請求，而後Fork(派生）出一個新的線程，這個線程調用解釋器或者外部程序處理腳本並讀取返回數據；接着，wrapper再將返回的數據經過FastCGI接口，沿着固定的socket傳遞給Nginx；最後，Nginx將返回的數據（html頁面或者圖片）發送給客戶端。這就是Nginx+FastCGI的整個運做過程，如圖1-3所示。

       

 

      因此，咱們首先須要一個wrapper，這個wrapper須要完成的工做：

  1. 經過調用fastcgi（庫）的函數經過socket和ningx通訊（讀寫socket是fastcgi內部實現的功能，對wrapper是非透明的）
  2. 調度thread，進行fork和kill
  3. 和application（php）進行通訊

三、spawn-fcgi與PHP-FPM

       FastCGI接口方式在腳本解析服務器上啓動一個或者多個守護進程對動態腳本進行解析，這些進程就是FastCGI進程管理器，或者稱爲FastCGI引擎。 spawn-fcgi與PHP-FPM就是支持PHP的兩個FastCGI進程管理器。 所以HTTPServer徹底解放出來，能夠更好地進行響應和併發處理。
       spawn-fcgi與PHP-FPM的異同：
       1）spawn-fcgi是HTTP服務器lighttpd的一部分，目前已經獨立成爲一個項目，通常與lighttpd配合使用來支持PHP。可是ligttpd的spwan-fcgi在高併發訪問的時候，會出現內存泄漏甚至自動重啓FastCGI的問題。即：PHP腳本處理器當機，這個時候若是用戶訪問的話，可能就會出現白頁(即PHP不能被解析或者出錯)。
       2）Nginx是個輕量級的HTTP server，必須藉助第三方的FastCGI處理器才能夠對PHP進行解析，所以其實這樣看來nginx是很是靈活的，它能夠和任何第三方提供解析的處理器實現鏈接從而實現對PHP的解析(在nginx.conf中很容易設置)。nginx也可使用spwan-fcgi(須要一同安裝lighttpd，可是須要爲nginx避開端口，一些較早的blog有這方面安裝的教程)，可是因爲spawn-fcgi具備上面所述的用戶逐漸發現的缺陷，如今慢慢減小用nginx+spawn-fcgi組合了。

       因爲spawn-fcgi的缺陷，如今出現了第三方(目前已經加入到PHP core中)的PHP的FastCGI處理器PHP-FPM，它和spawn-fcgi比較起來有以下優勢：

       因爲它是做爲PHP的patch補丁來開發的，安裝的時候須要和php源碼一塊兒編譯，也就是說編譯到php core中了，所以在性能方面要優秀一些；

同時它在處理高併發方面也優於spawn-fcgi，至少不會自動重啓fastcgi處理器。所以，推薦使用Nginx+PHP/PHP-FPM這個組合對PHP進行解析。

      相對Spawn-FCGI，PHP-FPM在CPU和內存方面的控制都更勝一籌，並且前者很容易崩潰，必須用crontab進行監控，而PHP-FPM則沒有這種煩惱。
       FastCGI 的主要優勢是把動態語言和HTTP Server分離開來，因此Nginx與PHP/PHP-FPM常常被部署在不一樣的服務器上，以分擔前端Nginx服務器的壓力，使Nginx專注處理靜態請求和轉發動態請求，而PHP/PHP-FPM服務器專注解析PHP動態請求。

四、Nginx+PHP-FPM

      PHP-FPM是管理FastCGI的一個管理器，它做爲PHP的插件存在，在安裝PHP要想使用PHP-FPM時在老php的老版本（php5.3.3以前）就須要把PHP-FPM以補丁的形式安裝到PHP中，並且PHP要與PHP-FPM版本一致，這是必須的）

　  PHP-FPM實際上是PHP源代碼的一個補丁，旨在將FastCGI進程管理整合進PHP包中。必須將它patch到你的PHP源代碼中，在編譯安裝PHP後纔可使用。
　  PHP5.3.3已經集成php-fpm了，再也不是第三方的包了。PHP-FPM提供了更好的PHP進程管理方式，能夠有效控制內存和進程、能夠平滑重載PHP配置，比spawn-fcgi具備更多優勢，因此被PHP官方收錄了。在./configure的時候帶 –enable-fpm參數便可開啓PHP-FPM。

      fastcgi已經在php5.3.5的core中了，沒必要在configure時添加 --enable-fastcgi了。老版本如php5.2的須要加此項。

      當咱們安裝Nginx和PHP-FPM完後，配置信息：

     PHP-FPM的默認配置php-fpm.conf：
     listen_address  127.0.0.1:9000 #這個表示php的fastcgi進程監聽的ip地址以及端口
      start_servers
      min_spare_servers
      max_spare_servers
 
      Nginx配置運行php： 編輯nginx.conf加入以下語句：
      location ~ \.php$ {
            root html;   
            fastcgi_pass 127.0.0.1:9000; 指定了fastcgi進程偵聽的端口,nginx就是經過這裏與php交互的
            fastcgi_index index.php;
            include fastcgi_params;
             fastcgi_param SCRIPT_FILENAME   /usr/local/nginx/html$fastcgi_script_name;
    }
    Nginx經過location指令，將全部以php爲後綴的文件都交給127.0.0.1:9000來處理，而這裏的IP地址和端口就是FastCGI進程監聽的IP地址和端口。
   
     其總體工做流程：
     1)、FastCGI進程管理器php-fpm自身初始化，啓動主進程php-fpm和啓動start_servers個CGI 子進程。
           主進程php-fpm主要是管理fastcgi子進程，監聽9000端口。
           fastcgi子進程等待來自Web Server的鏈接。
     2)、當客戶端請求到達Web Server Nginx是時，Nginx經過location指令，將全部以php爲後綴的文件都交給127.0.0.1:9000來處理，即Nginx經過location指令，將全部以php爲後綴的文件都交給127.0.0.1:9000來處理。
      3）FastCGI進程管理器PHP-FPM選擇並鏈接到一個子進程CGI解釋器。Web server將CGI環境變量和標準輸入發送到FastCGI子進程。
      4)、FastCGI子進程完成處理後將標準輸出和錯誤信息從同一鏈接返回Web Server。當FastCGI子進程關閉鏈接時，請求便告處理完成。
      5)、FastCGI子進程接着等待並處理來自FastCGI進程管理器（運行在 WebServer中）的下一個鏈接。
 

4.   Nginx+PHP正確配置

通常web都作統一入口：把PHP請求都發送到同一個文件上，而後在此文件裏經過解析「REQUEST_URI」實現路由。

Nginx配置文件分爲好多塊，常見的從外到內依次是「http」、「server」、「location」等等，缺省的繼承關係是從外到內，也就是說內層塊會自動獲取外層塊的值做爲缺省值。

例如：

 

[plain]  view plain  copy
 
 print?
  1. server {  
  2.     listen 80;  
  3.     server_name foo.com;  
  4.     root /path;  
  5.     location / {  
  6.         index index.html index.htm index.php;  
  7.         if (!-e $request_filename) {  
  8.             rewrite . /index.php last;  
  9.         }  
  10.     }  
  11.     location ~ \.php$ {  
  12.         include fastcgi_params;  
  13.         fastcgi_param SCRIPT_FILENAME /path$fastcgi_script_name;  
  14.         fastcgi_pass 127.0.0.1:9000;  
  15.         fastcgi_index index.php;  
  16.     }  
  17. }   


 

1)  不該該在location 模塊定義index
一旦將來須要加入新的「location」，必然會出現重複定義的「index」指令，這是由於多個「location」是平級的關係，不存在繼承，此時應該在「server」裏定義「index」，藉助繼承關係，「index」指令在全部的「location」中都能生效。

2)     使用try_files
接下來看看「if」指令，說它是你們誤解最深的Nginx指令絕不爲過：

if (!-e $request_filename) {

rewrite . /index.php last;

}

不少人喜歡用「if」指令作一系列的檢查，不過這其實是「try_files」指令的職責：

try_files $uri $uri/ /index.php;


除此之外，初學者每每會認爲「if」指令是內核級的指令，可是實際上它是rewrite模塊的一部分，加上Nginx配置其實是聲明式的，而非過程式的，因此當其和非rewrite模塊的指令混用時，結果可能會非你所願。


3）fastcgi_params」配置文件：

include fastcgi_params;

Nginx有兩份fastcgi配置文件，分別是「fastcgi_params」和「fastcgi.conf」，它們沒有太大的差別，惟一的區別是後者比前者多了一行「SCRIPT_FILENAME」的定義：

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;


注意：$document_root 和 $fastcgi_script_name 之間沒有 /。

本來Nginx只有「fastcgi_params」，後來發現不少人在定義「SCRIPT_FILENAME」時使用了硬編碼的方式，因而爲了規範用法便引入了「fastcgi.conf」。


不過這樣的話就產生一個疑問：爲何必定要引入一個新的配置文件，而不是修改舊的配置文件？這是由於「fastcgi_param」指令是數組型的，和普通指令相同的是：內層替換外層；和普通指令不一樣的是：當在同級屢次使用的時候，是新增而不是替換。換句話說，若是在同級定義兩次「SCRIPT_FILENAME」，那麼它們都會被髮送到後端，這可能會致使一些潛在的問題，爲了不此類狀況，便引入了一個新的配置文件。


此外，咱們還須要考慮一個安全問題：在PHP開啓「cgi.fix_pathinfo」的狀況下，PHP可能會把錯誤的文件類型看成PHP文件來解析。若是Nginx和PHP安裝在同一臺服務器上的話，那麼最簡單的解決方法是用「try_files」指令作一次過濾：


try_files $uri =404;

依照前面的分析，給出一份改良後的版本，是否是比開始的版本清爽了不少：

 

[plain]  view plain  copy
 
 print?
  1. server {  
  2.     listen 80;  
  3.     server_name foo.com;  
  4.     root /path;  
  5.     index index.html index.htm index.php;  
  6.     location / {  
  7.         try_files $uri $uri/ /index.php;  
  8.     }  
  9.     location ~ \.php$ {  
  10.        try_files $uri =404;  
  11.        include fastcgi.conf;  
  12.        fastcgi_pass 127.0.0.1:9000;  
  13.    }  
  14. }  


 

 
 

5.   Nginx爲啥性能高－多進程IO模型

      參考http://mp.weixin.qq.com/s?__biz=MjM5NTg2NTU0Ng==&mid=407889757&idx=3&sn=cfa8a70a5fd2a674a91076f67808273c&scene=23&srcid=0401aeJQEraSG6uvLj69Hfve#rd

一、nginx採用多進程模型好處

      首先，對於每一個worker進程來講，獨立的進程，不須要加鎖，因此省掉了鎖帶來的開銷，同時在編程以及問題查找時，也會方便不少。

      其次，採用獨立的進程，可讓互相之間不會影響，一個進程退出後，其它進程還在工做，服務不會中斷，master進程則很快啓動新的worker進程。固然，worker進程的異常退出，確定是程序有bug了，異常退出，會致使當前worker上的全部請求失敗，不過不會影響到全部請求，因此下降了風險。

一、nginx多進程事件模型：異步非阻塞

         雖然nginx採用多worker的方式來處理請求，每一個worker裏面只有一個主線程，那可以處理的併發數頗有限啊，多少個worker就能處理多少個併發，何來高併發呢？非也，這就是nginx的高明之處，nginx採用了異步非阻塞的方式來處理請求，也就是說，nginx是能夠同時處理成千上萬個請求的。一個worker進程能夠同時處理的請求數只受限於內存大小，並且在架構設計上，不一樣的worker進程之間處理併發請求時幾乎沒有同步鎖的限制，worker進程一般不會進入睡眠狀態，所以，當Nginx上的進程數與CPU核心數相等時（最好每個worker進程都綁定特定的CPU核心），進程間切換的代價是最小的。

       而apache的經常使用工做方式（apache也有異步非阻塞版本，但因其與自帶某些模塊衝突，因此不經常使用），每一個進程在一個時刻只處理一個請求，所以，當併發數上到幾千時，就同時有幾千的進程在處理請求了。這對操做系統來講，是個不小的挑戰，進程帶來的內存佔用很是大，進程的上下文切換帶來的cpu開銷很大，天然性能就上不去了，而這些開銷徹底是沒有意義的。

     

 

         爲何nginx能夠採用異步非阻塞的方式來處理呢，或者異步非阻塞究竟是怎麼回事呢？

         咱們先回到原點，看看一個請求的完整過程:首先，請求過來，要創建鏈接，而後再接收數據，接收數據後，再發送數據。

         具體到系統底層，就是讀寫事件，而當讀寫事件沒有準備好時，必然不可操做，若是不用非阻塞的方式來調用，那就得阻塞調用了，事件沒有準備好，那就只能等了，等事件準備好了，你再繼續吧。阻塞調用會進入內核等待，cpu就會讓出去給別人用了，對單線程的worker來講，顯然不合適，當網絡事件越多時，你們都在等待呢，cpu空閒下來沒人用，cpu利用率天然上不去了，更別談高併發了。好吧，你說加進程數，這跟apache的線程模型有什麼區別，注意，別增長無謂的上下文切換。因此，在nginx裏面，最忌諱阻塞的系統調用了。不要阻塞，那就非阻塞嘍。非阻塞就是，事件沒有準備好，立刻返回EAGAIN，告訴你，事件還沒準備好呢，你慌什麼，過會再來吧。好吧，你過一會，再來檢查一下事件，直到事件準備好了爲止，在這期間，你就能夠先去作其它事情，而後再來看看事件好了沒。雖然不阻塞了，但你得不時地過來檢查一下事件的狀態，你能夠作更多的事情了，但帶來的開銷也是不小的。

關於IO模型：http://blog.csdn.net/hguisu/article/details/7453390

       nginx支持的事件模型以下（nginx的wiki）:

       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的事件處理模型：

 

[cpp]  view plain  copy
 
 print?
  1. while (true) {  
  2.     for t in run_tasks:  
  3.         t.handler();  
  4.     update_time(&now);  
  5.     timeout = ETERNITY;  
  6.     for t in wait_tasks: /* sorted already */  
  7.         if (t.time <= now) {  
  8.             t.timeout_handler();  
  9.         } else {  
  10.             timeout = t.time - now;  
  11.             break;  
  12.         }  
  13.     nevents = poll_function(events, timeout);  
  14.     for i in nevents:  
  15.         task t;  
  16.         if (events[i].type == READ) {  
  17.             t.handler = read_handler;  
  18.         } else { /* events[i].type == WRITE */  
  19.             t.handler = write_handler;  
  20.         }  
  21.         run_tasks_add(t);  
  22. }  

 

 

6.   Nginx優化

 1.　編譯安裝過程優化

1）.減少Nginx編譯後的文件大小

在編譯Nginx時，默認以debug模式進行，而在debug模式下會插入不少跟蹤和ASSERT之類的信息，編譯完成後，一個Nginx要有好幾兆字節。而在編譯前取消Nginx的debug模式，編譯完成後Nginx只有幾百千字節。所以能夠在編譯以前，修改相關源碼，取消debug模式。具體方法以下：

在Nginx源碼文件被解壓後，找到源碼目錄下的auto/cc/gcc文件，在其中找到以下幾行：

 

  1. # debug  
  2. CFLAGS=」$CFLAGS -g」 

 

註釋掉或刪掉這兩行，便可取消debug模式。

2.爲特定的CPU指定CPU類型編譯優化

在編譯Nginx時，默認的GCC編譯參數是「-O」，要優化GCC編譯，可使用如下兩個參數：

 

  1. --with-cc-opt='-O3' 
  2. --with-cpu-opt=CPU  #爲特定的 CPU 編譯，有效的值包括：
    pentium, pentiumpro, pentium3, # pentium4, athlon, opteron, amd64, sparc32, sparc64, ppc64 

 

要肯定CPU類型，能夠經過以下命令：

 

  1. [root@localhost home]#cat /proc/cpuinfo | grep "model name" 

2. 利用TCMalloc優化Nginx的性能

TCMalloc的全稱爲Thread-Caching Malloc，是谷歌開發的開源工具google-perftools中的一個成員。與標準的glibc庫的Malloc相比，TCMalloc庫在內存分配效率和速度上要高不少，這在很大程度上提升了服務器在高併發狀況下的性能，從而下降了系統的負載。下面簡單介紹如何爲Nginx添加TCMalloc庫支持。

要安裝TCMalloc庫，須要安裝libunwind（32位操做系統不須要安裝）和google-perftools兩個軟件包，libunwind庫爲基於64位CPU和操做系統的程序提供了基本函數調用鏈和函數調用寄存器功能。下面介紹利用TCMalloc優化Nginx的具體操做過程。

1).安裝libunwind庫

能夠從http://download.savannah.gnu.org/releases/libunwind下載相應的libunwind版本，這裏下載的是libunwind-0.99-alpha.tar.gz。安裝過程以下：

 

 

  1. [root@localhost home]#tar zxvf libunwind-0.99-alpha.tar.gz  
  2. [root@localhost home]# cd libunwind-0.99-alpha/  
  3. [root@localhost libunwind-0.99-alpha]#CFLAGS=-fPIC ./configure  
  4. [root@localhost libunwind-0.99-alpha]#make CFLAGS=-fPIC  
  5. [root@localhost libunwind-0.99-alpha]#make CFLAGS=-fPIC install 

2).安裝google-perftools

能夠從http://google-perftools.googlecode.com下載相應的google-perftools版本，這裏下載的是google-perftools-1.8.tar.gz。安裝過程以下：

 

  1. [root@localhost home]#tar zxvf google-perftools-1.8.tar.gz  
  2. [root@localhost home]#cd google-perftools-1.8/  
  3. [root@localhost google-perftools-1.8]# ./configure  
  4. [root@localhost google-perftools-1.8]#make && make install  
  5. [root@localhost google-perftools-1.8]#echo "/usr/
    local/lib" > /etc/ld.so.conf.d/usr_local_lib.conf  
  6. [root@localhost google-perftools-1.8]# ldconfig 

至此，google-perftools安裝完成。

3).從新編譯Nginx

爲了使Nginx支持google-perftools，須要在安裝過程當中添加「–with-google_perftools_module」選項從新編譯Nginx。安裝代碼以下：

 

  1. [root@localhostnginx-0.7.65]#./configure \  
  2. >--with-google_perftools_module --with-http_stub_status_module  --prefix=/opt/nginx  
  3. [root@localhost nginx-0.7.65]#make  
  4. [root@localhost nginx-0.7.65]#make install 

到這裏Nginx安裝完成。

4).爲google-perftools添加線程目錄

建立一個線程目錄，這裏將文件放在/tmp/tcmalloc下。操做以下：

 

  1. [root@localhost home]#mkdir /tmp/tcmalloc  
  2. [root@localhost home]#chmod 0777 /tmp/tcmalloc 

5).修改Nginx主配置文件

修改nginx.conf文件，在pid這行的下面添加以下代碼：

 

  1. #pid        logs/nginx.pid;  
  2. google_perftools_profiles /tmp/tcmalloc; 

接着，重啓Nginx便可完成google-perftools的加載。

6).驗證運行狀態

爲了驗證google-perftools已經正常加載，可經過以下命令查看：

 

  1. [root@ localhost home]# lsof -n | grep tcmalloc  
  2. nginx      2395 nobody   9w  REG    8,8       0    1599440 /tmp/tcmalloc.2395  
  3. nginx      2396 nobody   11w REG   8,8       0    1599443 /tmp/tcmalloc.2396  
  4. nginx      2397 nobody   13w REG  8,8        0    1599441  /tmp/tcmalloc.2397  
  5. nginx     2398 nobody    15w REG  8,8     0    1599442 /tmp/tcmalloc.2398 

因爲在Nginx配置文件中設置worker_processes的值爲4，所以開啓了4個Nginx線程，每一個線程會有一行記錄。每一個線程文件後面的數字值就是啓動的Nginx的pid值。

至此，利用TCMalloc優化Nginx的操做完成。

3.Nginx內核參數優化

 

內核參數的優化，主要是在Linux系統中針對Nginx應用而進行的系統內核參數優化。

下面給出一個優化實例以供參考。

 

 

  1. net.ipv4.tcp_max_tw_buckets = 6000 
  2. net.ipv4.ip_local_port_range = 1024 65000  
  3. net.ipv4.tcp_tw_recycle = 1 
  4. net.ipv4.tcp_tw_reuse = 1 
  5. net.ipv4.tcp_syncookies = 1 
  6. net.core.somaxconn = 262144 
  7. net.core.netdev_max_backlog = 262144 
  8. net.ipv4.tcp_max_orphans = 262144 
  9. net.ipv4.tcp_max_syn_backlog = 262144 
  10. net.ipv4.tcp_synack_retries = 1 
  11. net.ipv4.tcp_syn_retries = 1 
  12. net.ipv4.tcp_fin_timeout = 1 
  13. net.ipv4.tcp_keepalive_time = 30 

 

將上面的內核參數值加入/etc/sysctl.conf文件中，而後執行以下命令使之生效：

  1. [root@ localhost home]#/sbin/sysctl -p 

下面對實例中選項的含義進行介紹：

TCP參數設置：

net.ipv4.tcp_max_tw_buckets ：選項用來設定timewait的數量，默認是180 000，這裏設爲6000。

net.ipv4.ip_local_port_range:選項用來設定容許系統打開的端口範圍。在高併發狀況不然端口號會不夠用。當NGINX充當代理時，每一個到上游服務器的鏈接都使用一個短暫或臨時端口。

net.ipv4.tcp_tw_recycle:選項用於設置啓用timewait快速回收.

net.ipv4.tcp_tw_reuse:選項用於設置開啓重用，容許將TIME-WAIT sockets從新用於新的TCP鏈接。

net.ipv4.tcp_syncookies:選項用於設置開啓SYN Cookies，當出現SYN等待隊列溢出時，啓用cookies進行處理。

net.ipv4.tcp_max_orphans:選項用於設定系統中最多有多少個TCP套接字不被關聯到任何一個用戶文件句柄上。若是超過這個數字，孤立鏈接將當即被複位並打印出警告信息。這個限制只是爲了防止簡單的DoS攻擊。不能過度依靠這個限制甚至人爲減少這個值，更多的狀況下應該增長這個值。

net.ipv4.tcp_max_syn_backlog:選項用於記錄那些還沒有收到客戶端確認信息的鏈接請求的最大值。對於有128MB內存的系統而言，此參數的默認值是1024，對小內存的系統則是128。

net.ipv4.tcp_synack_retries參數的值決定了內核放棄鏈接以前發送SYN+ACK包的數量。

net.ipv4.tcp_syn_retries選項表示在內核放棄創建鏈接以前發送SYN包的數量。

net.ipv4.tcp_fin_timeout選項決定了套接字保持在FIN-WAIT-2狀態的時間。默認值是60秒。正確設置這個值很是重要，有時即便一個負載很小的Web服務器，也會出現大量的死套接字而產生內存溢出的風險。

net.ipv4.tcp_syn_retries選項表示在內核放棄創建鏈接以前發送SYN包的數量。

若是發送端要求關閉套接字，net.ipv4.tcp_fin_timeout選項決定了套接字保持在FIN-WAIT-2狀態的時間。接收端能夠出錯並永遠不關閉鏈接，甚至意外宕機。

net.ipv4.tcp_fin_timeout的默認值是60秒。須要注意的是，即便一個負載很小的Web服務器，也會出現由於大量的死套接字而產生內存溢出的風險。FIN-WAIT-2的危險性比FIN-WAIT-1要小，由於它最多隻能消耗1.5KB的內存，可是其生存期長些。

net.ipv4.tcp_keepalive_time選項表示當keepalive啓用的時候，TCP發送keepalive消息的頻度。默認值是2（單位是小時）。

 

緩衝區隊列:

net.core.somaxconn:選項的默認值是128， 這個參數用於調節系統同時發起的tcp鏈接數，在高併發的請求中，默認的值可能會致使連接超時或者重傳，所以，須要結合併發請求數來調節此值。

 由NGINX可接受的數目決定。默認值一般很低，但能夠接受，由於NGINX 接收鏈接很是快，但若是網站流量大時，就應該增長這個值。內核日誌中的錯誤消息會提醒這個值過小了，把值改大，直到錯誤提示消失。
注意： 若是設置這個值大於512，相應地也要改變NGINX listen指令的backlog參數。

net.core.netdev_max_backlog:選項表示當每一個網絡接口接收數據包的速率比內核處理這些包的速率快時，容許發送到隊列的數據包的最大數目。

 

 

4.　PHP-FPM的優化

若是您高負載網站使用PHP-FPM管理FastCGI，這些技巧也許對您有用:

1）增長FastCGI進程數

把PHP FastCGI子進程數調到100或以上，在4G內存的服務器上200就能夠建議經過壓力測試獲取最佳值。

2）增長 PHP-FPM打開文件描述符的限制

標籤rlimit_files用於設置PHP-FPM對打開文件描述符的限制，默認值爲1024。這個標籤的值必須和Linux內核打開文件數關聯起來，例如，要將此值設置爲65 535，就必須在Linux命令行執行「ulimit -HSn 65536」。

       而後 增長 PHP-FPM打開文件描述符的限制:
     # vi /path/to/php-fpm.conf
    找到「<valuename="rlimit_files">1024</value>」
把1024更改成 4096或者更高.
重啓 PHP-FPM.

       ulimit -n 要調整爲65536甚至更大。如何調這個參數，能夠參考網上的一些文章。命令行下執行 ulimit -n 65536便可修改。若是不能修改，須要設置  /etc/security/limits.conf，加入

* hard nofile65536

* soft nofile 65536



 

         3）適當增長max_requests

    標籤max_requests指明瞭每一個children最多處理多少個請求後便會被關閉，默認的設置是500。

    <value name="max_requests"> 500 </value>

   

 

 

   4.nginx.conf的參數優化

 

 

nginx要開啓的進程數 通常等於cpu的總核數 其實通常狀況下開4個或8個就能夠。

    每一個nginx進程消耗的內存10兆的模樣

worker_cpu_affinity
    僅適用於linux，使用該選項能夠綁定worker進程和CPU（2.4內核的機器用不了）

    假如是8 cpu 分配以下：
    worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000

00100000 01000000 10000000

    nginx可使用多個worker進程，緣由以下：

to use SMP 
to decrease latency when workers blockend on disk I/O 
to limit number of connections per process when select()/poll() is

used The worker_processes and worker_connections from the event sections

allows you to calculate maxclients value: k max_clients = worker_processes * worker_connections

 

worker_rlimit_nofile 102400;

    每一個nginx進程打開文件描述符最大數目 配置要和系統的單進程打開文件數一致,linux 2.6內核下開啓文件打開數爲65535，worker_rlimit_nofile就相應應該填寫65535 nginx調度時分配請求到進程並非那麼的均衡，假如超過會返回502錯誤。我這裏寫的大一點

use epoll

    Nginx使用了最新的epoll（Linux 2.6內核）和kqueue（freebsd）網絡I/O模型，而Apache則使用的是傳統的select模型。

處理大量的鏈接的讀寫，Apache所採用的select網絡I/O模型很是低效。在高併發服務器中，輪詢I/O是最耗時間的操做 目前Linux下可以承受高併發

    訪問的Squid、Memcached都採用的是epoll網絡I/O模型。

worker_processes 

    NGINX工做進程數（默認值是1）。在大多數狀況下，一個CPU內核運行一個工做進程最好，建議將這個指令設置成自動就能夠。有時可能想增大這個值，好比當工做進程須要作大量的磁盤I/O。

worker_connections 65535;
   每一個工做進程容許最大的同時鏈接數 （Maxclient = work_processes *　worker_connections）

keepalive_timeout 75

    keepalive超時時間

    這裏須要注意官方的一句話：
The parameters can differ from each other. Line Keep-Alive:

timeout=time understands Mozilla and Konqueror. MSIE itself shuts

keep-alive connection approximately after 60 seconds.

 

client_header_buffer_size 16k
large_client_header_buffers 4 32k
客戶請求頭緩衝大小 
nginx默認會用client_header_buffer_size這個buffer來讀取header值，若是header過大，它會使用large_client_header_buffers來讀取

若是設置太小HTTP頭/Cookie過大 會報400 錯誤 nginx 400 bad request
求行若是超過buffer，就會報HTTP 414錯誤(URI Too Long) nginx接受最長的HTTP頭部大小必須比其中一個buffer大，不然就會報400的HTTP錯誤(Bad Request)。

open_file_cache max 102400

使用字段:http, server, location 這個指令指定緩存是否啓用,若是啓用,將記錄文件如下信息: ·打開的文件描述符,大小信息和修改時間. ·存在的目錄信息. ·在搜索文件過程當中的錯誤信息 -- 沒有這個文件,沒法正確讀取,參考open_file_cache_errors 指令選項:
·max - 指定緩存的最大數目,若是緩存溢出,最長使用過的文件(LRU)將被移除
例: open_file_cache max=1000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on;

open_file_cache_errors
語法:open_file_cache_errors on | off 默認值:open_file_cache_errors off 使用字段:http, server, location 這個指令指定是否在搜索一個文件是記錄cache錯誤.

open_file_cache_min_uses

語法:open_file_cache_min_uses number 默認值:open_file_cache_min_uses 1 使用字段:http, server, location 這個指令指定了在open_file_cache指令無效的參數中必定的時間範圍內可使用的最小文件數,如 果使用更大的值,文件描述符在cache中老是打開狀態.
open_file_cache_valid

語法:open_file_cache_valid time 默認值:open_file_cache_valid 60 使用字段:http, server, location 這個指令指定了什麼時候須要檢查open_file_cache中緩存項目的有效信息.


開啓gzip
gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.0;
gzip_comp_level 2;
gzip_types text/plain application/x-javascript text/css

application/xml;
gzip_vary on;

緩存靜態文件：

location ~* ^.+\.(swf|gif|png|jpg|js|css)$ {
root /usr/local/ku6/ktv/show.ku6.com/;
expires 1m;
}

 

 

 

  5.訪問日誌
    記錄每一個請求會消耗CPU和I/O週期，一種下降這種影響的方式是緩衝訪問日誌。使用緩衝，而不是每條日誌記錄都單獨執行寫操做，NGINX會緩衝一連串的日誌記錄，使用單個操做把它們一塊兒寫到文件中。
    要啓用訪問日誌的緩存，就涉及到在access_log指令中buffer=size這個參數。當緩衝區達到size值時，NGINX會把緩衝區的內容寫到日誌中。讓NGINX在指定的一段時間後寫緩存，就包含flush=time參數。當兩個參數都設置了，當下個日誌條目超出緩衝區值或者緩衝區中日誌條目存留時間超過設定的時間值，NGINX都會將條目寫入日誌文件。當工做進程從新打開它的日誌文件或退出時，也會記錄下來。要徹底禁用訪問日誌記錄的功能，將access_log 指令設置成off參數。

 

   6.限流
你能夠設置多個限制，防止用戶消耗太多的資源，避免影響系統性能和用戶體驗及安全。 如下是相關的指令：
limit_conn and limit_conn_zone：NGINX接受客戶鏈接的數量限制，例如單個IP地址的鏈接。設置這些指令能夠防止單個用戶打開太多的鏈接，消耗超出本身的資源。
limit_rate：傳輸到客戶端響應速度的限制（每一個打開多個鏈接的客戶消耗更多的帶寬）。設置這個限制防止系統過載，確保全部客戶端更均勻的服務質量。
limit_req and limit_req_zone：NGINX處理請求的速度限制，與limit_rate有相同的功能。能夠提升安全性，尤爲是對登陸頁面，經過對用戶限制請求速率設置一個合理的值，避免太慢的程序覆蓋你的應用請求（好比DDoS攻擊)。
max_conns：上游配置塊中服務器指令參數。在上游服務器組中單個服務器可接受最大併發數量。使用這個限制防止上游服務器過載。設置值爲0（默認值）表示沒有限制。
queue (NGINX Plus) ：建立一個隊列，用來存放在上游服務器中超出他們最大max_cons限制數量的請求。這個指令能夠設置隊列請求的最大值，還能夠選擇設置在錯誤返回以前最大等待時間（默認值是60秒）。若是忽略這個指令，請求不會放入隊列。

 

 

 

 

7.   錯誤排查

一、Nginx 502 Bad Gateway

php-cgi進程數不夠用、php執行時間長（mysql慢）、或者是php-cgi進程死掉，都會出現502錯誤

通常來講Nginx 502 Bad Gateway和php-fpm.conf的設置有關，而Nginx 504 Gateway Time-out則是與nginx.conf的設置有關

1）、查看當前的PHP FastCGI進程數是否夠用：

netstat -anpo | grep "php-cgi" | wc -l

　　若是實際使用的「FastCGI進程數」接近預設的「FastCGI進程數」，那麼，說明「FastCGI進程數」不夠用，須要增大。

2）、部分PHP程序的執行時間超過了Nginx的等待時間，能夠適當增長

     nginx.conf配置文件中FastCGI的timeout時間，例如：

http {
    ......
    fastcgi_connect_timeout 300;
    fastcgi_send_timeout 300;
    fastcgi_read_timeout 300;
    ......
}


二、413 Request Entity Too Large
     解決：增大client_max_body_size

    client_max_body_size:指令指定容許客戶端鏈接的最大請求實體大小,它出如今請求頭部的Content-Length字段. 若是請求大於指定的值,客戶端將收到一個"Request Entity Too Large" (413)錯誤. 記住,瀏覽器並不知道怎樣顯示這個錯誤.

    php.ini中增大
post_max_size 和upload_max_filesize

3 Ngnix error.log出現：upstream sent too big header while reading response header from upstream錯誤

1)若是是nginx反向代理
   proxy是nginx做爲client轉發時使用的，若是header過大，超出了默認的1k，就會引起上述的upstream sent too big header （說白了就是nginx把外部請求給後端server，後端server返回的header  太大nginx處理不過來就致使了。

  server {
        listen       80;
        server_name  *.xywy.com ;

        large_client_header_buffers 4 16k;

        location / {

          #添加這3行 
           proxy_buffer_size 64k;
           proxy_buffers   32 32k;
           proxy_busy_buffers_size 128k;

           proxy_set_header Host $host;
           proxy_set_header X-Real-IP       $remote_addr;
           proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;

    }

}         

 

2) 若是是 nginx+PHPcgi 

  錯誤帶有 upstream: "fastcgi://127.0.0.1:9000"。就該 

  多加：

  fastcgi_buffer_size 128k;
  fastcgi_buffers 4 128k;

 

server {
        listen       80;
        server_name  ddd.com;
        index index.html index.htm index.php;
   
        client_header_buffer_size 128k;
        large_client_header_buffers 4 128k;
        proxy_buffer_size 64k;
        proxy_buffers 8 64k;
        fastcgi_buffer_size 128k;
        fastcgi_buffers 4 128k;

 

        location / {

          ......

        }

}         

 

 

8.   Nginx的php漏洞

 

漏洞介紹：nginx是一款高性能的web服務器，使用很是普遍，其不只常常被用做反向代理，也能夠很是好的支持PHP的運行。80sec發現其中存在一個較爲嚴重的安全問題，默認狀況下可能致使服務器錯誤的將任何類型的文件以PHP的方式進行解析，這將致使嚴重的安全問題，使得惡意的攻擊者可能攻陷支持php的nginx服務器。


漏洞分析：nginx默認以cgi的方式支持php的運行，譬如在配置文件當中能夠以


location ~ .php$ {
root html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
include fastcgi_params;
}

的方式支持對php的解析，location對請求進行選擇的時候會使用URI環境變量進行選擇，其中傳遞到後端Fastcgi的關鍵變量SCRIPT_FILENAME由nginx生成的$fastcgi_script_name決定，而經過分析能夠看到$fastcgi_script_name是直接由URI環境變量控制的，這裏就是產生問題的點。而爲了較好的支持PATH_INFO的提取，在PHP的配置選項裏存在cgi.fix_pathinfo選項，其目的是爲了從SCRIPT_FILENAME裏取出真正的腳本名。
那麼假設存在一個http://www.80sec.com/80sec.jpg，咱們以以下的方式去訪問

http://www.80sec.com/80sec.jpg/80sec.php


將會獲得一個URI

/80sec.jpg/80sec.php

通過location指令，該請求將會交給後端的fastcgi處理，nginx爲其設置環境變量SCRIPT_FILENAME，內容爲

/scripts/80sec.jpg/80sec.php

而在其餘的webserver如lighttpd當中，咱們發現其中的SCRIPT_FILENAME被正確的設置爲

/scripts/80sec.jpg

因此不存在此問題。
後端的fastcgi在接受到該選項時，會根據fix_pathinfo配置決定是否對SCRIPT_FILENAME進行額外的處理，通常狀況下若是不對fix_pathinfo進行設置將影響使用PATH_INFO進行路由選擇的應用，因此該選項通常配置開啓。Php經過該選項以後將查找其中真正的腳本文件名字，查找的方式也是查看文件是否存在，這個時候將分離出SCRIPT_FILENAME和PATH_INFO分別爲

/scripts/80sec.jpg和80sec.php

最後，以/scripts/80sec.jpg做爲這次請求須要執行的腳本，攻擊者就能夠實現讓nginx以php來解析任何類型的文件了。

POC： 訪問一個nginx來支持php的站點，在一個任何資源的文件如robots.txt後面加上/80sec.php，這個時候你能夠看到以下的區別：

訪問http://www.80sec.com/robots.txt

HTTP/1.1 200 OK
Server: nginx/0.6.32
Date: Thu, 20 May 2010 10:05:30 GMT
Content-Type: text/plain
Content-Length: 18
Last-Modified: Thu, 20 May 2010 06:26:34 GMT
Connection: keep-alive
Keep-Alive: timeout=20
Accept-Ranges: bytes

訪問訪問http://www.80sec.com/robots.txt/80sec.php

HTTP/1.1 200 OK
Server: nginx/0.6.32
Date: Thu, 20 May 2010 10:06:49 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=20
X-Powered-By: PHP/5.2.6

其中的Content-Type的變化說明了後端負責解析的變化，該站點就可能存在漏洞。

漏洞廠商：http://www.nginx.org

解決方案：

咱們已經嘗試聯繫官方，可是此前你能夠經過如下的方式來減小損失

關閉cgi.fix_pathinfo爲0

或者
if ( $fastcgi_script_name ~ ..*/.*php ) {return 403;}

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程