php,CGI,FastCGI,SCGI

php,CGI,FastCGI,SCGI

2008-12-07 14:39

最近在搞apache+php,想把apache中默认支持的CGI程序换成fastcgi。对CGI,FastCGI,PHP了解了一些。

PHP

超文本预处理器, Hypertext Preprocessor, 是一种被广泛应用的开放源代码的多用途脚本语言, 它可嵌入到 HTML中, 尤其适合 WEB 开发.
和客户端的 JavaScript 不同的是，PHP 代码是运行在服务端的。如果您在您的服务器上建立了如上例类似的代码，则在运行该脚本后，客户端就能接收到其结果，但他们无法得知其背后的代码是如何运作的。您甚至可以将 WEB 服务器设置成让 PHP 来处理所有的 HTML 文件，这么一来，用户就无法得知服务端到底做了什么。这是和客户端脚本的本质区别。
PHP 主要是用于服务端的脚本程序，因此您可以用 PHP 来完成任何其它的 CGI 程序能够完成的工作，例如收集表单数据，生成动态网页，或者发送/接收 Cookies。

PHP是一种运行在服务器端的语言或者脚本。完全可以代替CGI程序了。

CGI

CGI(common Gateway Interface,公共网关接口).是Web服务器与外部程序之间通信方式的标准.（这个“其他程序”可以使用任何计算机语言来编写，它通过CGI这个接口从HTTP服务器取得输入，然后把运行的结果又通过CGI这个接**给HTTP服务器，而HTTP服务器把这个结果送给浏览器。）。CGI(Common Gateway Interface)是HTTP服务器与你的或其它机器上的程序进行“交谈”的一种工具，其程序须运行在网络服务器上。
CGI处理步骤：
⑴通过Internet把用户请求送到服务器。
⑵服务器接收用户请求并交给CGI程序处理。
⑶CGI程序把处理结果传送给服务器。
⑷服务器把结果送回到用户。

浏览器→服务器→CGI→程序，之后在返回来。浏览器（HTML）收到用户请求，比如评论，表单，查询搜索关键词等之后发给服务器，服务器根据URL或者其他来源特征去相应目录执行CGI脚本。CGI脚本执行基于输入数据的操作，包括查询数据库、计算数值或调用系统中其他程序.脚本产生某种Web服务器能理解的输出结果. 服务器接收来自脚本的输出并且把它传回浏览器，让用户了解结果。

特意的看了下关于评论的CGI程序，才感觉是相当的常见只是自己一直没有注意罢了。现在把关于评论表单的CGI大概的写下来供自己理解吧。

URL 编码是一种浏览器用来打包表单输入的格式. 浏览器从表单中获取所有的name和其中的值 ，将他们作为name/value参数编码, 移去那些不能传送的字符, 将数据排行等等，这些还取决于你用GET还是POST?作为URL的一部分或者分离地发给服务器. 不管哪种情况, 在服务器端的表单输入格式样子象这样:

theName=Ichabod+Crane&gender=male&status=missing&headless=yes

URL编码遵循下列规则:

• 每对name/value由&符分开.
• 每对来自表单的name/value由=符分开. 如果用户没有输入值给这个name,那么这个name还是出现，只是无值(象这样 "name=").
• 任何特殊的字符(就是那些不是简单的七位ASCII，如汉字) 将以百分符%用十六进制编码. 当然也包括象 =, &, 和 % 这些特殊的字符.
• 在输入区中的空格将以加号+显示.

因为表单输入是用这个URL编码传递给你的脚本的，在你用这些参数之前必须解码，因为解码是个很普遍的工作，可以有很多工具做这个工作 . 你没有必要自己写这个解码程序.

上面的格式是不是相当常见啊。哈哈~~所以用PHP做为运行在服务器端的脚本语言，几乎可以来完成任何其它的 CGI 程序能够完成的工作，例如收集表单数据，生成动态网页，或者发送/接收 Cookies。

FastCGI

增强型的CGI程序。Fastcgi到底是什么样的技术呢。作为一种替代cgi的技术标准, fastcgi有如下优点(稳定,安全,高性能,方便扩展)

1.从稳定性上看, fastcgi是以独立的进程池运行来cgi,单独一个进程死掉,系统可以很轻易的丢弃,然后重新分配新的进程来运行逻辑.

2.从安全性上看, fastcgi和宿主的server完全独立, fastcgi怎么down也不会把server搞垮,

3.从性能上看, fastcgi把动态逻辑的处理从server中分离出来, 大负荷的IO处理还是留给宿主server, 这样宿主server可以一心一意作IO,对于一个普通的动态网页来说, 逻辑处理可能只有一小部分, 大量的图片等静态IO处理完全不需要逻辑程序的参与。

4.从扩展性上讲, fastcgi是一个中立的技术标准, 完全可以支持任何语言写的处理程序(php,java,python...)

从实际配置的apache+fastcgi的几篇文章中看到apache对fastcgi的支持mod_fastcgi简直就是一塌糊涂, 最新的稳定版本居然还是2003年的,snap也只到2004年, 在1.3下面还勉强可以用, 在apache2.0上更是被报告无法稳定运行.fastcgi在[lighttpd][]上表现还算不错, 但是lighttpd在用户群,兼容性上还不够主流(也就在linux上面表现不错, 没有正式的windows版本, solaris下面也有bug). 另外fastcgi也缺乏发展,让人有被废弃掉了的感觉.（查了下fastcgi的官方网站，他们也提到fastcgi没多少发展，现在也在apache上面有很好的表现了，所以对上面那段话暂不能苟同，实验之后在说或者请教其他牛人吧。）

从名字上看fastcgi是fast的cgi的,属于改良派.从理论上,他可以很多程序语言接口来开发动态web,但是这些程序语言每一个都是走完全革命的道路. java阵营就自己搞了一套j2ee server标准,要协作也直接找apache或者IIS谈,瞧不上fastcgi. aspx直接和IIS是亲兄弟,没有fastcgi的份. 剩下的php因为太流行(LAMP),和apache是铁哥们,一个mod_php就解决了,简单方便, python社区的牛人太多,精力旺盛,人家搞了个SCGI玩,和fastcgi比是有过之而无不及. 等到rails出山的时候, fastcgi真的算是老态龙钟了.rails的出现使得fastcgi重新焕发了青春, apache也开始重新构建新的mod_proxy_fcgi,但是它的前途还不能说是一片光明, 至少有以下几个问题:

目前的fastcgi和server沟通还不够智能,一个fastcgi进程如果执行时间过长会被当成是死进程杀掉重起,这样在处理长时间任务的时候很麻烦.这样做也使得fastcgi无法允许联机调试.

SCGI等类似技术的都可以替换fastcgi, SCGI在python中很成功,功能完备,目前SCGI也开始支持rails了

随着rails的流行,一个独立的mod_rails是可能出现的,而且ruby自身的webserver也开始涌现,以后极有可能自己搞一套东西连接主流的webserver.fastcgi设计的时候是想作common gateway interface(cgi)的,但是这个目标的现在看来已经不适合了.

类似的CGI技术还有SCGI，WSGI。I