CGI fastCgi php-fpm PHP-CGI 辨析

CGI fastCgi php-fpm PHP-CGI 辨析

• LNMP環境中的nginx是不支持php的，須要經過fastcgi插件來處理有關php的請求。而php須要php-fpm這個組件提供該功能。在php5.3.3之前的版本php-fpm是以一個補丁包的形式存在的，而php5.3.3之後只需在編譯安裝時使用–enable-fpm加載該模塊便可，無需另行安裝。

• web server（好比說nginx）只是內容的分發者。好比，若是請求/index.html，那麼web server會去文件系統中找到這個文件，發送給瀏覽器，這裏分發的是靜態數據。好了，若是如今請求的是/index.php，根據配置文件，nginx知道這個不是靜態文件，須要去找PHP解析器來處理，那麼他會把這個請求簡單處理後交給PHP解析器。Nginx會傳哪些數據給PHP解析器呢？url要有吧，查詢字符串也得有吧，POST數據也要有，HTTP header不能少吧，好的，CGI就是規定要傳哪些數據、以什麼樣的格式傳遞給後方處理這個請求的協議。仔細想一想，你在PHP代碼中使用的用戶從哪裏來的。

• 當web server收到/index.php這個請求後，會啓動對應的CGI程序，這裏就是PHP的解析器。接下來PHP解析器會解析php.ini文件，初始化執行環境，而後處理請求，再以規定CGI規定的格式返回處理後的結果，退出進程。web server再把結果返回給瀏覽器。
• 提升性能，那麼CGI程序的性能問題在哪呢？"PHP解析器會解析php.ini文件，初始化執行環境"，就是這裏了。標準的CGI對每一個請求都會執行這些步驟（不閒累啊！啓動進程很累的說！），因此處理每一個時間的時間會比較長。這明顯不合理嘛！那麼Fastcgi是怎麼作的呢？首先，Fastcgi會先啓一個master，解析配置文件，初始化執行環境，而後再啓動多個worker。當請求過來時，master會傳遞給一個worker，而後當即能夠接受下一個請求。這樣就避免了重複的勞動，效率天然是高。並且當worker不夠用時，master能夠根據配置預先啓動幾個worker等着；固然空閒worker太多時，也會停掉一些，這樣就提升了性能，也節約了資源。這就是fastcgi的對進程的管理。
• 你們都知道，PHP的解釋器是php-cgi。php-cgi只是個CGI程序，他本身自己只能解析請求，返回結果，不會進程管理（皇上，臣妾真的作不到啊！）因此就出現了一些可以調度php-cgi進程的程序，好比說由lighthttpd分離出來的spawn-fcgi。好了PHP-FPM也是這麼個東東，在長時間的發展後，逐漸獲得了你們的承認（要知道，前幾年你們但是抱怨PHP-FPM穩定性太差的），也愈來愈流行。
• 修改php.ini以後，php-cgi進程的確是沒辦法平滑重啓的。php-fpm對此的處理機制是新的worker用新的配置，已經存在的worker處理完手上的活就能夠歇着了，經過這種機制來平滑過分。
• Fastcgi是CGI的升級版，一種語言無關的協議，用來溝通程序(如PHP, Python, Java)和Web服務器(Apache2, Nginx), 理論上任何語言編寫的程序均可以經過Fastcgi來提供Web服務。
  Fastcgi的特色是會在一個進程中依次完成多個請求，以達到提升效率的目的，大多數Fastcgi實現都會維護一個進程池。
  而PHP-fpm就是針對於PHP的，Fastcgi的一種實現，他負責管理一個進程池，來處理來自Web服務器的請求。目前，PHP-fpm是內置於PHP的。
  可是PHP-fpm僅僅是個「PHP Fastcgi 進程管理器」, 它仍會調用PHP解釋器自己來處理請求，PHP解釋器(在Windows下)就是php-cgi.exe.

• fastcgi 是 app server 和web server 之間的通訊協議。 正常架構 app server 是master，web server是client
  php-fpm 帶兩個功能：1.實現了一個支持fastcgi協議的server程序 2. 進程管理器
  有了php-fpm，就能夠把php腳本變成 多進程模式，採用fastcgi協議的app server，和web server進行通訊

參考：https://segmentfault.com/q/1010000000256516