深入分解 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: 数据包包体所占字节数。

（编辑：河北网）

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