1、CLI:就是命令行，例如可以在控制台或者是shell中鍵入命令:
php -f index.php
然後獲取輸出
2、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 格式）。
3、FastCGI:CGI有很多缺點，每接收一個請求就要fork一個進程處理，只能接收一個請求作出一個響應。請求結束後該進程就會結束。而FastCGI會事先啟動起來，作為一個cgi的管理服務器存在，預先啟動一系列的子進程來等待處理，然後等待web服務器發過來的請求，一旦接受到請求就交由子進程處理，這樣由於不需要在接受到請求後啟動cgi，會快很多。FastCGI使用進程/線程池來處理一連串的請求。這些進程/線程由FastCGI服務器管理，而不是Web服務器。 當進來一個請求時，Web服務器把環境變量和這個頁面請求通過一個Socket長連接傳遞給FastCGI進程。FastCGI像是一個常駐型的CGI，它可以一直執行，在請求到達時不會花費時間去fork一個進程來處理(這是CGI對位人诟病的fork-and-execute模式)。正是因為它只是一個通信協議，它還支持分布式的運算，即FastCGI程序可以在網站服務器以外的主機上執行並且接受來自其他網站服務器的請求
FastCGI整個流程:
Web server啟動時載入FastCGI進程管理器
FastCGI自身初始化，啟動多個CGI解釋器進程(可見多個php-cgi)並等待來自Web server的請求
當請求Web server時，Web server通過socket請求FastCGI進程管理器，FastCGI進程管理器選擇並連接到一個CGI解釋器，Web server將CGI環境變量和標准輸入發送到FastCGI子進程php-cgi
FastCGI子進程處理請求完成後將標准輸出和錯誤從同一連接返回給Web server，當FastCGI子進程結束後請求便結束。FastCGI子進程接著等待處理來自FastCGI進程管理器的下一個連接，在CGI模式中，php-cgi在此便退出了。
php-fpm:PHP的FastCGI進程管理器
4、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文件的功能。
