有了CGI为什么还需要Nginx?

NIO
  • 330

查阅了资料后, 有一个笼统的理解, 请指正:

在一个计算机上运行着一个网站, 有如下分工.

1. Nginx 监听计算机的某一个端口(比如80), 等待用户的request

2. 远程有一个用户执行了一个request, Nginx监听到了, 然后把这个请求传给CGI程序(比如Python的WSGI)

3. CGI程序接受请求, 运行对应的代码, 然后返回一个response

上面的理解对吗? 如果是对的, Nginx为什么要存在呢? 因为好像就算没有Nginx, 直接用CGI接受请求也是可以的样子, 仅仅是为了负载平衡吗?

谢谢.

回复
阅读 11.6k
8 个回答
✓ 已被采纳

蟹妖。一股知乎范儿
首先把问题修正为为什么CGI与WebServer不能互相替代? 因为CGI是一种标准,Nginx则是一种应用。两者不是同类,所以下面用WebServer代替Nginx

CGI是一种标准,Nginx则是一种应用。
浏览器的角度来看,浏览器只负责发送请求,接收来自WebServer的返回结果并渲染之。对于WebServer来讲,它需要做的仅仅是接收请求,寻找浏览器请求的文件并且发送回去。如果仅仅是这样,世界就很完美了。
但是后来发生的事情大家都知道了。。我们不光要浏览静态网页,我们还要登陆论坛、发帖骂人灌水踩答案点赞刷声望等等。这些行为是静态的Html没法完成的。所以有了JS、Flash等等基于前端的交互技术。WebServer把包含了这些代码的文件发给浏览器,后者把它解析称它应该有的样子(或者不应该有的样子,比如IE6),我们可以在页面上看看动画什么的,这些称之为前段交互技术。
但是有些交互前端做不了, 比如我上次发了一个高清无码套图,我要看到大家的反应,点个赞啊楼主好人啊之类的,那么这个技术就要用到数据库,但是数据库本身是需要另外一种语言来操作的,这种语言可以是python、prel、Ruby、PHP等等,我们称之为动态语言。他们对数据库进行增删查改四大操作,并且返回结果给WebServer,后者再传给浏览器。

由于有很多动态语言和很多种Web服务器,他们彼此之间互不兼容,给程序员造成了很大的麻烦。那么,CGI应运而僧。CGI的定义是统一网关接口。从此WebServer收到后台动态交互请求就直接发给CGI,CGI发给动态语言,动态语言把结果发回给CGICGI再发回给WebServer,后面的事情你都清楚了。。。。

那么结论就是,CGI是一个翻译层,它的功能不是直接提供结果给浏览器,而是翻译来自WebServer的请求并转给后台的应用程序,并且把执行结果翻译成静态网页返回给WebServer,所以,是不能互换的。

最后,写的比较仓促,很多表述有不严谨的地方,欢迎拍砖。

  • 负载均衡
  • 反向代理
  • 平滑升级
  • 扩容灾备
  • 隐藏CGI语言种类
  • 记录日志
  • gzip

太多了,我觉得仔细想想以后我还能列出至少和上面一样长的nginx的其他好处

浏览器跟 Web 服务器间的通信是 HTTP 协议。浏览器不支持 CGI/FastCGI 协议,所以无法抛弃 Nginx 直接跟 FPM 、PHP-CGI 等通信。

Nginx本质是个web server,如果直接用CGI,那么这个CGI就成了web server,逻辑又混乱了。
CGI是为了处理动态的逻辑。
web server仅仅是一个HTTP服务的实现,只管收一个请求,然后回复一个相应的响应(通常是一个HTML页面,根据请求的不同,也可以是其它的文件),不管任何逻辑。所有的逻辑处理,都是扔给CGI的。比如用户登录的验证等。

可以把Nginx想像为传令兵,主要的活不是他做的,但是如果没有他,
实际干活的人就是亲自跑去接任务、交任务。

不是不能做,而是干活的人只愿意关心工作如何做好,
不愿意做跑腿那堆事儿,把自己的功能弄成大杂烩。

你不觉得如果没有Nginx,你列出的4点中的第1点就没人干了吗?

静态文件,基本都交给nginx去处理了。
动态的请求的话,nginx相当于一层路由了,想转到哪儿就转到哪儿,cgi只需要专注处理具体的业务逻辑即可

Daemon_Zhao
  • 2
新手上路,请多包涵

我是看了这里的神评后,果断注册账号的。。新手小白,学习中。。。

宣传栏