FastCGI工作原理-CSDN博客

本文链接：https://blog.csdn.net/sgbfblog/article/details/26965335

本文详细介绍了FastCGI的工作原理及其在Apache中的应用。FastCGI作为一种改进的CGI技术，通过保持持久的进程来提高Web应用程序的性能。文章解释了FastCGI管理进程如何创建并复用CGI解释器，以及在Apache的不同工作模式下FastCGI的具体运行机制。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

FastCgi工作原理

1.前言

在公司的实际项目中，目前web服务器用的都是apache+fastcgi或者nginx+uwsgi两种方式。后端采用python。fastcgi相比cgi性能有很明显的提升，所以该文主要是探讨一下fastcgi的工作原理，采用的web服务器是apache，在apache加载模块mod_fastcgi来实现fastcgi的功能。

2.fastcgi原理

从Fastcgi官网的介绍就可以比较清楚的知道fastcgi的运作原理。那么具体到apache里面，可能会有些细节是需要重新审视的，在之前的文章有介绍过apache安装fastcgi模块，下面看看fastcgi在apache的运行原理。
既然是在apache中加载fastcgi模块，首先需要说明一下apache的工作模式。apache现在主流的模式有两种，prefork和worker模式。这可以在conf/extra/http-mpm.conf文件中进行配置，注意在http.conf中加入include conf/extra/http-mpm.conf,不然配置就无效了。当然要使用这些工作模式，在源码编译的时候是需要加上相应的编译参数的。要查看apache的运行模式，可以通过命令bin/apachectl -l命令实现。两种模式的区别是prefork是进程模式，使用多个子进程，每个进程在确定的时间只维持一个连接，效率高，内存占用大。worker模式则是进程和线程混合模式，一个子进程可以有多个线程，每个线程在确定的时间只维持一个连接。优点是内存占用较小，缺点是如果一个线程挂掉，则整个子进程都会一起死掉。目前新版本apache使用较多的是worker模式。
fastcgi是基于cgi的扩展。普通cgi的工作流程是这样的：web服务器接收客户端请求，然后把请求提交给cgi程序，cgi程序根据用户输入参数处理请求，返回标准的html语句给web服务器，web服务器再返回给客户端。fasctcgi的核心思想是在web服务器和cgi程序之间建立一个智能的可持续的中间cgi程序管理层。即有一个fastcgi管理进程一直在运行，该管理进序会创建可复用的cgi程序实例。具体步骤如下：
- web服务器(比如apache)启动时载入FastCgi管理进程。
- fastcgi管理进程自身初始化，并创建多个cgi解释器。（我们用的是python）。
- 客户端请求到达web服务器后，web服务器将请求发送到fastcgi管理进程，fastcgi管理进程选择并连接到一个cgi解释器。
- fastcgi子进程完成处理后将标准输出和错误信息返回给fastcgi管理进程，然后再由fastcgi管理进程返回给web服务器完成本次操作，并等待下一次连接。（注意这时cgi解释器程序并没有退出，而在cgi模式中这次连接处理完成cgi程序就会退出)

3.实例

以apache配置mod_fastcgi作为实例分析，apache的worker模式为例，假设在http-mpm.conf中配置的StartServers=5的话，则除了最初的apache进程，apache启动后还会创建一个fcgi进程和5个apache子进程。fcgi进程在接收请求后会根据请求数量来创建相应数目的cgi解释器程序。具体数目视请求并发数和fastcgi配置而定。注意这里的进程父子关系，fcgi进程和之前的5个apache子进程的父进程都是最初的apache进程。而后续cgi解释器进程的父进程是fcgi进程，不是apache子进程派生出来的哦。关于FastCgi配置可以参见FastCgiConfig。注意其中的参数maxClassProcesses和maxProcesses的区别，maxClassProcesses指的是每个cgi解释器程序最大实例数目，也就是说如果有个cgi是/cgi-bin/my.py，那么这个python程序进程最多可以创建maxClassesProcesses个。maxProcesses是所有解释器程序最大实例数目。即总的python解释器数目不能大于maxProcesses。