CGI 和 FastCGI 协议的运行原理

目录

• 介绍
• 深入cgi协议
• 深入fastcgi协议
• php-fpm

介绍

在用php开发的过程中，我们常常使用nginx或者apache作为我们的web服务器。但是php是如何与这些web服务器通信的呢？

• apache把php作为一个模块集成到apache进程(httpd)运行,这种mod_php的运行模式与php-cgi没有任何关系。

• nginx是通过fastcgi来实现与php的通信。

要谈fastcgi就必须先说说cgi。那什么是cgi？

cgi(common gateway interface:通用网关接口)是web 服务器运行时外部程序的规范,按cgi 编写的程序可以扩展服务器功能。cgi 应用程序能与浏览器进行交互,还可通过数据库api 与数据库服务器等外部数据源进行通信,从数据库服务器中获取数据。--百度百科

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

消息类型定义

• begin_request: 从 web 服务器发送到 web 应用，表示开始处理新的请求。

• abort_request: 从 web 服务器发送到 web 应用，表示中止一个处理中的请求。比如，用户在浏览器发起请求后按下浏览器上的「停止按钮」时，会触发这个消息。

• end_request: 从 web 应用发送给 web 服务器，表示该请求处理完成。返回数据包里包含「返回的代码」，它决定请求是否成功处理。

• params: 「流数据包」，从 web 服务器发送到 web 应用。此时可以发送多个数据包。发送结束标识为从 web 服务器发出一个长度为 0 的空包。且 params 中的数据类型和 cgi 协议一致。即我们使用 $_server 获取到的系统环境等。

• stdin: 「流数据包」，用于 web 应用从标准输入中读取出用户提交的 post 数据。

• stdout: 「流数据报」，从 web 应用写入到标准输出中，包含返回给用户的数据。

web 服务器和 fastcgi 交互过程

• web 服务器接收用户请求，但最终处理请求由 web 应用完成。此时，web 服务器尝试通过套接字（unix 或 tcp 套接字，具体使用哪个由 web 服务器配置决定）连接到 fastcgi 进程。

• fastcgi 进程查看接收到的连接。选择「接收」或「拒绝」连接。如果是「接收」连接，则从标准输入流中读取数据包。

• 如果 fastcgi 进程在指定时间内没有成功接收到连接，则该请求失败。否则，web 服务器发送一个包含唯一的requestid 的 begin_request 类型消息给到 fastcgi 进程。后续所有数据包发送都包含这个 requestid。 然后，web 服务器发送任意数量的 params 类型消息到 fastcgi 进程。一旦发送完毕，web 服务器通过发送一个空params 消息包，然后关闭这个流。 另外，如果用户发送了 post 数据 web 服务器会将其写入到 标准输入（stdin） 发送给 fastcgi 进程。当所有 post 数据发送完成，会发送一个空的 标准输入（stdin） 来关闭这个流。

• 同时，fastcgi 进程接收到 beginrequest 类型数据包。它可以通过响应 endrequest 来拒绝这个请求。或者接收并处理这个请求。如果接收请求，fastcgi 进程会等待接收所有的 params 和 标准输入数据包。 然后，在处理请求并将返回结果写入 标准输出（stdout） 流。处理完成后，发送一个空的数据包到标准输出来关闭这个流，并且会发送一个 end_request 类型消息通知 web 服务器，告知它是否发生错误异常。

为什么需要在消息头发送 requestid 这个标识？

如果是每个连接仅处理一个请求，发送 requestid 则略显多余。

但是我们的 web 服务器和 fastcgi 进程之间的连接可能处理多个请求，即一个连接可以处理多个请求。所以才需要采用数据包协议而不是直接使用单个数据流的原因：以实现「多路复用」。

因此，由于每个数据包都包含唯一的 requestid，所以 web 服务器才能在一个连接上发送任意数量的请求，并且 fastcgi 进程也能够从一个连接上接收到任意数量的请求数据包。

另外我们还需要明确一点就是 web 服务器 与 fastcgi 进程间通信是 无序的。即使我们在交互过程中看起来一个请求是有序的，但是我们的 web 服务器也有可能在同一时间发出几十个 begin_request 类型的数据包，以此类推。

php-fpm

php-fpm即php-fastcgi process manager.

php-fpm是fastcgi的实现，并提供了进程管理的功能。

进程包含 master 进程和 worker 进程两种进程。

master 进程只有一个，负责监听端口，接收来自 web server 的请求，而 worker 进程则一般有多个(具体数量根据实际需要配置)，每个进程内部都嵌入了一个 php 解释器，是 php 代码真正执行的地方。

php-fpm 是 fastcgi 进程管理器（php fastcgi process manager）()，用于替换 php 内核的 fastcgi 的大部分附加功能（或者说一种替代的 php fastcgi 实现），对于高负载网站是非常有用的。

php-fpm如何工作的？

php-fpm 进程管理器有两种进程组成，一个 master 进程和多个 worker 进程。master 进程负责监听端口，接收来自 web 服务器的请求，然后指派具体的 worker 进程处理请求；worker 进程则一般有多个 (依据配置决定进程数)，每个进程内部都嵌入了一个 php 解释器，用来执行 php 代码。

nginx 服务器如何与 fastcgi 协同工作

nginx 服务器无法直接与 fastcgi 服务器进行通信，需要启用 ngx_http_fastcgi_module 模块进行代理配置，才能将请求发送给 fastcgi 服务。

转载:

php和apache是如何通信的?

nginx+php-fpm运行原理详解

掌握cgi和fastcgi协议的运行原理