標籤：header 程式 進程管理 傳遞資料 lighttpd 錯誤資訊 nginx ges 發送
本篇文章是對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 的可執行檔安裝到 網頁伺服器的 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=dHello 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使用的人
PHP運行模式的深入理解
