Nginx解析PHP脚本的过程

Bertha 。 2022-06-02 10:49 216阅读 0赞

之前项目中碰到了一些php-fpm的问题：因为网站的一些接口，在特定情况下响应特别慢（1-2分钟），迟迟不结束，导致php-fpm数量越来越多，最后到达127个后，服务器就没能响应正常请求了，浏览器一直打转，迟迟不响应。把接口修好后，php-fpm进程的数量就稳定了，问题得以解决。这让我对php-fpm这个进程产生了兴趣。

在百度和google了不少文章后，我总结了一下关于CGI，fastCGI，PHP-FPM，php-cgi的概念，还有nginx解析PHP的过程，如下：（博主知识水平有限，如果有不对的地方，欢迎大家指正）

## 1、什么是CGI ##

> CGI是Common Gateway Interface（公共网关接口）的缩写，它有什么用呢？我们知道浏览器访问一个含有动态数据的页面，浏览器使用HTTP协议发送请求。数据包经过路由器和交换机，到达目标web服务器，web服务器收到这个请求，需要和PHP通信，才能拿到含有动态数据的页面。为什么要通信？因为他们语言不通（nginx等web服务器和php语言和语法不一样，没法直接沟通）

那么，要怎么通信呢？最早是用CGI协议来通信。通过CGI协议，nginx能够将HTTP请求转化为PHP可以理解的语言（uri，post数据和get的数据，HTTP header等数据）。CGI规定了要传哪些数据、以什么样的格式传递给后方处理。

### 1、传统的使用CGI协议的工作方式 ###

> web服务器本身只是内容的分发者，比如请求/index.html，web服务器就会去寻找这个文件，然后返回给浏览器，这里指的只是静态文件。如果是请求/index.php会怎么样？web服务器知道这不是个静态资源，需要解析后再返回给浏览器，于是web服务器就启动一个php解释器进程，这个解释器实现了CGI协议，能够完成和后端语言PHP的沟通，PHP把该返回的动态数据还给web服务器，然后web服务器再发给浏览器。
> 
>   
> 
> 
> ### 2、传统的CGI协议的弊端 ###

为什么传统的CGI工作方式会有弊端？因为**每请求一个PHP脚本**，web服务器就得为一个请求开启一个PHP解释器（早期是php-cgi）进程来完成解析。这意味着：每来一个请求，解释器就得初始化php.ini并加载php扩展，等环境初始化完了，再解析，解析完成后进程自动结束（即fork-and-execute模式）。

所以用cgi方式的服务器有多少连接请求就会有多少cgi子进程，子进程反复加载是cgi性能低下的主要原因。都会当用户请求数量非常多时，会大量挤占系统的资源如内 存，CPU时间等，造成效能低下。

## 2、什么是fastCGI ##

> fastCGI，通俗的翻译为快速的CGI。FastCGI，顾名思义为更快的 CGI，它允许在一个进程内处理多个请求，而不是一个请求处理完毕就直接结束进程，web服务器性能上有了很大的提高。
> 
>   
> 
> 
> ### 1、关于php-fpm ###

php-fpm，即专门为php打造的fastCGI process manager（PHP的fastCGI管理器）。nginx使用这些php-fpm进程来和PHP进行通信，你可以理解把php-fpm理解为php解释器。

和传统的php-cgi的解释器不同，php-fpm实现了fastCGI协议，而且还新增了不少特性。比如php-fpm能够平滑重启php环境配置：我们知道在修改了php.ini之后，wamp和phpstudy需要重启服务器才能重新加载php.ini里的内容。如果是php-fpm，则不用重启web服务器，原先正在工作的php-fpm继续工作，等原先工作的php-fpm完成自己的工作后，就结束掉自己。新增加的php-fpm就使用修改后的php.ini即可。

### 2、实现了fastCGI的工作方式 ###

> 实现了fastCGI协议的nginx，第一次启动时，会启动一个php-fpm的master进程，该master进程初始化环境后，启动多个worker进程（即php-fpm进程池中的php-fpm），如下图：
> 
>   
> 
> 
> ![20160924172129213][]
> 
>   
> 
> 
> 当请求发来后，master进程把请求分发到进程池中的php-fpm，分发完后，就可以接下一个请求了，避免了重复劳动（重复加载php.ini初始化环境），效率自然提升了。当请求多的时候，master会启动更多的php-fpm子进程，当请求少的时候，master也会停掉一些子进程。既提高了性能，也节省资源。
> 
> 当然，当php-fpm设定的上限，不足以支持更高的并发请求时，nginx只能返回502错误了，因为没有更多的php-fpm进程可用了。
> 
> 在这种协议下，php-fpm成为了和PHP沟通的PHP解释器。
> 
>   
>

> ## 3、nginx是如何和php-fpm进程交流的 ##
> 
> 到目前为止，我们知道了实现了fastCGI的php-fpm是如何工作的，但是nginx是怎么启动php-fpm进程的呢？
> 
> Nginx 不仅仅是一个 Web 服务器，也是一个功能强大的 Proxy 服务器，除了进行 http 请求的代理，也可以进行许多其他协议请求的代理，包括本文与 fpm 相关的 fastcgi 协议。为了能够使 Nginx 理解 fastcgi 协议，Nginx 提供了 fastcgi 模块来将 http 请求映射为对应的 fastcgi 请求。
> 
>   
> 
> 
> 下面是一个nginx的配置文件，用来把nginx中的变量，解释为PHP能够理解的变量：
> 
>   
> 
> 
> ![20160924173926182][]  
> 
> 
>   
> 
> 
> 下面是nginx把php请求交给fastCGI模块来处理的配置（在nginx.conf中可以查到此项配置）
> 
>   
> 
> 
> ![20160924174133629][]  
> 
> 
>   
> 
> 
> 在这个配置文件中，我们新建了一个虚拟主机，监听在 80 端口，Web 根目录为 /home/rf/projects/wordpress。通过location配置，我们把所有.php文件的处理，交给了fastCGI模块。之后就是fastCGI模块启动php-fpm（实现fastCGI模块），并通过php-fpm来解释动态请求。
> 
>   
> 
> 
> 下面是我总结的一个流程图，如果有不正确的地方，欢迎指正。
> 
>   
> 
> 
> ![20160924215736345][]

[20160924172129213]: /images/20220602/50c89e73d6c24c1ba828b33a4dd6fece.png
[20160924173926182]: /images/20220602/2cb9c82a9d834a9ab20b5a648307f743.png
[20160924174133629]: /images/20220602/4159a8d790ff4cf5a3f021e8004e9224.png
[20160924215736345]: /images/20220602/d5ec870bacb4411ca65129b65179b3b2.png