php的幾種運行模式CLI、CGI、FastCGI、mod_php

一、CLI:就是命令行，例如能夠在控制檯或者是shell中鍵入命令:

1	php -f index.php

而後獲取輸出

 

二、CGI:如下是不一樣的說法與理解

    公共網關接口」(Common Gateway Interface)，HTTP服務器 與你的或其它機器上的程序 進行 「交談」的一種工具 ，其程序 須運行在網絡 服務器 上。在服務器 環境中，爲「程序 」提供標準 的接口，經過這個接口，「程序 」能夠對服務器 與客戶端 交換的信息 作一些事情 。「程序 」的語 言並無要求。程序 對接口進行 操做。服務器 要支持 CGI就要提供CGI中要求的環境變量 ，或者還有別的。

    HTTP Server和一個獨立的進程之間的協議，把HTTP Request的Header設置成進程的環境變量，HTTP Request的正文設置成進程的標準輸入，而進程的標準輸出就是HTTP Response包括Header和正文。

    這個 Web 服務器使用了 UNIX shell 環境變量 來保存從 Web 服務器傳遞出去的參數，而後生成一個運行 CGI 的獨立進程。

    不一樣類型語言寫的程序只要符合cgi標準，就能做爲一個cgi程序與web服務器交互

    以CGI方式運行時,web server將用戶請求以消息的方式轉交給PHP獨立進程,PHP與web服務之間無從屬關係。

 

    我的理解:CGI規定了php與web server交流的規則，至關於執行了response = exec("php -f index.php -url=xxx -cookie=xxx -xxx=xxx")。

 

    關於CGI與CLI區別能夠查看官方文檔說的挺不錯的:http://php.net/manual/zh/features.commandline.php

    文中闡述了CGI與CLI的顯著區別:

        如下爲 CLI SAPI 和其它 CLI SAPI 模塊相比的顯著區別：

• 與 CGI SAPI 不一樣，其輸出沒有任何頭信息。

  儘管 CGI SAPI 提供了取消 HTTP 頭信息的方法，但在 CLI SAPI 中並不存在相似的方法以開啓 HTTP 頭信息的輸出。

  CLI 默認以安靜模式開始，但爲了保證兼容性，-q 和 --no-header 參數爲了向後兼容仍然保留，使得可使用舊的 CGI 腳本。

  在運行時，不會把工做目錄改成腳本的當前目錄（可使用 -C 和 --no-chdir 參數來兼容 CGI 模式）。

  出錯時輸出純文本的錯誤信息（非 HTML 格式）。

 

三、FastCGI:CGI有不少缺點，每接收一個請求就要fork一個進程處理，只能接收一個請求做出一個響應。請求結束後該進程就會結束。而FastCGI會事先啓動起來，做爲一個cgi的管理服務器存在，預先啓動一系列的子進程來等待處理，而後等待web服務器發過來的請求，一旦接受到請求就交由子進程處理，這樣因爲不須要在接受到請求後啓動cgi，會快不少。FastCGI使用進程/線程池來處理一連串的請求。這些進程/線程由FastCGI服務器管理，而不是Web服務器。 當進來一個請求時，Web服務器把環境變量和這個頁面請求經過一個Socket長鏈接傳遞給FastCGI進程。FastCGI像是一個常駐型的CGI，它能夠一直執行，在請求到達時不會花費時間去fork一個進程來處理(這是CGI對位人詬病的fork-and-execute模式)。正是由於它只是一個通訊協議，它還支持分佈式的運算，即FastCGI程序能夠在網站服務器之外的主機上執行而且接受來自其餘網站服務器的請求

    FastCGI整個流程:

1. Web server啓動時載入FastCGI進程管理器

2. FastCGI自身初始化，啓動多個CGI解釋器進程(可見多個php-cgi)並等待來自Web server的請求

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

4. FastCGI子進程處理請求完成後將標準輸出和錯誤從同一鏈接返回給Web server，當FastCGI子進程結束後請求便結束。FastCGI子進程接着等待處理來自FastCGI進程管理器的下一個鏈接，在CGI模式中，php-cgi在此便退出了。

 

    php-fpm:PHP的FastCGI進程管理器

 

四、mod_php：即apache的php模塊，將PHP作爲web-server的子進程控制,二者之間有從屬關係.最明顯的例子就是在CGI模式下,若是修改了PHP.INI的配置文件,不用重啓web服務即可生效,而模塊模式下則須要重啓web服務。以mod_php模式運行PHP，意味着php是做爲apache的一個模塊來啓動的，所以只有在apache啓動的時候會讀取php.ini配置文件並加載擴展模塊，在apache運行期間是不會再去讀取和加載擴展模塊的

Apache的工做模式 prefork的工做原理

一個單獨的控制進程(父進程)負責產生子進程，這些子進程用於監聽請求並做出應答。Apache老是試圖保持一些備用的 (spare)或是空閒的子進程用於迎接即將到來的請求。這樣客戶端就無需在獲得服務前等候子進程的產生。在Unix系統中，父進程一般以root身份運行以便邦定80端口，而 Apache產生的子進程一般以一個低特權的用戶運行。User和Group指令用於配置子進程的低特權用戶。運行子進程的用戶必需要對他所服務的內容有讀取的權限，可是對服務內容以外的其餘資源必須擁有儘量少的權限。

worker的工做原理

每一個進程可以擁有的線程數量是固定的。服務器會根據負載狀況增長或減小進程數量。一個單獨的控制進程(父進程)負責子進程的創建。每一個子進程可以創建ThreadsPerChild數量的服務線程和一個監聽線程，該監聽線程監聽接入請求並將其傳遞給服務線程處理和應答。Apache老是試圖維持一個備用(spare)或是空閒的服務線程池。這樣，客戶端無須等待新線程或新進程的創建便可獲得處理。在Unix中，爲了可以綁定80端口，父進程通常都是以root身份啓動，隨後，Apache以較低權限的用戶創建子進程和線程。User和Group指令用於配置Apache子進程的權限。雖然子進程必須對其提供的內容擁有讀權限，但應該儘量給予他較少的特權。另外，除非使用了suexec ，不然，這些指令配置的權限將被CGI腳本所繼承

 

    我的理解:這種模式把php嵌入到apache中，至關於給apache加入瞭解析php文件的功能。

 

from:https://www.cnblogs.com/orlion/p/5282753.html  待整理