当前位置: 首页 > 网络学院 > 设计教程 > 设计理念 > CGI剖析:第二部分

设计理念
图形简介:第一部分
图形简介:第二部分
图形简介:第三部分
图形简介:第四部分
网站规划101
通过网络赚取客户的信任
网站配色:第一部分
网站配色:第二部分
CGI剖析:第一部分
CGI剖析:第二部分
CGI剖析:第三部分
下拉表单:第一部分
下拉表单:第二部分
下拉表单:第三部分
网站设计公司:第一部分
网站设计公司:第二部分
Web 标准
HTML 元素
样式表
Web 易读性

设计理念 中的 CGI剖析:第二部分


出处:互联网   整理: 软晨网(RuanChen.com)   发布: 2009-03-01   浏览: 1684 ::
收藏到网摘: n/a

CGI is at the mercy of HTTP. It is important to note that HTTP only provides for a one-time, question/answer type of communication. After all, it was defined primarily for web browsers and web servers to exchange HTML documents. Thus, by definition, HTTP is not very dynamic.

CGI
是受HTTP所支配的。很重要的一点就是要注意:HTTP是提供一次性提问/回答的交流方式。毕竟,它主要是定义为使浏览器和网络服务器来转换HTML文档。因而,精确的说,HTTP并不具备太多的动态性质。

One-time, question/answer communication works like this: the web browser and the web server are only connected as long as it takes for the web browser to send one document request and the web server to send one requested document. If the browser wants a second document, it must recontact the server and ask again. Each request is new. The server maintains no ongoing connection or record of past exchanges.

一次性提问/回答式的交流方式是这样工作的:仅当网络浏览器发送文档请求以及网络服务器发送被请求的文件时,网络浏览器和网络服务器才建立连接。如果希望获取第二份文档,那么它必须重新与服务器建立连接并且再次发出请求。每个请求都是全新的。服务器是不会一直与过去的信息交互保持持续的链接或记录的。

While this is very efficient for network traffic (because the bandwidth is only used when information needs to be exchanged), it is a big pain in the butt when it comes to CGI, because CGI is about conversations, not about one-time question/answers

然而,这对网络流量来说非常有效(因为带宽仅用在当信息需要交换的时候),当涉及到CGI的时候就会感到异常头痛,因为CGI是关于对话的,并不是关于一次性提问/回答的。

Imagine that when talking on the phone you had to hang up and redial every time you said something and received an answer. Imagine further that every time you called back you had to go over every previous exchange before you could get to the next piece. That is the way web browsers work with web servers and this makes communication tough.

你可以想象一下,当通过电话机通话时,你必须拿着电话,并且,每当你要将事情或者收到对方回答的时候,你都需要重拨一次号码(多么麻烦啊)。再深入考虑一下,每当你回拨电话时,你都要在进入下一个环节之前回顾每一项先前交换过的信息。这就是网络浏览器与网络服务器工作的方式,显然,这会导致交流上的巨大不便。

This makes communication tough for three reasons.

这会使得交流变得非常困难,主要有三点原因:

First, if the client and server are to maintain information over several exchanges, the CGI must be responsible for keeping a running dictation of the conversation so that every time there is a new exchange, the web server can consult the record of the entire conversation up to that point. This is what CGI aficionados call "maintaining state". The CGI script must be able to keep track of certain information like username or the contents of a virtual shopping cart for every "instance" of a script. That is, there must be a way to tie the current HTTP request to related ones that have gone on before. Maintaining state is possible with CGI using hidden variables, by encoding the URL, or by maintaining a state file on the server, it's just not easy or efficient.

第一,如果客户端和服务器需要维护多条信息交换,CGI将负责监听连续的对话信息,这样一来,服务器就可以询问整个对话中的每次新交换的信息。这就是CGI狂热者们宣称的“维持状态”。为了使每个“实例”脚本程序正确运行,CGI脚本必须能够对购物车的特定信息(如:用户名)或者内容了如指掌。这也就是说,必须将当前的HTTP请求与以前相关的信息进行绑定。如果CGI能够通过对URL进行编码,或者通过维护服务器上的陈述文件来使用隐藏变量,那么就可以实现“维持状态”。但这并不简单或者有效。

Second, every set of question/answers causes the web server to execute a unique instance of the CGI script. This is pretty expensive, especially on a high volume web site that may have 100 instances of a CGI script executing at any given moment, each, perhaps, with its own Perl interpreter. Every one of those CGI scripts takes a little bit of oomph out of the server engine. If we were not limited to question/answer format, we would not need to execute so many instances.

第二,每组提问/回答都会迫使网络服务器执行一个独一无二的CGI脚本实例。这样的成本是非常昂贵的,特别是对于一个大流量的网站来说,可能会在特定的时刻对100个实例同时执行一个CGI脚本程序,并且,可能每个实例都会有其自己的Perl解释器。每一个CGI脚本都会占用一部分服务器引擎的资源。如果我们不是被限制在提问/回答这样的格式上的话,我们将不会执行这么多的实例。

Consider the following CGI application executing....
设想一下下面的CGI应用程序执行情况……

Client: Hello?

客户端:你好?

 

Server: Welcome, what would you like (CGI script executed once)

服务器:欢迎你,需要点什么?(执行一次CGI脚本)

 

Client: I would like a list of products you are selling

客户端:我想要一份你出售的产品列表。

 

Server: Here is a list (another one)

服务器:这就是你所需要的列表。(再次执行一次CGI脚本)

 

Client: I want to purchase this product

客户:我想购买这个产品。

 

Server: Okay. 

服务器:没问题。(再次执行一次CGI脚本)

 

Client: I'm done, can I check out?

客户端:我决定好了,我可以付钱了吗?

 

Server: Yes, what is your credit card number? (another script)

服务器:好的,你的信用卡卡号是多少?(再次执行一次CGI脚本)

 

Client: Here it is.

客户端:给你。

 

    Server: Thanks (another instance of the script that also emails the

            results to some store admin)

    服务器:谢谢。(执行另一个脚本实例,这个脚本实例会将结果通过email发送到指定的商店)

 

Yuck, this exchanged caused 5 instances of the store script to be executed as well as 5 Perl interpreters if the CGI script was written in Perl.

真是烦人,这份信息交换包含5个被执行的商店脚本程序实例。如果这个CGI脚本程序是由Perl写成的,那么Perl将被解释5次。

Third, CGI is extremely slow. Every time the client does something, the CGI Script must recreate the entire dialog and execute a new request. Add a new item to a virtual shopping cart - new request. Calculate a running total - new request. Submit an order - yet another request. Each request takes time and since the CGI script must be executed again and everyone must wait for a busy Internet.

第三,CGI的执行速度太慢。每当客户操作一次,CGI程序必须重新创建整个对话,并且执行一个全新的请求,在购物车中添加一个全新的项目——新的请求,计算连续发送的新请求总数,提交一份订单,然后再轮到下一个请求。每个请求都会花费一定的时间。并且,CGI脚本程序必须再次执行一次,因此,每个人都必须等待这个繁忙的互联网。

评论 (1) 1 All

登陆 | 还没注册?