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

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

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

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

所以，你应该明白，现在你应该抽出 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: 数据包包体所占字节数。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!