PHP 之 FastCGI 与 mod_php

深入&浅出：FastCGI、mod_php与PHP-FPM的前世今生

网络上关于FastCGI和mod_php的资料常常零散且不够系统，这给初学者带来了不少困扰。为此，我们特地梳理了这份指南，希望能为你提供一个清晰、全面的视角。

背景：从Apache到Nginx的演变

对于许多开发者来说，最初接触PHP时，它总是以模块（mod_php）的形式运行在Apache服务器中，这几乎是Apache处理PHP的默认方式。然而，当我们转向Nginx时，会发现它使用的是另一个名词：PHP-FPM。这不禁让人好奇，PHP-FPM究竟是什么？它和PHP本身又是什么关系？今天，就让我们一层层揭开它们的神秘面纱。

核心角色：PHP处理器（PHP Handlers）

首先，我们需要建立一个基本认知：无论是Apache还是Nginx，它们本质上都是为发送HTML、图片等静态资源而设计的Web服务器。它们自身并没有能力去解释PHP、Python这类动态脚本。

那么，动态的PHP代码由谁来解释呢？答案就是PHP处理器。它的职责非常明确——解释Web应用中的PHP代码，将其“翻译”成HTML或其他静态资源，然后将这个结果交还给Web服务器，最终由服务器送达用户的浏览器。

可以说，正是因为大多数Web服务器“看不懂”PHP，才需要PHP处理器这个专业的“翻译官”。

沟通的桥梁：SAPI

现在问题来了：Apache或Nginx如何与PHP处理器建立连接并进行通信呢？

这就要提到SAPI（服务器端应用编程接口）了。简单理解，SAPI是PHP与特定运行环境（如Web服务器）对话的接口规范。这就像一台PC主机，无论你安装Windows、Linux还是macOS，只要符合PC的硬件接口规范，系统都能正常运行。PHP脚本的执行方式也很多样，可以通过Web服务器，也可以在命令行下，甚至能嵌入到其他程序中。

而在Web开发领域，最常用的两种SAPI连接方式便是mod_php和mod_fastcgi。

经典模式：mod_php

让我们先回顾一下熟悉的场景：Apache是如何识别并处理PHP文件的？通常，我们需要在Apache的配置文件`httpd.conf`中添加或修改这么几行：

// 添加模块
LoadModule php5_module modules/libphp5.so
AddType application/x-httpd-php .php

// 修改默认索引文件
DirectoryIndex index.php index.html index.htm index.html

这样一来，PHP便作为Apache的一个内置子模块运行。每当有用户请求访问PHP文件时，Apache就会直接调用`php5_module`来解析代码。在这种模式下，PHP成为了Apache进程本身的一部分，每一个新创建的Apache子进程都会加载这个PHP模块。

进化模式：mod_fastcgi 与 FastCGI 协议

那么，Nginx常用的PHP-FPM又属于哪种模式呢？查看PHP-FPM的官方说明，第一句就点明了：“一个用于PHP的简单而健壮的FastCGI进程管理器”。这说明PHP-FPM是辅助mod_fastcgi模式工作的。但FastCGI本身是什么？它管理的又是什么进程？

基石：什么是CGI？

要理解FastCGI，得先从其前身CGI说起。CGI（通用网关接口）堪称Web技术史上的里程碑。它定义了外部应用程序（CGI程序）与Web服务器之间的交互标准，是两者之间传递信息的“协议”。

正是CGI规范，使得Web服务器能够执行外部程序，并将程序的输出（通常是动态生成的HTML）发送给浏览器。它将互联网从一堆简单的静态文档，转变成了一个充满交互可能的新媒体。简而言之，CGI确保了服务器传递给后端程序的数据是标准格式。

升级：什么是FastCGI？

FastCGI，你可以把它理解为CGI的“长效”升级版。传统的CGI模式是“一次一销”（fork-and-execute）：每来一个请求，就启动一个新的进程来处理，处理完毕该进程就结束。这种频繁的进程创建和销毁是性能的主要瓶颈。

而FastCGI则采用了“常驻内存”（long-live）的方式。它会预先启动并保持进程运行，等待请求的到来。处理完一个请求后，进程并不退出，而是继续等待下一个。这不仅避免了频繁创建进程的开销，还支持分布式运算——FastCGI程序甚至可以运行在网站服务器之外的其他主机上。

本质上，FastCGI是一种与编程语言无关、可伸缩的CGI开放扩展。它的核心价值在于将CGI解释器进程常驻内存，通过进程管理器来调度，从而获得了优异的性能、伸缩性和故障转移能力。

FastCGI 是如何工作的？

它的工作流程可以概括为以下几个步骤：

1. Web服务器（如Nginx）启动时，加载FastCGI进程管理器（对于Nginx，是通过FastCGI模块；对于Apache，则是mod_fastcgi模块）。
2. FastCGI进程管理器初始化自己，并启动多个CGI解释器进程（例如多个php-cgi进程），然后进入等待状态。
3. 当客户端的请求到达Web服务器时，FastCGI进程管理器会选择一个空闲的CGI解释器进程与之连接。
4. Web服务器将相关的环境变量和请求数据（标准输入）发送给这个FastCGI子进程（php-cgi）。
5. FastCGI子进程完成数据处理后，将结果（标准输出）和错误信息通过同一个连接返回给Web服务器。
6. 请求处理完毕，连接关闭，但这个FastCGI子进程并不会退出，而是被回收，等待处理下一个连接。这与传统CGI处理完即退出的模式截然不同。

所以说，FastCGI是CGI的增强版，它是一种协议，充当了PHP、Python、Ja va等程序与Apache、Nginx等Web服务器之间的“翻译官”。理论上，任何语言编写的程序都能通过FastCGI来提供Web服务。它的关键优势在于，一个进程可以连续处理多个请求，并且通常通过维护一个进程池来进一步提升效率。

用更通俗的话解释：FastCGI需要提前启动，并且可以启动多个工作进程。这些进程就像随时待命的“服务生”，一直运行着等待Web服务器（“前台”）发来订单（请求）。接到订单后，“服务生”进行加工处理（PHP解析运算），做好“菜”（生成HTML）后递给“前台”，然后继续等待下一个订单，而不是下班离开。

最终的拼图：PHP-FPM

现在，我们终于可以清晰地定义PHP-FPM了：它就是PHP语言对FastCGI协议的一种具体实现，并且额外肩负着“进程管理器”的职责。PHP-FPM负责管理一个PHP进程池（里面运行着多个php-cgi解释器进程），专门处理来自Web服务器的请求。

不过需要明确一点：PHP-FPM本身并不解析PHP代码。它作为“经理”，负责调度和管理；真正的“解析工作”仍然由PHP解释器（例如在Linux下的php-cgi进程）来完成。PHP-FPM确保了这些解释器进程高效、稳定地运行。

---

技术世界日新月异，保持学习是应对变化的最好方式。希望本文能帮助你理清这些核心概念，在Web开发的路上走得更稳、更远。

原文转载自：https://www.cnblogs.com/houruikk/p/7401075.html