Nginx解析PHP的原理 | CGI、FastCGI及php-fpm的关系

Nginx解析PHP的原理,CGI/FastCGI以及PHP-Fpm的关系.

一、PHP+Nginx应运而生的场景.
随着互联网的发展,用户对此接受面广,数据流的增大使得Web端的运行承载压力日益增大,野蛮生长在大数据时代里的WEB语言PHP也找到了比老搭档更优越的活力搭档Nginx,说到Nginx咱就一起唠一唠这其中的奥妙.

从以下几个维度来剖析一下Nginx的活力所在,当然是和解析PHP的老搭档APACHE相比而言.

  1. 性能
    1.1 资源占有率少,节省内存资源
    1.2 非阻塞式的请求处理机制给之增加了强劲动力,这也是为什么能在高迸发折腾下保持金枪不倒之势. 哈哈~
    1.3 有很多资料千篇一律说性能比Apache提升了3倍,这块不敢苟同。
  2. 延展性
    2.1 高内聚的模块化设计,简介的模块编写,使得产品更具魅力和活力
    2.2 有活跃的技术社区和技术群体,便于技术的支持度.
  3. 量级和可用性
    3.1 轻量级
    3.2 解析静态页面远比解析动态页面性能好.
    3.3 配置更简洁友好,戒掉了臃肿. 美中不足的是URL重写还待加强.
    3.4 新兴意味着有稳定性的挑战和GUG的伴随,当然不必担忧,有前人铺路呢.

二、什么是CGI、什么是FastCGI,什么是PHP-Fpm,什么是PHP-cgi

CGI :是一个可伸缩地、高速地在HTTP server和动态脚本语言间通信的接口
FastCGI : 是CGI的fast版本(哈哈,急速版)多数流行的HTTP server都支持FastCGI,包括Apache、Nginx和lighttpd等,这一带Fast可了不得了:
1.性能提升.他老爹处理请求时遇到动态脚本解析器。
2.升级附带了支持高迸发性
3.安全上做了升级
说道性能提升了,肯定有性能提升之道,那提升的原理是啥呢?
1.1 接口处理方式采用了 C/S 结构. 在处理机制上就使得HTTP服务和脚本解析器剥离开来,使得部署变得可分离,这样脚本解析服务器可以分出来多个守护进程,遇到动态脚本则分发给FastCIG,将得到结果反给浏览器。HTTP服务器呢则一心一意的干静态资源解析方面的活。这就相当于是多线程的概念啦,当然会快呀。
PHP-Fpm : 这个就是咱们上面提到的脚本解析守护进程.
PHP-Cgi : 是PHP自带的FastCGI管理器。

三、Nginx如何解析PHP
Nginx 是没法解析动态脚本的,下面看一张原理解析图片,说白了Nginx解析php是通过fast-cig + php-fpm配合完成的.
用户通过浏览器访问PHP页面时候,流程是首先请求到了Nginx服务器,服务器发现是动态请求,Nginx通过Fast-cgi接口来跟动态脚本PHP通信,Fast-cig在Linux下是socket(文件或者Ip类型),通信过程中由FastCGI的wrapper(wrapper可理解为用于启动另外一个线程的程序)进而启动一个CIG的解析器.Web server将CGI环境变量和标准输入发送到FastCGI子进程php-cgi
FastCGI子进程完成处理后将标准输出和错误信息从同一连接返回Web Server再返回给用户。当FastCGI子进程关闭连接时,请求便告处理完成。FastCGI子进程接着等待并处理来自FastCGI进程管理器(运行在Web Server中)的下一个连接。 在CGI模式中,php-cgi在此便退出了,在php-cgi启动的过程中,会有守护者或者说管理者(PHP-fpm),防止php-cgi的崩溃.
这样整流程也算完成了.


PHP源码分析 - PHP-FPM运行原理

我们知道web服务器与PHP应用之间通过SAPI接口进行交互数据。PHP提供了多种SAPI接口,例如 apache2hander、fastcgi、cli等等。当然,php-fpm也是其中一种。相比其他接口,php-fpm运用更加广泛。

php-fpm是一种master(主)/worker(子)多进程架构,与nginx设计风格有点类似。master进程主要负责CGI及PHP环境初始化、事件监听、子进程状态等等,worker进程负责处理php请求。
在介绍运行原理之前,我们先了解下它的几种运行模式。

运行模式
php-fpm支持三种运行模式,分别为static、ondemand、dynamic,默认为dynamic 。
static : 静态模式,启动时分配固定的worker进程。
ondemand: 按需分配,当收到用户请求时fork worker进程。
dynamic: 动态模式,启动时分配固定的进程。伴随着请求数增加,在设定的浮动范围调整worker进程。

这三种模式各有千秋,大家可以根据不同的环境调整相应的配置。

下面进入本文主题,着重介绍php-fpm运行原理。

运行原理
php-fpm采用master/worker架构设计,前面简单地描述master和worker进程模块的功能。下面将详细讲解这两个模块的运行原理。

master进程
master进程工作流程分为4个阶段,如下图:

1. cgi初始化阶段:分别调用fcgi_init()和 sapi_startup()函数,注册进程信号以及初始化sapi_globals全局变量。
2. php环境初始化阶段:由cgi_sapi_module.startup 触发。实际调用php_cgi_startup函数,而php_cgi_startup内部又调用php_module_startup执行。 php_module_startup主要功能:a).加载和解析php配置;b).加载php模块并记入函数符号表(function_table);c).加载zend扩展 ; d).设置禁用函数和类库配置;e).注册回收内存方法;
3. php-fpm初始化阶段:执行fpm_init()函数。负责解析php-fpm.conf文件配置,获取进程相关参数(允许进程打开的最大文件数等),初始化进程池及事件模型等操作。
4. php-fpm运行阶段:执行fpm_run() 函数,运行后主进程发生阻塞。该阶段分为两部分:fork子进程 和 循环事件。fork子进程部分交由fpm_children_create_initial函数处理( 注:ondemand模式在fpm_pctl_on_socket_accept函数创建)。循环事件部分通过fpm_event_loop函数处理,其内部是一个死循环,负责事件的收集工作。

worker进程
worker进程分为 接收客户端请求、处理请求、请求结束三个阶段。


1. 接收客户端请求:执行fcgi_accept_request函数,其内部通过调用accept 函数获取客户端请求。

//请求锁
FCGI_LOCK(req->listen_socket);
req->fd = accept(listen_socket, (struct sockaddr *)&sa, &len);
//释放锁
FCGI_UNLOCK(req->listen_socket);

从上面的代码,可以注意到accept之前有一个请求锁的操作,这么设计是为了避免请求出现“惊群”的现象。当然,这是一个可选的选项,可以取消该功能。
2. 处理请求阶段:首先,分别调用fpm_request_info、php_request_startup获取请求内容及注册全局变量($_GET、$_POST、$_SERVER、$_ENV、$_FILES);然后根据请求信息调用php_fopen_primary_script访问脚本文件;最后交给php_execute_script执行。php_execute_script内部调用zend_execute_scripts方法将脚本交给zend引擎处理。
3. 请求结束阶段:执行php_request_shutdown函数。此时 回调register_shutdown_function注册的函数及__destruct()方法,发送响应内容、释放内存等操作。

总结
php-fpm采用master/worker架构设计, master进程负责CGI、PHP公共环境的初始化及事件监听操作。worker进程负责请求的处理功能。在worker进程处理请求时,无需再次初始化PHP运行环境,这也是php-fpm性能优异的原因之一。

原文地址:https://www.cnblogs.com/rxbook/p/10343125.html