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 的目標把富客戶端, 弱服務器, 它可能對 服務器端的模板技術有一對沖擊.