FastCgi原理初探

本文详细介绍了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。

4.参考资料


### FastCGI 协议安全漏洞及原理 #### 安全漏洞概述 FastCGI 是一种用于 Web 服务器和应用程序之间通信的协议。该协议允许Web服务器将请求转发给处理程序,如PHP-FPM来执行脚本并返回响应。然而,在某些情况下,FastCGI实现可能存在严重的安全隐患。 CVE-2019-11043 描述了一个存在于 PHP-FPM 中基于 FastCGI 的远程代码执行 (RCE) 漏洞[^1]。此漏洞源于对特定参数缺乏充分验证,攻击者可以通过精心构造的数据包触发缓冲区溢出或其他逻辑错误,从而获得目标系统的控制权。 另一个值得注意的是未授权访问漏洞,这使得未经授权的应用实例能够接收到来自前端代理(比如 Nginx)传递过来未经严格过滤或认证的信息流。如果配置不当,则可能导致敏感信息泄露甚至更严重后果。 #### 工作流程中的潜在风险点 当客户端发起 HTTP 请求时,Nginx 等反向代理会依据预设规则解析这些请求并将它们转换为符合 FastCGI 规范的消息格式发送至后端处理器——即 PHP-FPM 实例所在位置;后者负责进一步拆解消息内容以便调用相应的解释引擎完成实际业务操作后再把结果反馈回去形成闭环交互过程[^2]。 在这个过程中存在几个可能引发问题的关键环节: - **输入校验不足**:对于来自外部环境提交的内容未能实施有效审查机制,容易被恶意利用。 - **权限管理缺失**:假如没有设置适当的身份鉴别措施,任何能接触到网络接口的人都可以尝试连接到 FPM 并发出指令。 - **资源隔离不彻底**:多租户环境下共享同一套基础设施却没能做到良好区分的话也会带来隐患。 为了防止上述情况的发生,开发者应当遵循最佳实践指南加强应用层面上的安全防护策略,并定期更新软件版本以修复已知缺陷。 ```python # 示例 Python 脚本模拟简单的 FastCGI 客户端行为 import flup.client.fcgi_client as fcgi def send_request(): try: client = fcgi.FCGIClient('localhost', 9000) env = { 'SCRIPT_FILENAME': '/var/www/html/index.php', 'REQUEST_METHOD': 'GET' } response = client.call(env, '') print(response.decode()) except Exception as e: print(f"Error occurred: {e}") if __name__ == "__main__": send_request() ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值