CGI
Python
wikipedia中对 CGI 有比较详尽的描述, 基于自己的理解总结如下.首先,CGI在web服务器处理请求中的角色关系如下图:
CGI 在其中扮演的是在web服务器和特定语言解释器之间输入输出的协议的角色, 每个来自用户的请求, web服务器都会唤起特定语言解释器的命令行(例如Python), CGI 会作为一种约定来将web服务器获得的请求数据(如url,pos t data)等,有选择地 作为命令行参数来输入到解释器的命令行中(标准输入), 解释器根据输入 构造出特定的html作为标准输出, 此时 CGI 又会对输出作额外的处理,如加入特定的header(mimetype,cookie等)返回给web服务器,继而返回给用户(web服务器可能会作额外的处理).这就是一个完整的处理流程.
CGI 作为一种标准协议后,各种主流的web服务器都支持,如 apache, IIS 等, 那么从上面的处理流程中我们会发现其中的几个主要缺点:1.对于每个请求,都需要新创建一个解释器的进程,而进程的创建通常都是比较昂贵的(expens ive)
2.而且,对于脚本语言,解释器还需要一定的时间来解释生成对应的html
3.更大机率的 code injection, 因为在cgi脚本中都是手动地处理html所以更容易引起代码注入(当然更多地取决于程序员本身)
环境如下:Ubuntu 8.101.Apache 2.x2.Python 2.5.2
编辑apache配置文件(我的是/etc/apache2/apache2.conf), 加入下面一行:AddHandler cgi-script .py告诉apache来使用CGI协议来解释python文件.
这里是个helloworld的应用, 更复杂的可参考 Python CGI.代码如下(假设名为tes t.py):#! /usr/bin/env pythonprint "Content-Type: text/html" # HTML is followingprint # blank line, end of headersprint "
如果你弄清楚了上面的示例,你就能够明白 各种web框架(django, cakephp等),都只是简化和封装了一些处理的方式,本质还是类似于C GI的处理方式, 即1)header 2)html.想想 django 的 return HttpResponse("
既然这些缺陷是如此明显,后续的一些web服务器的设计者或者web开发者便开始着手解决这些问题, 比较重要的有:fas tcgi 的出现, fas tcgi 的处理流程如下
web服务器和解释器之间使用TCP或者s ocket来连接,在启动时会启动若干个(可以配置)长驻进程来提供请求的服务(减少建立和销毁进程的开销), 一个进程可以服务于多个请求(使用多线程或者事件驱动,参考 fas tcgis pec).所以 fas tcgi 很好地解决了进程建立/销毁开销的问题.
另一个思路是类似于apache的mod_perl这样的解决方式.这种方式是将处理逻辑集成在web服务器之中, 如下图:
其中你可以在Data Axis (竖轴)上, Content Generator 之前或者之后来加入相应的filter(即module), 来进行特定的处理.
通常而言,集成在web服务器中的module方式,会有更好的性能优势, 但是因为是集成在web服务器中, 所以mod_xxx崩溃很有可能会使得web服务器也崩溃.而 fas tcgi 与web服务器之间是独立的进程 一个挂了不会影响另一个.
最后,我们回到我的室友提到的那个问题, QQ居然还在用C GI, 通过上面的分析,我们现在应该很明确了, 使用纯的CGI并不是一个好的办法, 因为它的诸多缺陷, 所以可以使用 fas tcgi 或者module的方式.当然,作为最初动态网页内容处理的始祖, CGI 是具有里程碑式意义的协议,到后来的 fas tcgi, s cgi 等 都是与CGI 的理念相同的.
您的帮助是我们莫大的动力！感谢有您一路相随，记得点击页面右上角的“大拇指”或者“两角箭头”，谢谢了。