PHP運行模式的深刻理解

本篇文章是對PHP運行模式進行了詳細的分析介紹，須要的朋友參考下

 

PHP運行模式有4鍾：
1）cgi 通用網關接口（Common Gateway Interface)）
2） fast-cgi 常駐 (long-live) 型的 CGI
3） cli  命令行運行   （Command Line Interface）
4）web模塊模式 （apache等web服務器運行的模塊模式）
1.CGI（Common Gateway Interface）
CGI即通用網關接口(Common Gateway Interface)，它是一段程序, 通俗的講CGI就象是一座橋，把網頁和WEB服務器中的執行程序鏈接起來，它把HTML接收的指令傳遞給服務器的執行程序，再把服務器執行程序的結果返還給HTML頁。CGI 的跨平臺性能極佳，幾乎能夠在任何操做系統上實現。 CGI已是比較老的模式了，這幾年都不多用了。

每有一個用戶請求，都會先要建立cgi的子進程，而後處理請求，處理完後結束這個子進程，這就是fork-and-execute模式。 當用戶請求數量很是多時，會大量擠佔系統的資源如內存，CPU時間等，形成效能低下。因此用cgi方式的服務器有多少鏈接請求就會有多少cgi子進程，子進程反覆加載是cgi性能低下的主要緣由。
若是不想把 PHP 嵌入到服務器端軟件（如 Apache）做爲一個模塊安裝的話，能夠選擇以 CGI 的模式安裝。或者把 PHP 用於不一樣的 CGI 封裝以便爲代碼建立安全的 chroot 和 setuid 環境。這樣每一個客戶機請求一個php文件，Web服務器就調用php.exe（win下是php.exe,linux是php）去解釋這個文件，而後再把解釋的結果以網頁的形式返回給客戶機。 這種安裝方式一般會把 PHP 的可執行文件安裝到 web 服務器的 cgi-bin 目錄。CERT 建議書 CA-96.11 建議不要把任何的解釋器放到 cgi-bin 目錄。

這種方式的好處是把web server和具體的程序處理獨立開來，結構清晰，可控性強，同時缺點就是若是在高訪問需求的狀況下，cgi的進程fork就會成爲很大的服務器負擔，想 象一下數百個併發請求致使服務器fork出數百個進程就明白了。這也是爲何cgi一直揹負性能低下，高資源消耗的惡名的緣由。

CGI模式安裝：
CGI已是比較老的模式了，這幾年都不多用了,因此咱們只是爲了測試。
安裝CGI模式須要註釋掉
LoadModule php5_module modules/libphp5.so 這行。若是不註釋這行會一直走到handler模式。也就是模塊模式。
而後在httpd.conf增長action：
Action application/x-httpd-php /cgi-bin/
若是在/cgi-bin/目錄找不到php-cgi.可自行從php的bin裏面cp一個。
而後重啓apache,再打開測試頁面發現Server API變成：CGI/FastCGI。說明成功切換爲cgi模式。
問題：
1)  若是cgi程序放在/usr/local/httpd/cgi-bin/裏沒法執行，遇到403或500錯誤的話
打開apache錯誤日誌 有以下提示： Permission denied: exec of
能夠檢查cgi程序的屬性，按Linux contexts文件 裏定義的，/usr/local/httpd/cgi-bin/裏必須是httpd_sys_script_exec_t 屬性。  經過ls -Z查看，若是不是則經過以下命令更改： chcon -t httpd_sys_script_exec_t /var/www/cgi-bin/*.cgi 若是是虛擬主機裏的cgi，則參考問題2使之能正常使用普通的功能後，再經過chcon設置cgi文件的context爲
httpd_sys_script_exec_t便可。chcon -R -t httpd_sys_script_exec_t cgi-bin/
2) apache錯誤提示：.... malformed header from script. Bad header=
根據提示說明有header有問題，查看文件輸出的第一句話是什麼，應該相似於以下 
Content-type: text/plain; charset=iso-8859-1\n\n 
或者Content-type:text/html\n\n
注意：聲明好Content-type後要輸出兩個空行。
3）apache錯誤提示： Exec format error
腳本解釋器設置錯誤。腳本第一行應該以'#!解釋器路徑'的形式, 填寫腳本解釋器的路徑，若是是PERL程序，常見的路徑爲: #!/usr/bin/perl 或 #!/usr/local/bin/perl   若是是PHP程序，不須要填寫解釋器路徑，系統會自動找到PHP。
2. Fastcgi模式
fast-cgi 是cgi的升級版本，FastCGI 像是一個常駐 (long-live) 型的 CGI，它能夠一直執行着，只要激活後，不會每次都要花費時間去 fork 一次 (這是 CGI 最爲人詬病的 fork-and-execute 模式)。 
FastCGI的工做原理是：
(1)、Web Server啓動時載入FastCGI進程管理器【PHP的FastCGI進程管理器是PHP-FPM(php-FastCGI Process Manager)】（IIS ISAPI或Apache Module);
(2)、FastCGI進程管理器自身初始化，啓動多個CGI解釋器進程 (在任務管理器中可見多個php-cgi.exe)並等待來自Web Server的鏈接。
(3)、當客戶端請求到達Web Server時，FastCGI進程管理器選擇並鏈接到一個CGI解釋器。Web server將CGI環境變量和標準輸入發送到FastCGI子進程php-cgi。
(4)、FastCGI子進程完成處理後將標準輸出和錯誤信息從同一鏈接返回Web Server。當FastCGI子進程關閉鏈接時，請求便告處理完成。FastCGI子進程接着等待並處理來自FastCGI進程管理器（運行在 WebServer中）的下一個鏈接。在正常的CGI模式中，php-cgi.exe在此便退出了。
在CGI模式中，你能夠想象 CGI一般有多慢。每個Web請求PHP都必須從新解析php.ini、從新載入所有dll擴展並重初始化所有數據結構。使用FastCGI，全部這些都只在進程啓動時發生一次。一個額外的好處是，持續數據庫鏈接(Persistent database connection)能夠工做。
Fastcgi的優勢：
1）從穩定性上看, fastcgi是以獨立的進程池運行來cgi,單獨一個進程死掉,系統能夠很輕易的丟棄,而後從新分 配新的進程來運行邏輯.
2）從安全性上看,Fastcgi支持分佈式運算. fastcgi和宿主的server徹底獨立, fastcgi怎麼down也不會把server搞垮.
3）從性能上看, fastcgi把動態邏輯的處理從server中分離出來, 大負荷的IO處理仍是留給宿主server, 這樣宿主server能夠一心一意做IO,對於一個普通的動態網頁來講, 邏輯處理可能只有一小部分, 大量的圖片等靜態 
FastCGI缺點：說完了好處，也來講說缺點。從個人實際使用來看，用FastCGI模式更適合生產環境的服務器。但對於開發用機器來講就不太合適。由於當使用 Zend Studio調試程序時，因爲 FastCGI會認爲 PHP進程超時，從而在頁面返回 500錯誤。這一點讓人很是惱火，因此我在開發機器上仍是換回了 ISAPI模式。
安裝fastcgi模式：
安裝apache路徑是/usr/local/httpd/
安裝php路徑是/usr/local/php/
1）安裝mod_fastcgi
wget http://www.fastcgi.com/dist/mod_fastcgi-2.4.6.tar.gz
tar zxvf mod_fastcgi-2.4.6.tar.gz
cd mod_fastcgi-2.4.6
cp Makefile.AP2 Makefile
vi Makefile，編輯top_dir = /usr/local/httpd
make
make install
安裝完後，
/usr/local/httpd/modules/多出一個文件：mod_fcgid.so
2）從新編譯php
./configure --prefix=/usr/local/php --enable-fastcgi --enable-force-cgi-redirect --disable-cli
make 
make install
這樣編譯後，在PHP的bin目錄下的php-cgi就是fastcgi模式的php解釋器了
安裝成功後,執行
php -v 輸出
PHP 5.3.2 (cgi-fcgi).
這裏輸出帶了cgi-fcgi
注意：
1.編譯參數不能加 –with-apxs=/usr/local/httpd/bin/apxs 不然安裝出來的php執行文件是cli模式的
2 若是編譯時不加--disable-cli則輸出 PHP 5.3.2(cli)

3)配置apache
須要配置apache來以fastcgi模式運行php程序
vi httpd.conf
咱們使用虛擬機的方式實現：

複製代碼代碼以下:

#加載fastcgi模塊
LoadModule fastcgi_module modules/mod_fastcgi.so
#//以靜態方式執行fastcgi 啓動了10進程
FastCgiServer /usr/local/php/bin/php-cgi  -processes 10 -idle-timeout 150 -pass-header HTTP_AUTHORIZATION
<VirtualHost *:80>
 #
 DocumentRoot   /usr/local/httpd/fcgi-bin   
 ServerName www.fastcgitest.com

 ScriptAlias /fcgi-bin/   /usr/local/php/bin/   #定義目錄映射 /fcgi-bin/ 代替 /usr/local/php/bin/
 Options +ExecCGI
 AddHandler fastcgi-script .php .fcgi #.php結尾的請求都要用php-fastcgi來處理  
 AddType application/x-httpd-php .php #增長MIME類型
 Action application/x-httpd-php /fcgi-bin/php-cgi  #設置php-fastcgi的處理器： /usr/local/php/bin/php-cgi
 <Directory /usr/local/httpd/fcgi-bin/>
  Options Indexes ExecCGI
  Order allow,deny
  allow from all
 </Directory>
</VirtualHost>

或者

複製代碼代碼以下:

<IfModule mod_fastcgi>ScriptAlias /fcgi-bin/ "/usr/local/php/bin" #定義目錄映射FastCgiServer /usr/local/php/bin/php-cgi   -processes 10 #配置fastcgi server，<Directory "/usr/local/httpd/fcgi-bin/">SetHandler fastcgi-scriptOptions FollowSymLinksOrder allow,denyAllow from all</Directory>AddType application/x-httpd-php .php  #增長MIME類型AddHandler php-fastcgi .php   #.php結尾的請求都要用php-fastcgi來處理Action php-fastcgi /fcgi-bin/php-cgi #設置php-fastcgi的處理器 
</IfModule>

4）.restart 下apache,查看phpinfo，若是服務器信息是：
Apache/2.2.11 (Unix) mod_fastcgi/2.4.6之類的就說明安裝成功了。
若是出現403的錯誤，查看下/usr/local/httpd/fcgi-bin/是否有足夠的權限。
或者

複製代碼代碼以下:

<Directory />
Options FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
</Directory>

改成：

複製代碼代碼以下:

<Directory />
Options FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
</Directory>

就能夠了。
ps -ef|grep  php-cgi能夠看見10個fastcgi進程在跑。
3. CLI模式
cli是php的命令行運行模式，你們常常會使用它，可是可能並無注意到（例如：咱們在linux下常用 "php -m"查找PHP安裝了那些擴展就是PHP命令行運行模式；有興趣的同窗能夠輸入php -h去深刻研究該運行模式）
1.讓 PHP 運行指定文件。
php script.php
php -f script.php
以上兩種方法（使用或不使用 -f 參數）都可以運行腳本的script.php。您能夠選擇任何文件來運行，您指定的 PHP 腳本並不是必需要以 .php 爲擴展名，它們能夠有任意的文件名和擴展名。
2.在命令行直接運行 PHP 代碼。
php -r "print_r(get_defined_constants());"
在使用這種方法時，請您注意外殼變量的替代及引號的使用。
注: 請仔細閱讀以上範例，在運行代碼時沒有開始和結束的標記符！加上 -r 參數後，這些標記符是不須要的，加上它們會致使語法錯誤。
3.經過標準輸入（stdin）提供須要運行的 PHP 代碼。
以上用法給咱們提供了很是強大的功能，使得咱們能夠以下範例所示，動態地生成 PHP 代碼並經過命令行運行這些代碼：
$ some_application | some_filter | php | sort -u >final_output.txt
4. 模塊模式
模塊模式是以mod_php5模塊的形式集成，此時mod_php5模塊的做用是接收Apache傳遞過來的PHP文件請求，並處理這些請求，而後將處理後的結果返回給Apache。若是咱們在Apache啓動前在其配置文件中配置好了PHP模塊（mod_php5）， PHP模塊經過註冊apache2的ap_hook_post_config掛鉤，在Apache啓動的時候啓動此模塊以接受PHP文件的請求。

除了這種啓動時的加載方式，Apache的模塊能夠在運行的時候動態裝載，這意味着對服務器能夠進行功能擴展而不須要從新對源代碼進行編譯，甚至根本不須要中止服務器。咱們所須要作的僅僅是給服務器發送信號HUP或者AP_SIG_GRACEFUL通知服務器從新載入模塊。可是在動態加載以前，咱們須要將模塊編譯成爲動態連接庫。此時的動態加載就是加載動態連接庫。 Apache中對動態連接庫的處理是經過模塊mod_so來完成的，所以mod_so模塊不能被動態加載，它只能被靜態編譯進Apache的核心。這意味着它是隨着Apache一塊兒啓動的。
Apache是如何加載模塊的呢？咱們之前面提到的mod_php5模塊爲例。首先咱們須要在Apache的配置文件httpd.conf中添加一行：
該運行模式是咱們之前在windows環境下使用apache服務器常用的，而在模塊化(DLL)中，PHP是與Web服務器一塊兒啓動並運行的。（是apache在CGI的基礎上進行的一種擴展，加快PHP的運行效率）

複製代碼代碼以下:

LoadModule php5_module modules/mod_php5.so  

這裏咱們使用了LoadModule命令，該命令的第一個參數是模塊的名稱，名稱能夠在模塊實現的源碼中找到。第二個選項是該模塊所處的路徑。若是須要在服務器運行時加載模塊，能夠經過發送信號HUP或者AP_SIG_GRACEFUL給服務器，一旦接受到該信號，Apache將從新裝載模塊，而不須要從新啓動服務器。

5.php在Nginx中運行模式（Nginx+ PHP-FPM）
使用FastCGI方式如今常見的有兩種stack：ligthttpd+spawn-fcgi;另一種是nginx+PHP-FPM(也能夠用spawn-fcgi)。
A、如上面所說該兩種結構都採用FastCGI對PHP支持，所以HTTPServer徹底解放出來，能夠更好地進行響應和併發處理。所以lighttpd和nginx都有small, but powerful和efficient的美譽。
B、該二者還能夠分出一個好壞來，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組合了。

C、因爲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
6.總結
目前在
HTTPServer這塊基本能夠看到有三種stack比較流行：
（1）Apache+mod_php5
（2）lighttp+spawn-fcgi
（3）nginx+PHP-FPM
三者後二者性能可能稍優，可是Apache因爲有豐富的模塊和功能，目前來講仍舊是老大。有人測試nginx+PHP-FPM在高併發狀況下可能會達到Apache+mod_php5的5~10倍，如今nginx+PHP-FPM使用的人愈來愈多。

 

---

---

 當咱們在談到cgi的時候，咱們在討論什麼

　　

　　最先的Web服務器簡單地響應瀏覽器發來的HTTP請求，並將存儲在服務器上的HTML文件返回給瀏覽器，也就是靜態html。事物老是不斷髮展，網站也愈來愈複雜，因此出現動態技術。可是服務器並不能直接運行 php，asp這樣的文件，本身不能作，外包給別人吧，可是要與第三作個約定，我給你什麼，而後你給我什麼，就是握把請求參數發送給你，而後我接收你的處理結果給客戶端。那這個約定就是 common gateway interface，簡稱cgi。這個協議能夠用vb，c，php，python 來實現。cgi只是接口協議，根本不是什麼語言。下面圖能夠看到流程                        

 

  WEB服務器與cgi程序交互

 　　WEB服務器將根據CGI程序的類型決定數據向CGI程序的傳送方式，通常來說是經過標準輸入/輸出流和環境變量來與CGI程序間傳遞數據。 以下圖所示：

　　CGI程序經過標準輸入（STDIN）和標準輸出（STDOUT）來進行輸入輸出。此外CGI程序還經過環境變量來獲得輸入，操做系統提供了許多環境變量，它們定義了程序的執行環境，應用程序能夠存取它們。Web服務器和CGI接口又另外設置了一些環境變量，用來向CGI程序傳遞一些重要的參數。CGI的GET方法還經過環境變量QUERY-STRING向CGI程序傳遞Form中的數據。 下面是一些經常使用的CGI環境變量：

變量名	描述
CONTENT_TYPE	這個環境變量的值指示所傳遞來的信息的MIME類型。目前，環境變量CONTENT_TYPE通常都是：application/x-www-form-urlencoded,他表示數據來自於HTML表單。
CONTENT_LENGTH	若是服務器與CGI程序信息的傳遞方式是POST，這個環境變量即便從標準輸入STDIN中能夠讀到的有效數據的字節數。這個環境變量在讀取所輸入的數據時必須使用。
HTTP_COOKIE	客戶機內的 COOKIE 內容。
HTTP_USER_AGENT	提供包含了版本數或其餘專有數據的客戶瀏覽器信息。
PATH_INFO	這個環境變量的值表示緊接在CGI程序名以後的其餘路徑信息。它經常做爲CGI程序的參數出現。
QUERY_STRING	若是服務器與CGI程序信息的傳遞方式是GET，這個環境變量的值即便所傳遞的信息。這個信息經跟在CGI程序名的後面，二者中間用一個問號'?'分隔。
REMOTE_ADDR	這個環境變量的值是發送請求的客戶機的IP地址，例如上面的192.168.1.67。這個值老是存在的。並且它是Web客戶機須要提供給Web服務器的惟一標識，能夠在CGI程序中用它來區分不一樣的Web客戶機。
REMOTE_HOST	這個環境變量的值包含發送CGI請求的客戶機的主機名。若是不支持你想查詢，則無需定義此環境變量。
REQUEST_METHOD	提供腳本被調用的方法。對於使用 HTTP/1.0 協議的腳本，僅 GET 和 POST 有意義。
SCRIPT_FILENAME	CGI腳本的完整路徑
SCRIPT_NAME	CGI腳本的的名稱
SERVER_NAME	這是你的 WEB 服務器的主機名、別名或IP地址。
SERVER_SOFTWARE	這個環境變量的值包含了調用CGI程序的HTTP服務器的名稱和版本號。例如，上面的值爲Apache/2.2.14(Unix)

 

  一個例子

　　說了這麼多，你也許感受煩了，寫個小程序可能會更好的理解。 lighttpd + CGI，用c語言寫cgi程序 。

      lighttpd 配置 cgi， 打開cgi.conf， cgi.assign = (".cgi" => "") 設置 cgi 模塊的擴展名和解釋器。就本語句而言，表示cgi模塊的擴展名是「.cgi」且該 cgi 模塊不須要特別的解釋器來執行。由於用c來寫的是可執行文件。

     下面是 test.c 代碼：

#include "stdio.h"
#include "stdlib.h"
#include <string.h>

int main()
{
     char *data;
     data = getenv("QUERY_STRING");
     puts(data);
     printf("Hello cgi!");

     return 0;
}

 生成可執行文件放到你的服務器配置程序的目錄下

gcc test.c -o test.cgi

 訪問：http://localhost/test.cgi?a=b&c=d 結果爲： 

a=b&c=d
Hello cgi!

　　經過環境變量"QUERY_STRING" 獲取get 方式提交的內容，若是想獲取post 提交的內容能夠經過getenv("CONTENT-LENGTH")，Web服務器在調用使用POST方法的CGI程序時設置此環境變量，它的文本值表示Web服務器傳送給CGI程序的輸入中的字符數目。上面例子展現了cgi 程序與web服務器的交互。

  cgi 與 fastcgi

　　CGI工做原理：每當客戶請求CGI的時候，WEB服務器就請求操做系統生成一個新的CGI解釋器進程(如php-cgi.exe)，CGI 的一個進程則處理完一個請求後退出，下一個請求來時再建立新進程。固然，這樣在訪問量不多沒有併發的狀況也行。但是當訪問量增大，併發存在，這種方式就不適合了。因而就有了fastcgi。

　　FastCGI像是一個常駐(long-live)型的CGI，它能夠一直執行着，只要激活後，不會每次都要花費時間去fork一次（這是CGI最爲人詬病的fork-and-execute 模式）。

　　通常狀況下，FastCGI的整個工做流程是這樣的：

　　1.Web Server啓動時載入FastCGI進程管理器（IIS ISAPI或Apache Module)

        2.FastCGI進程管理器自身初始化，啓動多個CGI解釋器進程(可見多個php-cgi)並等待來自Web Server的鏈接。

        3.當客戶端請求到達Web Server時，FastCGI進程管理器選擇並鏈接到一個CGI解釋器。 Web server將CGI環境變量和標準輸入發送到FastCGI子進程php-cgi。

        4.FastCGI子進程完成處理後將標準輸出和錯誤信息從同一鏈接返回Web Server。當FastCGI子進程關閉鏈接時， 請求便告處理完成。FastCGI子進程接着等待並處理來自FastCGI進程管理器(運行在Web Server中)的下一個鏈接。 在CGI模式中，php-cgi在此便退出了。

        PHP-FPM與Spawn-FCGI

　　Spawn-FCGI是一個通用的FastCGI管理服務器，它是lighttpd中的一部份，不少人都用Lighttpd的Spawn-FCGI進行FastCGI模式下的管理工做。 可是有缺點，因而PHP-fpm就是針對於PHP的，Fastcgi的一種實現，他負責管理一個進程池，來處理來自Web服務器的請求。目前，PHP-fpm是內置於PHP的。

  apache 模塊方式

　　記得曾在xp 配置 apache + php ，會在apache 配置下面一段：

LoadModule php5_module C:/php/php5apache2_2.dll

　　當PHP須要在Apache服務器下運行時，通常來講，它能夠模塊的形式集成， 此時模塊的做用是接收Apache傳遞過來的PHP文件請求，並處理這些請求， 而後將處理後的結果返回給Apache。若是咱們在Apache啓動前在其配置文件中配置好了PHP模塊， PHP模塊經過註冊apache2的ap_hook_post_config掛鉤，在Apache啓動的時候啓動此模塊以接受PHP文件的請求。

     Apache 的Hook機制是指：Apache 容許模塊(包括內部模塊和外部模塊，例如mod_php5.so，mod_perl.so等)將自定義的函數注入到請求處理循環中。 換句話說，模塊能夠在Apache的任何一個處理階段中掛接(Hook)上本身的處理函數，從而參與Apache的請求處理過程。 mod_php5.so/ php5apache2.dll就是將所包含的自定義函數，經過Hook機制注入到Apache中，在Apache處理流程的各個階段負責處理php請求。

有人測試nginx+PHP-FPM在高併發狀況下可能會達到Apache+mod_php5的5~10倍，如今nginx+PHP-FPM使用的人