fastcgi與cgi的區(qū)別

先講下cgi：
cgi在2000年或更早的時候用得比較多， 以前web服務(wù)器一般只處理靜態(tài)的請求，如果碰到一個動態(tài)請求怎么辦呢？web服務(wù)器會把根據(jù)這次請求的內(nèi)容，然后會fork一個新進程運行外部c程序 （或perl腳本...）， 這個進程會把處理完的數(shù)據(jù)返回給web服務(wù)器，最后web服務(wù)器把內(nèi)容發(fā)送給用戶，剛才fork的進程也隨之退出。 如果下次用戶還請求改動態(tài)腳本，那么web服務(wù)器又再次fork一個新進程，周而復(fù)始的進行。

后來出現(xiàn)了一種更高級的方式是， web服務(wù)器可以內(nèi)置perl解釋器或php解釋器。 也就是說這些解釋器做成模塊的方式，web服務(wù)器會在啟動的時候就啟動這些解釋器。 當(dāng)有新的動態(tài)請求進來時，web服務(wù)器就是自己解析這些perl或php腳本，省得重新fork一個進程，效率提高了。

fastcgi的方式是，web服務(wù)器收到一個請求時，他不會重新fork一個進程（因為這個進程在web服務(wù)器啟動時就開啟了，而且不會退 出），web服務(wù)器直接把內(nèi)容傳遞給這個進程（進程間通信，但fastcgi使用了別的方式，tcp方式通信），這個進程收到請求后進行處理，把結(jié)果返回 給web服務(wù)器，最后自己接著等待下一個請求的到來，而不是退出。
fastcgi跟cgi的區(qū)別是：
                  在web服務(wù)器方面                                                         在對數(shù)據(jù)進行處理的進程方面
cgi         fork一個新的進程進行處理                                           讀取參數(shù)，處理數(shù)據(jù)，然后就結(jié)束生命期
fastcgi   用tcp方式跟遠程機子上的進程或本地進程建立連接       要開啟tcp端口，進入循環(huán)，等待數(shù)據(jù)的到來，處理數(shù)據(jù)

舉個例子: 服務(wù)端現(xiàn)在有個10萬個字單詞， 客戶每次會發(fā)來一個字符串，問以這個字符串為前綴的單詞有多少個。 那么可以寫一個程序，這個程序會建一棵trie樹，然后每次用戶請求過來時可以直接到這個trie去查找。 但是如果以cgi的方式的話，這次請求結(jié)束后這課trie也就沒了，等下次再啟動該進程時，又要新建一棵trie樹，這樣的效率就太低下了。   而用fastcgi的方式的話，這課trie樹在進程啟動時建立，以后就可以直接在trie樹上查詢指定的前綴了。

[問1]
我也是 c cgi 的堅定支持者，而且親自試驗過 FastCGI 的穩(wěn)定性和高性能。但是很長時間我也沒查明白：為什么現(xiàn)在使用 cgi 的網(wǎng)站那么少，F(xiàn)astCGI 更少了?

[答1]
你這個問題問的非常好,
都知道 CGI 只是個技術(shù)標(biāo)準(zhǔn)(目前使用的是 CGI/1.1), 因為該標(biāo)準(zhǔn)非常簡單所有它很容易用各種高級語言和腳本語言進行描述; 但它也給 CGI 開發(fā)者帶來了困難, 那就是過去沒有非常好的開發(fā)工具以開發(fā)方便開發(fā)者開發(fā)復(fù)雜的應(yīng)用. 很多時候它們不得不手工 printf 輸入每一句 html 語句. 這樣嚴(yán)重限制了傳統(tǒng) cgi 的發(fā)展;

與此同時, 另一批工具(暫時稱之為泛 CGI吧), 如 asp, jsp, php, 它們繼承了 CGI 標(biāo)準(zhǔn)的簡單性, 同時提供了相應(yīng)的解釋或編譯工具. 通過這些工具, 開發(fā)人員只要在 html/xml 模板文件中嵌入相應(yīng)(腳本)語句即可, 特別是 asp.net 開發(fā)環(huán)境, php 之后的模板技術(shù)等, jsp 等 strust 框架等都為開發(fā)人員提供了更為抽象化的開發(fā)工具, 使開發(fā)人員徹底忘記了它們(asp, php, jsp等)的前身 CGI (之所以稱它們?yōu)榉?CGI, 因為它們都是 CGI 技術(shù)的繼承和發(fā)展者).

[問3]
php的性能是因為成了服務(wù)器的模塊，但是 c cgi 也能編寫成模塊的模式，特別是 FastCGI 天生幾乎就是服務(wù)器的模塊，可是為什么用的人那么少呢？
而且我自己的試驗證明，F(xiàn)astCGI 極穩(wěn)定，不穩(wěn)定基本是程序沒編寫好，有內(nèi)存泄露、忘記重置等問題造成的.

[答3]
PHP 也可以作為 CGI 運行, 同時也支持 FastCGI.
php 性能是因為成了服務(wù)器的模塊， 這導(dǎo)致 php 非常依賴服務(wù)器, 所以通常 php 只在 apahce 服務(wù)器具有非常好的性能, 換個 webserver 甚至它是不能運行的. 嚴(yán)格遵守 CGI 標(biāo)準(zhǔn)的應(yīng)用工具應(yīng)該是不存在這些問題的.
不過, 在適當(dāng)?shù)膽?yīng)用中, 為了性能犧牲一些特性為是必要的.

對 FastCGI 要有充分的信心, FastCGI 沒有問題, 在很多應(yīng)用中證明它都有很好的表現(xiàn).
前面提及, 用的少主要原因是在 CSP/eybuild 之前大家沒有很好的編寫復(fù)雜應(yīng)用的 CGI 開發(fā)工具.

[問4]
實際應(yīng)用上，多數(shù)人會選擇 apache 或 IIS ...

[答4]
WEB 服務(wù)應(yīng)用領(lǐng)域是主要用這兩個服務(wù)器, 不過其它 web 應(yīng)用(如設(shè)備管理/控制等), 使用的 webserver 就很廣泛了, 如 thttpd, mini-httpd, goAhead, lighttpd, boa, ...
它們可能還要運行在不同的 CPU 架構(gòu)(如 inter, xscale, arm, mips, ...)下, 不同的存儲器限定環(huán)境中(如只有 2M, 8M, 16M的內(nèi)存) 無硬盤, 只有幾M的 flash 等,
這些環(huán)境的應(yīng)用中, 目前最主要的 web 開發(fā)語言都是 c, ...

[問5]
我認(rèn)為隨著ajax應(yīng)用的普及，模板技術(shù)有逐漸被取代的趨勢

[答5]
ajax 是一種非常不錯客戶端技術(shù), 通在不刷新整個頁面的情況下給用戶帶來很新體驗. 它服務(wù)器端的技術(shù)互相補充相互依賴, 從目前的形式看, 還很難說誰會取代誰的趨勢. 根據(jù)項目和應(yīng)用不同, 開發(fā)者應(yīng)該靈活選擇它們要選用的開發(fā)工具和開發(fā)技術(shù), 并進一有效的融合, 不宜單純一味追求某一技術(shù).

[問6]
web標(biāo)準(zhǔn)客戶端的結(jié)構(gòu)、表現(xiàn)、行為分離，確實是好框架，是發(fā)展趨勢，而且能簡化服務(wù)器端開發(fā)。我認(rèn)為隨著應(yīng)用的普及，模板技術(shù)會被取代。那時候，開發(fā)服務(wù)端只要編程就可以了，完全脫離頁面的束縛。

[答6]
呵呵, W3C 關(guān)于 結(jié)構(gòu)、表現(xiàn)、行為分離 確實極大地推動了 web 技術(shù)的發(fā)展,
但它主要是指結(jié)構(gòu)-(html)、表現(xiàn)(css)、行為(js) 三者的分離, 是一種客戶端技術(shù), 與取代模板關(guān)系不大.
一般認(rèn)為 ajax 的目標(biāo)把富客戶端, 弱服務(wù)器, 它可能對 服務(wù)器端的模板技術(shù)有一對沖擊.