web server收到用戶請求，並把請求提交給cgi程序，cgi程序根據請求提交的參數作相應處理，然後輸出標準的html語句返回給web server，web server再返回給客戶端，這就是普通cgi的工作原理。
從 上面看，cgi所要實現的不過是動態網頁而已，這種處理方式的特點就是每接到一個請求，web server都要fork出一個單獨的cgi程序的進程來處理，這種方式的好處是把web server和具體的程序處理獨立開來，結構清晰，可控性強，同時缺點就是如果在高訪問需求的情況下，cgi的進程fork就會成爲很大的服務器負擔，想 象一下數百個併發請求導致服務器fork出數百個進程就明白了。這也是爲什麼cgi一直揹負性能低下，高資源消耗的惡名的原因。
相應的有問題就有解決方案，目前流行的方案就是使用模塊設計，基本上目前的web server都有相應的模塊機制來擴充它的
所幸我們還有另外的選擇，這就是fastcgi。 fastcgi是基於cgi架構的擴展，他的核心思想就是在web server和具體cgi程序之間建立一個智能的可持續的中間層，統管cgi程序的運行，這樣web server只需要將請求提交給這個層，這個層再派生出幾個可複用的cgi程序實例，然後再把請求分發給這些實例，這些實例是可控的，可持續，可複用的， 因此一方面避免了進程反覆fork，另一方面又可以通過中間層的控制和探測機制來監視這些實例的運行情況，根據不同的狀況fork或者回收實例，達到靈活 性和穩定性兼得的目的。
本人曾經做過測試，使用cgi方式運行php效率最差，mod_php方式性能非常不錯，幾乎是cgi方 式的50倍，但是無法保證虛擬主機站點的安全性隔離，而fastcgi性能則基本和mod_php相當，這還是在使用了suexec切換虛擬主機站點運行 用戶的情況下的結果。
fastcgi與cgi的區別
先講下cgi：
cgi在2000年或更早的時候用得比較多， 以前web服務器一般只處理靜態的請求，如果碰到一個動態請求怎麼辦呢？web服務器會把根據這次請求的內容，然後會fork一個新進程運行外部c程序 （或perl腳本...）， 這個進程會把處理完的數據返回給web服務器，最後web服務器把內容發送給用戶，剛纔fork的進程也隨之退出。 如果下次用戶還請求改動態腳本，那麼web服務器又再次fork一個新進程，周而復始的進行。
後來出現了一種更高級的方式是， web服務器可以內置perl解釋器或php解釋器。 也就是說這些解釋器做成模塊的方式，web服務器會在啓動的時候就啓動這些解釋器。 當有新的動態請求進來時，web服務器就是自己解析這些perl或php腳本，省得重新fork一個進程，效率提高了。
fastcgi的方式是，web服務器收到一個請求時，他不會重新fork一個進程（因爲這個進程在web服務器啓動時就開啓了，而且不會退 出），web服務器直接把內容傳遞給這個進程（進程間通信，但fastcgi使用了別的方式，tcp方式通信），這個進程收到請求後進行處理，把結果返回 給web服務器，最後自己接着等待下一個請求的到來，而不是退出。
fastcgi跟cgi的區別是：
在web服務器方面 在對數據進行處理的進程方面
cgi fork一個新的進程進行處理 讀取參數，處理數據，然後就結束生命期
fastcgi 用tcp方式跟遠程機子上的進程或本地進程建立連接 要開啓tcp端口，進入循環，等待數據的到來，處理數據
舉個例子: 服務端現在有個10萬個字單詞， 客戶每次會發來一個字符串，問以這個字符串爲前綴的單詞有多少個。 那麼可以寫一個程序，這個程序會建一棵trie樹，然後每次用戶請求過來時可以直接到這個trie去查找。 但是如果以cgi的方式的話，這次請求結束後這課trie也就沒了，等下次再啓動該進程時，又要新建一棵trie樹，這樣的效率就太低下了。 而用fastcgi的方式的話，這課trie樹在進程啓動時建立，以後就可以直接在trie樹上查詢指定的前綴了。
[問1]
我也是 c cgi 的堅定支持者，而且親自試驗過 FastCGI 的穩定性和高性能。但是很長時間我也沒查明白：爲什麼現在使用 cgi 的網站那麼少，FastCGI 更少了?
[答1]
你這個問題問的非常好,
都知道 CGI 只是個技術標準(目前使用的是 CGI/1.1), 因爲該標準非常簡單所有它很容易用各種高級語言和腳本語言進行描述; 但它也給 CGI 開發者帶來了困難, 那就是過去沒有非常好的開發工具以開發方便開發者開發複雜的應用. 很多時候它們不得不手工 printf 輸入每一句 html 語句. 這樣嚴重限制了傳統 cgi 的發展;
與此同時, 另一批工具(暫時稱之爲泛 CGI吧), 如 asp, jsp, php, 它們繼承了 CGI 標準的簡單性, 同時提供了相應的解釋或編譯工具. 通過這些工具, 開發人員只要在 html/xml 模板文件中嵌入相應(腳本)語句即可, 特別是 asp.net 開發環境, php 之後的模板技術等, jsp 等 strust 框架等都爲開發人員提供了更爲抽象化的開發工具, 使開發人員徹底忘記了它們(asp, php, jsp等)的前身 CGI (之所以稱它們爲泛 CGI, 因爲它們都是 CGI 技術的繼承和發展者).
[問3]
php的性能是因爲成了服務器的模塊，但是 c cgi 也能編寫成模塊的模式，特別是 FastCGI 天生幾乎就是服務器的模塊，可是爲什麼用的人那麼少呢？
而且我自己的試驗證明，FastCGI 極穩定，不穩定基本是程序沒編寫好，有內存泄露、忘記重置等問題造成的.
[答3]
PHP 也可以作爲 CGI 運行, 同時也支持 FastCGI.
php 性能是因爲成了服務器的模塊， 這導致 php 非常依賴服務器, 所以通常 php 只在 apahce 服務器具有非常好的性能, 換個 webserver 甚至它是不能運行的. 嚴格遵守 CGI 標準的應用工具應該是不存在這些問題的.
不過, 在適當的應用中, 爲了性能犧牲一些特性爲是必要的.
對 FastCGI 要有充分的信心, FastCGI 沒有問題, 在很多應用中證明它都有很好的表現.
前面提及, 用的少主要原因是在 CSP/eybuild 之前大家沒有很好的編寫複雜應用的 CGI 開發工具.
[問4]
實際應用上，多數人會選擇 apache 或 IIS ...
[答4]
WEB 服務應用領域是主要用這兩個服務器, 不過其它 web 應用(如設備管理/控制等), 使用的 webserver 就很廣泛了, 如 thttpd, mini-httpd, goAhead, lighttpd, boa, ...
它們可能還要運行在不同的 CPU 架構(如 inter, xscale, arm, mips, ...)下, 不同的存儲器限定環境中(如只有 2M, 8M, 16M的內存) 無硬盤, 只有幾M的 flash 等,
這些環境的應用中, 目前最主要的 web 開發語言都是 c, ...
[問5]
我認爲隨着ajax應用的普及，模板技術有逐漸被取代的趨勢
[答5]
ajax 是一種非常不錯客戶端技術, 通在不刷新整個頁面的情況下給用戶帶來很新體驗. 它服務器端的技術互相補充相互依賴, 從目前的形式看, 還很難說誰會取代誰的趨勢. 根據項目和應用不同, 開發者應該靈活選擇它們要選用的開發工具和開發技術, 並進一有效的融合, 不宜單純一味追求某一技術.
[問6]
web標準客戶端的結構、表現、行爲分離，確實是好框架，是發展趨勢，而且能簡化服務器端開發。我認爲隨着應用的普及，模板技術會被取代。那時候，開發服務端只要編程就可以了，完全脫離頁面的束縛。
[答6]
呵呵, W3C 關於 結構、表現、行爲分離 確實極大地推動了 web 技術的發展,
但它主要是指結構-(html)、表現(css)、行爲(js) 三者的分離, 是一種客戶端技術, 與取代模板關係不大.
一般認爲 ajax 的目標把富客戶端, 弱服務器, 它可能對 服務器端的模板技術有一對衝擊.
1,2 C/C++本身的模板技術已經足夠了。 論壇裏面我寫過一個模板能滿足99％的cgi開發
而java的一些框架和技術，是其他產品無法或者難以替代的
3,4 錯誤，php比c cgi更適應各種平臺。什麼情況會只有2m內存，硬盤？ 也只能適合嵌入式了
5.6 ajax 技術不能代替任何現有的，對google的盲目崇拜而已。ajax被用在很多不適合的地方， 大多又都帶來加大服務器消耗的代價
使用FastCGI只會愈來愈少。
