CGI
CGI: Common Gateway Interface. HTTP 服務器與你的或其它機器上的程序進行“交談”的一種協議，其程序須運行在網絡服務器上。
web server（比如說 Nginx）只是內容的分發者。
如果請求 /index.html，那麼 web server 會去文件系統中找到這個文件，發送給瀏覽器，這裏分發的是靜態數據。
如果現在請求的是 /index.php，根據配置文件，nginx 知道這個不是靜態文件，需要去找 PHP 解析器來處理，那麼他會把這個請求簡單處理後交給 PHP 解析器。Nginx 會傳哪些數據給 PHP 解析器呢？url、查詢字符串、POST 數據、HTTP header 等等，CGI 就是規定要傳哪些數據、以什麼樣的格式傳遞給後方處理這個請求的協議。
FastCGI
FastCGI 是 CGI 的升級版，一種語言無關的協議，用來溝通程序（如 PHP Python Java）和 Web 服務器（Apache2 Nginx），理論上任何語言編寫的程序都可以通過 FastCGI 來提供 Web 服務。
FastCGI 的特點是會在一個進程中依次完成多個請求，以達到提高效率的目的，多數 FastCGI 實現都會維護一個進程池。
那麼 CGI 程序的性能問題在哪呢？“PHP 解析器會解析 php.ini 文件，初始化執行環境”，就是這裏了。標準的 CGI 對每個請求都會執行這些步驟，所以處理每個請求的時間會比較長。
那麼 FastCGI 是怎麼做的呢？首先，FastCGI 會先啓一個 master，解析配置文件，初始化執行環境，然後再啓動多個 worker。當請求過來時，master 會傳遞給一個 worker，然後立即可以接受下一個請求。這樣就避免了重複的勞動，效率自然是高。而且當 worker 不夠用時，master 可以根據配置預先啓動幾個 worker 等着；當然空閒 worker 太多時，也會停掉一些，這樣就提高了性能，也節約了資源。這就是 FastCGI 對進程的管理。
PHP-CGI
PHP-CGI 只是個 CGI 程序，他自己本身只能解析請求，返回結果，不會進程管理。
PHP-CGI 的不足：PHP-CGI 變更 php.ini 配置後需重啓 PHP-CGI 才能讓新的 php-ini 生效，不可以平滑重啓。直接殺死 PHP-CGI 進程，PHP 就不能運行了。（PHP-FPM 和 Spawn-FCGI 就沒有這個問題，守護進程會平滑從新生成新的子進程。）
PHP-FPM
PHP 的解釋器是 php-cgi，它只是個 CGI 程序，只能解析請求，返回結果，不會進程管理。所以就出現了一些能夠調度 PHP-CGI 進程的程序。
PHP-FPM 是 PHP 針對 FastCGI 協議的具體實現，也是 PHP 在多種服務器端應用編程端口（SAPI：cgi、fast-cgi、cli、isapi、apache）裏使用最普遍、性能最佳的一款進程管理器。
PHP 5.3.3 已經集成 PHP-FPM 了，不再是第三方的包了。PHP-FPM 提供了更好的 PHP 進程管理方式，可以有效控制內存和進程、可以平滑重載 PHP 配置，被 PHP 官方收錄了。
小故事
你（PHP）去和愛斯基摩人（web 服務器，如 Apache、Nginx）談生意。你說中文（PHP 代碼），他說愛斯基摩語（C 代碼），互相聽不懂，怎麼辦？那就都把各自說的話轉換成英語（FastCGI 協議）吧。
怎麼轉換呢？你就要使用一個翻譯機（PHP-FPM）（當然對方也有一個翻譯機，那個是他自帶的）
我們這個翻譯機是最新型的，老式的那個（PHP-CGI）被淘汰了。
FastCGI 是 Nginx 和 PHP 之間的一個通信接口，該接口實際處理過程通過啓動 PHP-FPM 進程來解析 PHP 腳本，即 PHP-FPM 相當於一個動態應用服務器，從而實現 Nginx 動態解析 PHP。
因此，如果 Nginx 服務器需要支持 PHP 解析，需要在nginx.conf 中增加 PHP 的配置：將 PHP 腳本轉發到 FastCGI 進程監聽的 IP 地址和端口（php-fpm.conf 中指定）。
同時，PHP 安裝的時候，需要開啓支持 FastCGI 選項，並且編譯安裝 PHP-FPM 補丁/擴展，同時，需要啓動 PHP-FPM 進程，纔可以解析 Nginx 通過 FastCGI 轉發過來的 PHP 腳本