设为首页 - 加入收藏 阳江站长网 (http://www.mxzcj.com)- 国内知名站长资讯网站,提供最新最全的站长资讯,创业经验,网站建设等!
热搜: 平台 图片 网络 模式
当前位置: 主页 > 站长资讯 > 外闻 > 正文

深入剖析 Web 服务器与 PHP 应用的通信机制 - 掌握 CGI 和 FastCGI 协议的运行原理

发布时间:2018-12-17 20:22 所属栏目:[外闻] 来源:Web开发
导读:副标题#e# 身为一名使用 PHP 语言开发后端服务的程序猿,我们每天都和 PHP 以及 Web 服务器产生无数次的亲密接触。得益于它们,我们才能够如此快速的构建出令人陶醉的 Web 产品。 尽管我们已经和 Web 服务器和 PHP 建立起深厚的友谊,但你知道它们之间为何

身为一名使用 PHP 语言开发后端服务的程序猿,我们每天都和 PHP 以及 Web 服务器产生无数次的亲密接触。得益于它们,我们才能够如此快速的构建出令人陶醉的 Web 产品。

尽管我们已经和 Web 服务器和 PHP 建立起深厚的友谊,但你知道它们之间为何能够配合的如此默契么?

这一切都需要从 CGI(Common Gateway Interface:通用网关接口)协议说起。但是请不要对 CGI 协议产生任何的恐惧心理,它并非什么特别复杂的协议,如果你对它不甚了解,可能的原因或许是你还有花一点小心思来学习它。

深入剖析 Web 服务器与 PHP 应用的通信机制 - 掌握 CGI 和 FastCGI 协议的运行原理

所以,你应该明白,现在你应该抽出 20 多分钟仔细的研究一下: Web 服务器与 PHP 应用之间是如何进行通信的这个问题。

介绍

我们知道 PHP 自 5.4 起为我们内置的 Web 服务器。不过在此之前的版本(或者不使用这个内置服务器时),我们就需要使用其他的 Web 服务器,通常是 Nginx 或者 Apache 这两块 Web 服务器,来部署我们的 PHP 应用。

这就涉及一个问题,当用户发起一个 HTTP 请求后,我们的 PHP 应用程序在处理这个请求时并没有直接的解析这个 HTTP 协议,而是可以直接从 $GET、$POST 和 $_SERVER等全局变量中,获取到用户请求数据和其它系统环境。这究竟又是为何呢?

要想整明白这个问题,我们就不得不需要整明白一个问题:CGI 协议。

CGI 协议同 HTTP 协议一样是一个「应用层」协议,它的 功能 是为了解决 Web 服务器与 PHP 应用(或其他 Web 应用)之间的通信问题。

既然它是一个「协议」,换言之它与语言无关,即只要是实现类 CGI 协议的应用就能够实现相互的通信。

深入 CGI 协议

我们已经知道了 CGI 协议是为了完成 Web 服务器和应用之间进行数据通信这个问题。那么,这一节我们就来看看究竟它们之间是如何进行通信的。

简单来讲 CGI 协议它描述了 Web 服务器和应用程序之间进行数据传输的格式,并且只要我们的编程语言支持标准输入(STDIN)、标准输出(STDOUT)以及环境变量等处理,你就可以使用它来编写一个 CGI 程序。

CGI 的运行原理

  • 当用户访问我们的 Web 应用时,会发起一个 HTTP 请求。最终 Web 服务器接收到这个请求。
  • Web 服务器创建一个新的 CGI 进程。在这个进程中,将 HTTP 请求数据已一定格式解析出来,并通过标准输入和环境变量传入到 URL 指定的 CGI 程序(PHP 应用 $_SERVER)。
  • Web 应用程序处理完成后将返回数据写入到标准输出中,Web 服务器进程则从标准输出流中读取到响应,并采用 HTTP 协议返回给用户响应。

一句话就是 Web 服务器中的 CGI 进程将接收到的 HTTP 请求数据读取到环境变量中,通过标准输入转发给 PHP 的 CGI 程序;当 PHP 程序处理完成后,Web 服务器中的 CGI 进程从标准输出中读取返回数据,并转换回 HTTP 响应消息格式,最终将页面呈献给用户。然后 Web 服务器关闭掉这个 CGI 进程。

可以说 CGI 协议特别擅长处理 Web 服务器和 Web 应用的通信问题。然而,它有一个严重缺陷,对于每个请求都需要重新 fork 出一个 CGI 进程,处理完成后立即关闭。

CGI 协议的缺陷

  • 每次处理用户请求,都需要重新 fork CGI 子进程、销毁 CGI 子进程。
  • 一系列的 I/O 开销降低了网络的吞吐量,造成了资源的浪费,在大并发时会产生严重的性能问题。

深入 FastCGI 协议

从功能上来讲,CGI 协议已经完全能够解决 Web 服务器与 Web 应用之间的数据通信问题。但是由于每个请求都需要重新 fork 出 CGI 子进程导致性能堪忧,所以基于 CGI 协议的基础上做了改进便有了 FastCGI 协议,它是一种常驻型的 CGI 协议。

本质上来将 FastCGI 和 CGI 协议几乎完全一样,它们都可以从 Web 服务器里接收到相同的数据,不同之处在于采取了不同的通信方式。

再来回顾一下 CGI 协议每次接收到 HTTP 请求时,都需要经历 fork 出 CGI 子进程、执行处理并销毁 CGI 子进程这一系列工作。

而 FastCGI 协议采用 进程间通信(IPC) 来处理用户的请求,下面我们就来看看它的运行原理。

FastCGI 协议运行原理

FastCGI 进程管理器启动时会创建一个 主(Master) 进程和多个 CGI 解释器进程(Worker 进程),然后等待 Web 服务器的连接。

Web 服务器接收 HTTP 请求后,将 CGI 报文通过 套接字(UNIX 或 TCP Socket)进行通信,将环境变量和请求数据写入标准输入,转发到 CGI 解释器进程。

CGI 解释器进程完成处理后将标准输出和错误信息从同一连接返回给 Web 服务器。

CGI 解释器进程等待下一个 HTTP 请求的到来。

为什么是 FastCGI 而非 CGI 协议

如果仅仅因为工作模式的不同,似乎并没有什么大不了的。并没到非要选择 FastCGI 协议不可的地步。

然而,对于这个看似微小的差异,但意义非凡,最终的结果是实现出来的 Web 应用架构上的差异。

CGI 与 FastCGI 架构

在 CGI 协议中,Web 应用的生命周期完全依赖于 HTTP 请求的声明周期。

对每个接收到的 HTTP 请求,,都需要重启一个 CGI 进程来进行处理,处理完成后必须关闭 CGI 进程,才能达到通知 Web 服务器本次 HTTP 请求处理完成的目的。

但是在 FastCGI 中完全不一样。

FastCGI 进程是常驻型的,一旦启动就可以处理所有的 HTTP 请求,而无需直接退出。

再看 FastCGI 协议

通过前面的讲解,我们相比已经可以很准确的说出来 FastCGI 是一种通信协议 这样的结论。现在,我们就将关注的焦点挪到协议本身,来看看这个协议的定义。

同 HTTP 协议一样,FastCGI 协议也是有消息头和消息体组成。

消息头信息

主要的消息头信息如下:

  • Version:用于表示 FastCGI 协议版本号。
  • Type:用于标识 FastCGI 消息的类型 - 用于指定处理这个消息的方法。
  • RequestID:标识出当前所属的 FastCGI 请求。
  • Content Length: 数据包包体所占字节数。

【免责声明】本站内容转载自互联网,其相关言论仅代表作者个人观点绝非权威,不代表本站立场。如您发现内容存在版权问题,请提交相关链接至邮箱:bqsm@foxmail.com,我们将及时予以处理。

网友评论
推荐文章
金亚洲信誉