歡迎您光臨本站 註冊首頁

為什麼現在使用 cgi 的網站那麼少,FastCGI 更少了

←手機掃碼閱讀     火星人 @ 2014-03-05 , reply:0

為什麼現在使用 cgi 的網站那麼少,FastCGI 更少了

這個問題困惑了很多網友,
下文是一段半月前與某網友的討論的整理, 希望對大家有幫助.

[問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 技術的繼承和發展者).

注: CGI 是指 WEB server 與 WEB 應用程序之間的通用介面標準, 即: Common Gateway Interface.

[問2]
原來如此,總覺得他們的原理和cgi類似,實際正是cgi的拓展和封裝,我們完全可以自己用 c 編寫更強的拓展和封裝!

[答2]
是的, CSP/eybuild 是一種類似於 asp, jsp, php 的 C/C++ 語言的開發工具, 它能彌補了傳統 C 開發 CGI 的不足, 同時提供了類似 asp, jsp, php的模板技術,虛擬目錄,自動掃描鏈接等技術, 使 c 開發人員可以不編寫一句 c 代碼的的情況下即可編寫一完整的站點框架, c 開發人員只要專註編寫邏輯處理即可, 使得 c 開發人員和 html/jsp/css 等開發人員進行有效的分離. 這使得 cgi 編寫非常簡單, asp, php, jsp 等的站占只是換一編程即可.
CSP/eybuild 對 FastCGI 擁有很好的支持和裁剪性, 只要在添加一個編譯選項 cgi 程序即轉成了 fastcgi 程序
[問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 是一種非常不錯客戶端技術, 通在不刷新整個頁面的情況下給用戶帶來很新體驗. 它伺服器端的技術互相補充相互依賴, 從目前的形式看, 還很難說誰會取代誰的趨勢. 根據項目和應用不同, 開發者應該靈活選擇它們要選用的開發工具和開發技術, 並進一有效的融合, 不宜單純一味追求某一技術.
不得不承認, 包括 CSP/eybuild 的很多開發應用都採用了 Ajax .

[問6]
web標準客戶端的結構、表現、行為分離,確實是好框架,是發展趨勢,而且能簡化伺服器端開發。我認為隨著應用的普及,模板技術會被取代。那時候,開發服務端只要編程就可以了,完全脫離頁面的束縛。

[答6]
呵呵, W3C 關於 結構、表現、行為分離 確實極大地推動了 web 技術的發展,
但它主要是指結構-(html)、表現(css)、行為(js) 三者的分離, 是一種客戶端技術, 與取代模板關係不大.
一般認為 ajax 的目標把富客戶端, 弱伺服器, 它可能對 伺服器端的模板技術有一對衝擊.

另外, CSP/eybuild 的 eyForm(javascript 庫) 就是關於結構與行為分離的有效性檢查的 JS 庫, 會對你理解結構、表現、行為分離有所幫助.
以上只是個人的拙見, 希望能解答你的問題.

(為避嫌, 故隱去部分內容).

[ 本帖最後由 newzy 於 2007-5-21 23:21 編輯 ]
《解決方案》

雖然是在做廣告,但還是要支持一下的。
因為以前我也用c做過cgi,用c寫過網頁,能體會到其中的痛苦,哈哈哈。
基於goAhead的,

[ 本帖最後由 hake2000 於 2007-5-21 15:04 編輯 ]
《解決方案》

1,2.   c/c++本身的模板技術已經足夠了。 論壇裡面我寫過一個模板能滿足99%的cgi開發
      而java的一些框架和技術,是其他產品無法或者難以替代的
3,4 錯誤,php比c cgi更適應各種平台。什麼情況會只有2m內存,硬碟? 也只能適合嵌入式了
5。6 ajax 技術不能代替任何現有的,對google的盲目崇拜而已。ajax被用在很多不適合的地方, 大多又都帶來加大伺服器消耗的代價


使用FastCGI只會愈來愈少。
《解決方案》

原帖由 xinglp 於 2007-5-21 20:33 發表
我也是從C CGI/FastCGI起步的,這方面用的很少,現在都開始直接寫Web伺服器了,但是還是很難在這方面找工作,一般用C開發的地方都是高負荷的場合,開發成本高用的自然就少,中國人習慣見效塊,也就是Java的快捷開 ...

沒實際的工作經驗, 你不了解現在的IT環境。
web需要簡單架構。簡單的增加伺服器,就能平衡php,jsp的負載,即便sina,yahoo這樣大網站。

分散式的系統,web的性能瓶頸基本都在DB和I/O, 開放語言本身的性能都可以忽律不計。從未見過瓶頸在web伺服器的。
一台伺服器才多少錢,一個高級程序員月薪多少?

不必中國人習慣見效快的,  有喜歡見效慢的嗎?
《解決方案》

用c封裝一套cgi的庫也不是一件很麻煩的事情。
就單純的從開發速度,開發成本和維護成本還是php更適合web開發。
個人感覺web頁面也實在算沒有必要用c開發。
當然如果用c來寫cgi的話對程序員的要求稍微高點。
《解決方案》

說白了CGI會越來越少,Web應用開發有兩種趨勢,JSP .Net...和專用Web伺服器
《解決方案》

樓主newzy好久不見了,呵呵

一些純技術架構、追求性能和平台成本的項目解決方案都會選擇cgi方式,如果項目負責人了解FastCGI就更好了

基於cgi(c)的新型架構LAPC/F(Linux、Apache、PostgerSQL、gcc(c)、FastCGI)
c代碼嵌入html開發方式(類似於asp、php),方便頁面開發
SQL嵌入c代碼開發方式(E/SQL),代碼與sql融合使資料庫操作更直觀,且便於資料庫系統移植
c代碼中允許使用中文變數名、函數名,使代碼更容易維護
...盡在
http://lapcf.calvinwilliams.name/

[火星人 ] 為什麼現在使用 cgi 的網站那麼少,FastCGI 更少了已經有1198次圍觀

http://coctec.com/docs/service/show-post-37898.html