fastcgi與cgi有什麼不一樣

前言

如今的CGI基本沒人使用，不安全以及性能極其低下，愈來愈多的使用web內置擴展、fastCGI。例如微軟iis的ISAPI，apache的php模塊，nginx的php-cgi。CGI、內置模塊、fastcgi這三種性能最好的要屬於fast_cgi速度最快，可是須要額外的進程。解析來看看CGI和FASTCGI有什麼不一樣.

CGI方式介紹：

cgi在2000年或更早的時候用得比較多，之前web服務器通常只處理靜態的請求，若是碰到一個動態請求怎麼辦呢？web服務器會根據此次請求的內容，而後會fork一個新進程來運行外部c程序（或perl腳本...）， 這個進程會把處理完的數據返回給web服務器，最後web服務器把內容發送給用戶，剛纔fork的進程也隨之退出。 若是下次用戶還請求改動態腳本，那麼web服務器又再次fork一個新進程，周而復始的進行。

web內置模塊介紹：

後來出現了一種更高級的方式是， web服務器能夠內置perl解釋器或php解釋器。 也就是說這些解釋器作成模塊的方式，web服務器會在啓動的時候就啓動這些解釋器。 當有新的動態請求進來時，web服務器就是本身解析這些perl或php腳本，免得從新fork一個進程，效率提升了。

fastcgi方式介紹：

fastcgi的方式是，web服務器收到一個請求時，他不會從新fork一個進程（由於這個進程在web服務器啓動時就開啓了，並且不會退出），web服務器直接把內容傳遞給這個進程（進程間通訊，但fastcgi使用了別的方式，tcp方式通訊），這個進程收到請求後進行處理，把結果返回給web服務器，最後本身接着等待下一個請求的到來，而不是退出.

fastcgi跟cgi的區別表格：

舉個例子: 服務端如今有個10萬個字單詞， 客戶每次會發來一個字符串，問以這個字符串爲前綴的單詞有多少個。 那麼能夠寫一個程序，這個程序會建一棵trie樹，而後每次用戶請求過來時能夠直接到這個trie去查找。 可是若是以cgi的方式的話，此次請求結束後這課trie也就沒了，等下次再啓動該進程時，又要新建一棵trie樹，這樣的效率就過低下了。 而用fastcgi的方式的話，這課trie樹在進程啓動時創建，之後就能夠直接在trie樹上查詢指定的前綴了。

引用評論（ https://segmentfault.com/q/10...）

首先，CGI是幹嗎的？CGI是爲了保證web server傳遞過來的數據是標準格式的，方便CGI程序的編寫者。

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是個協議，跟進程什麼的不要緊。那fastcgi又是什麼呢？Fastcgi是用來提升CGI程序性能的。

提升性能，那麼CGI程序的性能問題在哪呢？"PHP解析器會解析php.ini文件，初始化執行環境"，就是這裏了。標準的CGI對每一個請求都會執行這些步驟（不閒累啊！啓動進程很累的說！），因此處理每一個時間的時間會比較長。這明顯不合理嘛！那麼Fastcgi是怎麼作的呢？首先，Fastcgi會先啓一個master，解析配置文件，初始化執行環境，而後再啓動多個worker。當請求過來時，master會傳遞給一個worker，而後當即能夠接受下一個請求。這樣就避免了重複的勞動，效率天然是高。並且當worker不夠用時，master能夠根據配置預先啓動幾個worker等着；固然空閒worker太多時，也會停掉一些，這樣就提升了性能，也節約了資源。這就是fastcgi的對進程的管理。

那PHP-FPM又是什麼呢？是一個實現了Fastcgi的程序，被PHP官方收了。

你們都知道，PHP的解釋器是php-cgi。php-cgi只是個CGI程序，他本身自己只能解析請求，返回結果，不會進程管理（皇上，臣妾真的作不到啊！）因此就出現了一些可以調度php-cgi進程的程序，好比說由lighthttpd分離出來的spawn-fcgi。好了PHP-FPM也是這麼個東東，在長時間的發展後，逐漸獲得了你們的承認（要知道，前幾年你們但是抱怨PHP-FPM穩定性太差的），也愈來愈流行。

好了，最後來回來你的問題。
網上有的說，fastcgi是一個協議，php-fpm實現了這個協議

對。

有的說，php-fpm是fastcgi進程的管理器，用來管理fastcgi進程的

對。php-fpm的管理對象是php-cgi。但不能說php-fpm是fastcgi進程的管理器，由於前面說了fastcgi是個協議，彷佛沒有這麼個進程存在，就算存在php-fpm也管理不了他（至少目前是）。
有的說，php-fpm是php內核的一個補丁

之前是對的。由於最開始的時候php-fpm沒有包含在PHP內核裏面，要使用這個功能，須要找到與源碼版本相同的php-fpm對內核打補丁，而後再編譯。後來PHP內核集成了PHP-FPM以後就方便多了，使用--enalbe-fpm這個編譯參數便可。

有的說，修改了php.ini配置文件後，沒辦法平滑重啓，因此就誕生了php-fpm

是的，修改php.ini以後，php-cgi進程的確是沒辦法平滑重啓的。php-fpm對此的處理機制是新的worker用新的配置，已經存在的worker處理完手上的活就能夠歇着了，經過這種機制來平滑過分。

還有的說PHP-CGI是PHP自帶的FastCGI管理器，那這樣的話幹嘛又弄個php-fpm出

不對。php-cgi只是解釋PHP腳本的程序而已。