HTTP伺服器是如何?對PHP的支援的？_PHP教程

目前各種伺服器HTTP Server對PHP的支援一共有三種：

• 通過HTTP Server內建的模組來實現，例如Apache的mod_php5，類似的Apache內建的mod_perl可以對perl支援；
• 通過CGI來實現，這個就好比之前perl的CGI，該種方式的缺點是效能差，因為每次伺服器遇到這些指令碼都需要重新啟動指令碼解析器來執行指令碼然後將結果返回給伺服器，另一方面就是不太安全，該方面幾乎很少使用了。
• 最新出現一種叫做FastCGI。所謂FastCGI就是對CGI的改進。它一般採用C/S結構，一般指令碼處理器會啟動一個或者多個daemon進程，每次HTTP Server遇到指令碼的時候，直接交付給FastCGI的進程來執行，然後將得到的結果(通常為html)返回給瀏覽器。

FastCGI這種方法的問題存在一個小問題是當遇到大流量的頻繁請求的話，指令碼處理器的daemon進程可能會超負荷從而變得很慢，甚至發生記憶體流失。但是比較起Apache的內建模組的方式的優點是由於Server和指令碼解析器完全分開各負其責，因此伺服器不再臃腫，可以專心地進行靜態檔案響應或者將動態指令碼解析器的結果返回給使用者用戶端。所以比較起Apache的內建模組方式，有時候效能要提高很多。有人測試可能會達到Apache+mod_php的5~10倍。

使用FastCGI方式現在常見的有兩種stack：

• ligthttpd+spawn-fcgi
• nginx+PHP-FPM(也可以用spawn-fcgi) 

如上面所說該兩種結構都採用FastCGI對PHP支援，因此HTTP Server完全解放出來，可以更好地進行響應和並發處理。因此lighttpd和nginx都有small, but powerful和efficient的美譽。

該兩者還可以分出一個好壞來，spawn-fcgi由於是lighttpd的一部分，因此安裝了lighttpd一般就會使用spawn-fcgi對php支援，但是目前有使用者說ligttpd的spwan-fcgi在高並發訪問的時候，會出現上面說的記憶體流失甚至自動重啟fastcgi。即：PHP指令碼處理器當機，這個時候如果使用者訪問的話，可能就會出現白頁(即PHP不能被解析或者出錯)。

Nginx不像lighttpd本身含帶了fastcgi(spawn-fcgi)，因此它完全是輕量級的，必須藉助第三方的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（具體可以google）。它和spawn-fcgi比較起來有如下優點：

由於它是作為PHP的patch補丁來開發的，安裝的時候需要和php源碼一起編譯，也就是說編譯到php core中了，因此在效能方面要優秀一些。同時它在處理高並發方面也優於spawn-fcgi，至少不會自動重啟fastcgi處理器。具體採用的演算法和設計可以google瞭解。

因此，如上所說由於nginx的輕量和靈活性，因此目前效能優越，越來越多人逐漸使用這個組合：nginx+PHP/PHP-FPM 。

總結

目前在HTTPServer這塊基本可以看到有三種stack比較流行： 

• Apache+mod_php5
• lighttp+spawn-fcgi
• nginx+PHP-FPM

http://www.bkjia.com/PHPjc/752557.htmlwww.bkjia.comtruehttp://www.bkjia.com/PHPjc/752557.htmlTechArticle目前各種伺服器HTTP Server對PHP的支援一共有三種： 通過HTTP Server內建的模組來實現，例如Apache的mod_php5，類似的Apache內建的mod_perl可以對per...

