CGI、FastCGI和php-fpm的概念和區別

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

FASTCGI是和HTTP協議相似的概念。無非就是規定了在同一個TCP鏈接裏怎麼同時傳多個HTTP鏈接。這實際上致使了個問題，有個HTTP鏈接傳個大文件不願讓出FASTCGI鏈接，在同一個FASTCGI鏈接裏的其餘HTTP鏈接就傻了。因此Lighttpd? 引入了 X-SENDFILE 。

php-fpm就至關因而Apache+mod_php。無非php-fpm自帶了FASTCGI Server，而Apache是HTTP Server。

那個WSGI和這個問題沒啥關係吧。WSGI這個只是Python內部的一個接口。不管你前面是FASTCGI，HTTP，SCGI，uWSGI等協議，你的FASTCGI/HTTP/SCGI/uWSGI Server都以相同的參數格式去調用一個函數，這樣你用Python寫的Web應用並不須要修改代碼，就能夠運行在不一樣的Server後面了。無非CGI協議是進程間的，而WSGI是進程內的。

 

1. 通常web服務器接受到瀏覽器的請求時，若是是靜態資源的話就直接將其返回給瀏覽器，若是是動態資源的話那就沒有現成的資源返回了，那這個時候cgi就出場了

2. cgi能夠理解爲一種協議or一類處理程序，就是動態去生成文件，從程序上來理解就是web服務器exec這樣一個進程，而後交給他一些輸入參數，他就慢慢的處理完後把結果返回給web服務器，那從協議層面來講cgi協議就是規範了web服務器和cgi程序的一些輸入輸出參數的含義

3.因此能夠有不少不一樣的cgi程序，別能夠執行php腳本的or能夠執行python腳本的，只要符合這類規範就能供web服務器調用，固然它的缺點就是每次都須要去啓動這個cgi程序，這會使得處理速度很慢

4.針對這種缺陷加以改進就成了fastcgi，一樣的他也能夠理解爲一種協議or一個程序，它跟cgi的不一樣就是不須要每次去exec，它會事先啓動起來，做爲一個cgi的管理服務器存在，預先啓動一系列的子進程來等待處理，而後等待web服務器發過來的請求，一旦接受到請求就交由子進程處理，這樣因爲不須要在接受到請求後啓動cgi，會快不少。

5.phpfpm是php對fastcgi的一種具體實現，它的啓動後會建立多個cgi子進程，而後主進程負責管理子進程，同時它對外提供一個socket，那web服務器當要轉發一個動態請求時只須要按照fastcgi協議要求的格式將數據發往這個socket的就能夠了，那phpfpm建立的子進程去爭搶這個socket鏈接，誰搶到了誰處理並將結果返回給web服務器，那phpfpm主進程幹什麼了？比方說其中一個子進程異常退出了怎麼辦，那phpfpm會去監控他一旦發現一個cgi子進程就會又啓動一個，還有其餘諸多管理功能

6 phpfpm做爲一個獨立的進程存在 經過socket與nginx創建鏈接，而mod_php 是做爲一個模塊被加載進了apache服務器，同時他們兩做爲cgi調度管理器，他們對其管理的方式也不同

通俗的能夠把服務器看做餐廳，用戶請求看做來用餐的顧客，服務器處理請求看做解決顧客的就餐問題（響應輸出一份飯）。

服務器上靜態資源看做已作好的飯，只要放到餐盒裏就能夠返回給顧客，動態資源須要廚房大廚現成作份再放到餐盒裏返回給顧客。

php_mod這個大廚有個特色，看見有顧客進門就點火，無論顧客要不要現作的，有點浪費資源

php_fpm這個大廚有好多小弟一直點着火（多個處理進程），等有顧客說要現作，大廚就安排小弟作份返回給客戶

cgi也是個大廚，不過他等到顧客要現作，他才點火，作飯，而後熄火。等待下一個要現作的到來

fastcgi呢就是個大廚僱了一幫小弟，專門作須要現場作的飯，大廚只管分派任務，小弟真正操鍋作飯