**1、CGI**：指的是Web服務器與web應用程序之間的一種數據交換協議。 **2、FastCGI**：類似于CGI，Fast-CGI也是一種通信協議，但是它在CGI的基礎上， 在效率上做了一些優化。 **3、PHP-CGI**：PHP-CGI是PHP對Web服務器提供的CGI協議的接口程序，即實現了CGI協議的php解釋器程序。它能解析PHP，也能通過CGI與web服務器通信。 **4、PHP-FPM**：是PHP對Web服務器提供的FastCGI協議的接口程序，即在實現解釋PHP腳本和與web服務器通訊的基礎上，額外還提供了相對 進程調度、任務管理功能。 ### **PHP-FPM運行模式** >我們先聊聊傳統 PHP-FPM 架構的運作模式，PHP-FPM 是一個多進程的 FastCGI 管理程序，是絕大多數 PHP 應用所使用的運行模式。 > 假設我們使用 Nginx 提供 HTTP 服務（Apache 同理），所有客戶端發起的請求最先抵達的都是 Nginx，然后 Nginx 通過 FastCGI 協議將請求轉發給 PHP-FPM 處理。 > PHP-FPM 的 Master進程 會為每個請求分配一個 Worker進程 來處理，這個處理指的就是，等待 PHP 腳本的解析，等待業務處理的結果返回，完成后回收子進程，這整個的過程是阻塞等待的，也就意味著 PHP-FPM 的進程數有多少能處理的請求也就是多少。 > 假設 PHP-FPM 有 200 個 Worker進程，一個請求將耗費 1 秒的時間，那么簡單的來說整個服務器理論上最多可以處理的請求也就是 200 個，QPS 即為 200/s。 > 在高并發的場景下，這樣的性能往往是不夠的，盡管可以利用 Nginx 作為負載均衡配合多臺 PHP-FPM 服務器來提供服務，但由于 PHP-FPM 的阻塞等待的工作模型，一個請求會占用至少一個 MySQL 連接，多節點高并發下會產生大量的 MySQL 連接，而 MySQL 的最大連接數默認值為 100，盡管可以修改，但顯而易見該模式沒法很好的應對高并發的場景。 **CGI即通用網關接口，是 Web 服務器調用外部程序時所使用的一種服務端應用的規范。** >早期的 Web 通信請求的都是靜態數據，比如圖片、Html文檔等，隨著Web的發展，靜態網站已經不能滿足人們的需要，所以引入 CGI 以便客戶端請求能夠觸發 Web 服務器運行另一個外部程序，客戶端所輸入的數據也會傳給這個外部程序，該程序運行結束后會將生成的 HTML 和其他數據通過 Web 服務器再返回給客戶端，利用 CGI 可以針對用戶請求動態返回給客戶端各種各樣動態變化的信息。 **FastCGI是 CGI 的升級版本，** >為了提升 CGI 的性能而生，CGI 針對每個 HTTP 請求都會?`fork`?一個新進程來進行處理（解析配置文件、初始化執行環境、處理請求），然后把這個進程處理完的結果通過 Web 服務器轉發給用戶，剛剛?`fork`?的新進程也隨之退出，如果下次用戶再請求動態資源，那么 Web 服務器又再次?`fork`?一個新進程，如此周而復始循環往復。而 FastCGI 則會先?`fork`?一個?`master`?進程，解析配置文件，初始化執行環境，然后再?`fork`?多個?`worker`?進程（與 Nginx 有點像），當 HTTP 請求過來時，`master`?進程將其會傳遞給一個?`worker`?進程，然后立即可以接受下一個請求，這樣就避免了重復的初始化操作，效率自然也就提高了。而且當?`worker`?進程不夠用時，`master`?進程還可以根據配置預先啟動幾個?`worker`?進程等著；當空閑?`worker`?進程太多時，也會關掉一些，這樣不僅提高了性能，還節約了系統資源。 **PHP-FPM** >這樣一來，PHP-FPM 就好理解了，FastCGI 只是一個協議規范，需要每個語言具體去實現，PHP-FPM 就是 PHP 版本的 FastCGI 協議實現，有了它，就是實現 PHP 腳本與 Web 服務器（通常是 Nginx）之間的通信，同時它也是一個 PHP SAPI，從而構建起 PHP 解釋器與 Web 服務器之間的橋梁。 PHP-FPM 負責管理一個進程池來處理來自 Web 服務器的 HTTP 動態請求，在 PHP-FPM 中，`master`?進程負責與 Web 服務器進行通信，接收 HTTP 請求，再將請求轉發給?`worker`?進程進行處理，`worker`?進程主要負責動態執行 PHP 代碼，處理完成后，將處理結果返回給 Web 服務器，再由 Web 服務器將結果發送給客戶端。這就是 PHP-FPM 的基本工作原理