总结

CGI：是 Web Server 与 Web Application 之间数据交换的一种协议或规范

FastCGI：同 CGI，是一种通信协议，但比 CGI 在效率上做了一些优化

PHP-CGI：是 PHP （Web Application）对 Web Server 提供的 CGI 协议的接口程序

PHP-FPM：是 PHP（Web Application）对 Web Server 提供的 FastCGI 协议的接口程序，额外还提供了相对智能一些任务管理

Web Server 一般指 Apache、Nginx、IIS、Tomcat 等服务器，Web Application 一般指 PHP、Java、Asp.net 等应用程序

Module方式

https://www.awaimai.com/371.html
正式说 CGI 之前，先来了解一下 Web Server 传递数据的另外一种方法：web服务器内置 PHP Module 。
以 Apache 为例，在PHP Module方式中，在 Apache 的配置文件 httpd.conf 中加上这样几句：

  1. #添加下边两行
  2. LoadModule php5_module D:/php/php5apache2_2.dll
  3. AddType application/x-httpd-php .php
  4. # 修改如下内容
  5. <IfModule dir_module>
  6.     DirectoryIndex index.php index.html
  7. </IfModule>

当在 linux 环境下源码安装时，大致是这样：

./configure --with-mysql=/usr/local --with-apache=/usr/local/apache --enable-track-vars

用 LoadModule 来加载 php5_module，就是把php作为apache的一个子模块来运行。随着服务器的启动，PHP解释器模块也会随之启动；当通过web访问php文件时，apache就会调用php5_module来解析php代码。

sapi

php5_module 是如何将数据传给 php 的解析器来解析 php 代码的呢？
答案是：sapi

SAPI（Server Application Programimg Interface，服务端应用编程接口）相当于PHP外部环境的代理器。PHP可以应用在终端上，也可以应用在Web服务器中，应用在终端上的SAPI就叫作CLI SAPI，应用在Web服务器中的就叫作CGI SAPI。

用一张图来看 apache、php、sapi 三者之间的关系：

CGI、FastCGI、PHP-FPM - 图1

从上面图中，我们看出了 sapi 就是这样的一个中间过程，sapi 提供了一个和外部通信的接口，使得 PHP 可以和其他应用进行交互数据（apache，nginx 等）。
php 默认提供了很多种 sapi，常见的提供给 apache 和 nginx 的 php5_module、CGI、FastCGI，给 IIS 的 ISAPI，以及 Shell 的 CLI。

所以，以上的 apache 调用 php 执行的过程如下：
apache -> httpd -> php5_module -> sapi -> php
httpd 是 Apache 超文本传输协议 (HTTP) 服务器的主程序。被设计为一个独立运行的后台进程，它会建立一个处理请求的子进程或线程池

这种模式将 php 模块安装到 apache 中，每一次 apache 请求，都会产生一条进程，这个进程就完整的包括 php 的各种运算计算等操作

在上图中，我们很清晰的可以看到，apache每接收一个请求，都会产生一个进程来连接php通过sapi来完成请求，可想而知，如果一旦用户过多，并发数过多，服务器就会承受不住了。
而且，把 php 当做一个模块加载到 apache 中，出问题时很难定位是 php 的问题还是 apache 的问题
此外，mod_php 通过嵌入 PHP 解释器到 Apache 进程中，只能与 Apache 配合使用，而 cgi 和 fast-cgi 以独立的进程的形式出现，只要对应的Ｗeb服务器实现 cgi 或者 fast-cgi 协议，就能够处理 PHP 请求。
mod_php 这种嵌入的方式最大的弊端就是内存占用大，不论是否用到 PHP 解释器都会将其加载到内存中。

所以weib服务器内置模版弊端很多，而且随着php-fpm的稳定性越来越好，也越来越流行

CGI协议

common gateway interface (公共网关接口)，是WEB服务器与处理程序之间通信的一种协议。它允许 web 服务器通过特定的协议与应用程序通信

CGI 可以用任何一种语言编写，只要这种语言具有标准输入、输出和环境变量。如 php、perl、tcl 等

WEB 服务器会传哪些数据给 PHP 解析器呢？
URL、查询字符串、POST 数据、HTTP header，CGI就是规定要传哪些数据、以什么样的格式传递给后方处理这个请求的协议。

调用过程

也就是说，CGI 就是专门用来和 web 服务器打交道的。web 服务器收到用户请求，就会把请求提交给 cgi 程序（如 php-cgi），cgi 程序根据请求提交的参数作应处理（解析 php），然后输出标准的 html 语句，返回给 web 服服务器，WEB 服务器再返回给客户端，这就是普通 cgi 的工作原理（cgi 程序，你就可以理解成遵循 cgi 协议编写的程序）

请求流程

web server(如Nginx)只是内容的分发者。
如果请求/index.html，那么web server会去文件系统中找到这个文件，发送给浏览器，这里分发的是静态数据。

如果现在请求的是/index.php，根据配置文件，找PHP解析器来处理。
当web server收到/index.php这个请求后，会启动对应的CGI程序，这里就是PHP的解析器。接下来PHP解析器会解析php.ini文件，初始化执行环境，然后处理请求，再以CGI规定的格式返回处理后的结果，退出进程。web server再把结果返回给浏览器。

优点

CGI 的好处就是完全独立于任何服务器，仅仅是做为中间分支。提供接口给 web 服务器和 web 应用 (如提 nginx 和 php)。他们通过 cgi 搭线来完成数据传递，这样做的好处是尽量减少两者的关联，使他们变得更独立

缺点

每一次 web 请求，CGI都会有启动和退出过程，也就是最为人诟病的 fork-and-execute 模式
CGI 的一个进程则处理完一个请求后退出，下一个请求来时再创建新进程。当访问量增大，并发存在，这种方式就不适合了。于是就有了fastcgi。

FASTCGI协议

FastCG 主要是将 CGI 解释器进程保持在内存中，并接受 FastCGI 进程管理器调度

工作原理


CGI、FastCGI、PHP-FPM - 图2
1.Web Server启动时载入FastCGI进程管理器（IIS ISAPI或Apache Module)
2.FastCGI进程管理器自身初始化，启动多个CGI解释器进程(可见多个php-cgi)并等待来自Web Server的连接。
3.当客户端请求到达Web Server时，FastCGI进程管理器选择并连接到一个CGI解释器。 Web server将CGI环境变量和标准输入发送到FastCGI子进程php-cgi。
4.FastCGI 子进程完成处理后将标准输出和错误信息从同一连接返回Web Server。
当FastCGI子进程关闭连接时， 请求便处理完成。
FastCGI子进程接着等待并处理来自FastCGI进程管理器(运行在Web Server中)的下一个连接。
在CGI模式中，php-cgi在此便退出了。

CGI 与 FastCGI 比较

  • 对于 CGI 来说，每一个 Web 请求 PHP 都必须重新解析 php.ini、重新载入全部扩展，并重新初始化全部数据结构。
  • 而使用 FastCGI，所有这些都只在进程启动时发生一次。一个额外的好处是，持续数据库连接 (Persistent database connection)
  • 由于 FastCGI 是多进程，所以比 CGI 多线程消耗更多的服务器内存，php-cgi 解释器每进程消耗 7 至 25 兆内存，将这个数字乘以 50 或 100 就是很大的内存数

PHP-CGI

php-cgi是PHP的解释器；是 PHP对 Web Server 提供的 CGI 协议的接口程序
CGI 程序和 FastCGI 程序，可以理解成遵循 CGI 协议和 FastCGI 协议编写的程序
image.png

它是单进程的，一个进程处理一个请求，处理结束后进程就自我销毁。
具体执行PHP文件，解析PHP文件还是PHP-CGI来处理，

PHP-fpm可以创建多个worker进程，worker进程负责调用fastcgi程序，fastcgi可以管理多个PHP-cgi程序执行任务

PHP-FPM

PHP-FPM 的全称是 PHP FastCGI Process Manager，PHP-FPM 是 FastCGI 的实现，并提供了进程管理的功能。

进程

FastCGI 进程包含 master 进程和 worker 进程两种进程。master 进程只有一个，负责监听端口，接收 Nginx 的请求，而 worker 进程则一般有多个 (可配置)，每个进程内部都嵌入了一个 PHP 解释器，是 PHP 代码真正执行的地方。

1.master进程
php-fpm是一种多进程的模型，由一个master进程和若干worker进程组成（具体数量需要看php-fpm.conf的配置），master不会处理请求，而是fork出worker子进程去接受和处理请求
master进程的主要作用就是管理worker进程，负责fork或者kill掉子进程。在启动时根据配置文件会预先启动一定数量的php-fpm进程。当请求比较多,worker处理不过来时，master会fork新的worker进程处理。如果空闲的进程较多时，就会kill掉一些worker进程，避免占用浪费系统资源。
2.worker进程
worker进程的主要工作是处理请求,每个worker进程都会accept请求，接受成功后会解析fastcgi，然后执行脚本，完成后关闭请求，继续等待新的连接。

优点

PHP的解释器是php-cgi。php-cgi只是个CGI程序，他自己本身只能解析请求，返回结果，不会管理进程；所以就出现了一些能够调度 php-cgi 进程的程序，php-fpm 就是这样的一个东西；
它克服了 php-cgi 变更 php.ini 配置后，需重启 php-cgi 才能让新的 php-ini 生效，不可以平滑重启。直接杀死 php-cgi 进程，php 就不能运行了的问题。
php-fpm 对此的处理机制是新的 worker 用新的配置，已经存在的 worker 处理完手上的活就可以歇着了，通过这种机制来平滑过度

php-fpm 提供了更好的 php 进程管理方式，可以有效的控制内存和进程，可以平滑重载 php 配置
CGI、FastCGI、PHP-FPM - 图4

请求步骤

image.png
当客户端发送一个请求时，web server会通过一个php-fpm进程（fpm开启的worker进程）去执行php代码，php代码的执行是单线程的。

当有多个客户端同时发送请求时（并发），web server会通过php-fpm为每个请求开启一个单独进程去执行php代码。

请求执行过后，空闲的进程被销毁，内存得以释放。

但并发的问题在于，在某一时间，客户端请求让php-fpm进程数量达到了最大限制数，这个时候，新来的请求只能等待空闲的php-fpm进程来处理，这就是多进程同步阻塞模式的弊端，当然还有进程过多所带来的内存占用问题。

举例

当 web server 收到 / index.php 请求，CGI 程序和 FastCGI 程序分别是怎么处理的？

CGI：当收到 web server 请求后，会启动对应的 CGI 程序，这里就是 PHP 的解析器（php-cgi）。接下来 PHP 解析器会解析 php.ini 文件，初始化执行环境，然后处理请求，再以 CGI 规定的格式返回处理后的结果，退出进程（CGI 每次接收到请求都会执行这些步骤）

FastCGI：FastCGI 程序会先启动一个 master，解析配置环境，初始化执行环境，然后再启动多个 worker。
当请求过来时，master 会传递给一个 worker，然后立即可以接受下一个请求。这样就避免了重复的劳动，效率自然是高。而且当 worker 不够用时，master 可以根据配置预先启动几个 worker 等着；
当然空闲 worker 太多时，也会停掉一些，这样就提高了性能，也节约了资源，这就是 fastcgi 对进程的管理。

php-fpm的三种运行模式

php-fpm支持三种运行模式，分别为static、ondemand、dynamic，默认为dynamic 。
static: 静态模式，启动时分配固定的worker进程。
ondemand: ondemand: 按需分配，当收到用户请求时fork worker进程，也就是说最初系统不会启动php-fpm进程，当有连接进来时按需启动。
dynamic: 动态模式，启动时分配固定的进程。伴随着请求数增加，在设定的浮动范围调整worker进程

平滑重启

对于php.ini文件的修改，php-cgi进程是没办法平滑重启的，有了php-fpm后，就把平滑重启成为了一种可能，php-fpm对此的处理机制是新的worker用新的配置，已经存在的worker处理完手上的活就可以歇着了，通过这种机制来平滑过度的。

多进程模式

PHP从代码级别来讲不支持多线程操作，不能像Java、C#等语言一样可以编写多线程代码。多线程在解决高并发问题中所起到的作用就是使计算机的资源在每一时刻都能达到最大的利用率，不至于浪费计算机资源使其闲置。
但php是可以多进程执行的，上文所述的FPM进程管理机制就是多进程单线程的，有效提高了并发访问的响应效率。

php-cli 命令行模式

属于命令行模式，该模式不需要借助其他程序，直接在命令行就可以执行php代码，命令类似下面这样：php xxx.php
注意事项：
在命令行模式下，没有超时时间，也无法通过 set_time_limit 设置超时时间，
在命令行模式下，默认关闭 buffer 缓冲。

在普通的Web模式中，echo var_dump等输出语句/函数，默认情况下是先进入php缓冲区，等缓冲区到达一定数量，才开始传输给Web服务器。
可以通过ob等系列函数操作缓存区，例如ob_get_contents在php-cli模式下，默认是关闭buffer，直接输出。

cgi脚本：

被执行的php源代码文件。

zend虚拟机：

对php文件做词法分析、语法分析、编译成opcode，并执行。最后关闭zend虚拟机。

cgi进程/线程和zend虚拟机的关系：

cgi进程调用并初始化zend虚拟机的各种环境。

PHP-FPM+Nginx 通信

https://xie.infoq.cn/article/fa7b39c76e6556f4a23b53cc2

Nginx如何结合PHP处理动态请求：
Nginx不支持对外部程序的直接调用或者解析，所有的外部程序（包括PHP）必须通过FastCGI接口来调用。
FastCGI接口在Linux下是socket，（这个socket可以是文件socket，也可以是ip socket）。为了调用CGI程序，还需要一个FastCGI的wrapper（wrapper可以理解为用于启动另一个程序的程序），这个wrapper绑定在某个固定socket上，如端口或者文件socket。
当Nginx将CGI请求发送给这个socket的时候，通过FastCGI接口，wrapper接纳到请求，然后派生出一个新的线程，这个线程调用解释器或者外部程序（php-fpm）处理脚本并读取返回数据。
接着，wrapper再将返回的数据通过FastCGI接口，沿着固定的socket传递给Nginx；
最后，Nginx将返回的数据发送给客户端，这就是Nginx+FastCGI的整个运作过程。
image.png

PHP-FPM 和 Nginx 的通信图
image.png

步骤

（1）当 Nginx 收到 http 请求（动态请求），它会初始化 FastCGI 环境。（如果是 Apache 服务器，则初始化 mode_fastcgi 模块、如果是 Nginx 服务器则初始化 ngx_http_fastcgi_module）

（2）我们在配置 nginx 解析 php 请求时，一般会有这样一行配置：
fastcgi_pass 127.0.0.1:9000;

或者长这样：
fastcgi_pass unix:/tmp/php-cgi.sock;

它其实是 Nginx 和 PHP-FPM 一个通信载体（或者说通信方式），目的是为了让 Nginx 知道，收到动态请求之后该往哪儿发。

（3）Nginx 将请求采用 socket 的方式转给 FastCGI 主进程

（4）FastCGI 主进程选择一个空闲的 worker 进程连接，然后 Nginx 将 CGI 环境变量和标准输入发送该 worker 进程（php-cgi）

（5）worker 进程完成处理后将标准输出和错误信息从同一 socket 连接返回给 Nginx

（6）worker 进程关闭连接，等待下一个连接

Nginx配置

我本机配置了能正常解析 php 程序的 nginx 配置，介绍一下每一行配置的含义

server{
  listen 8080;
  index index.php
  root /work/html/;
  location ~ [^/]\.php(/|$)
  {
    root /work/html/;
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param PATH_INFO $fastcgi_csript_name 
    include fastcgi_params;
  }
  access_log /work/html/logs/test.log;
}
  1. 第一个大括号 server{ }：代表一个独立的 server
  2. listen 8080：代表该 server 监听 8080 端口
  3. index：默认的请求文件名
  4. root /work/html/：请求资源根目录，告诉匹配到该 location 下的 uri 到 / work/html / 文件夹下去寻找同名资源
  5. location ~ [^/].php(/|$){ }：代表一个能匹配对应 uri 的 location，用于匹配一类 uri，并对所匹配的 uri 请求做自定义的逻辑、配置。这里的 location，匹配了所有带. php 的 uri 请求，例如：http://192.168.244.128:8011/test.php/asdasd http://192.168.244.128:8011/index.php 等
  6. fastcgi_pass 127.0.0.1:9000：指定监听的地址和端口：将进入到该 location 内的 uri 请求看做是 cgi 程序，并将请求发送到 9000 端口，交由 php-fpm 处理 (php-fpm 配置中会看见它监听了此端口)
  7. fastcgi_param SCRIPT_FILENAME 转给PHP-fpm的文档路径

$fastcgi_script_name; ：这行配置意思是：动态添加了一行 fastcgi 配置，配置内容为 SCRIPT_FILENAME，告知管理进程，cgi 脚本名称。由于我的 nginx 中只有 fastcgi_params 文件，没有 fastcgi.conf 文件，所以要使 php-fpm 知道 SCRIPT_FILENAME 的具体值，就必须要动态的添加这行配置

  1. fastcgi_param PATH_INFO $fastcgi_csript_name 转给PHP-fpm的脚本名
  2. include fastcgi_params; 引入 fastcgi 配置文件

    nginx与php-fpm通信的两种方式

    在linux中，nginx服务器和php-fpm可以通过tcp socket和unix socket两种方式进行通信。

Tcp Socket 方式是 IP 加端口, 可以跨服务器；当nginx和php-fpm不在同一台机器上时，只能使用这种方式。（windows系统只能使用tcp socket的通信方式），优点就是这种方式可以做负载均衡；扩展性好

UNIX Socket 不经过网络, 没有tcp 开销；只是将应用层数据从一个进程拷贝到另一个进程，效率要比tcp socket高。
可以使同一台操作系统上的两个或多个进程进行数据通信。
只能用于 Nginx 跟 PHP-FPM 都在同一服务器的场景；需要在 nginx 配置文件中填写 php-fpm 的 pid 文件位置
不过，unix socket 高并发时不稳定，连接数爆发时，会产生大量的长时缓存，在没有面向连接协议的支撑下，大数据包可能会直接出错不返回异常。而 tcp 这样的面向连接的协议，可以更好的保证通信的正确性和完整性。

如果 nginx 做要做负载均衡的话，根本也不要考虑 unix socket 的方式了，只能采用 TCP 的方式

配置方法

tcp socket通信方式

nginx.conf 中配置：fastcgi_pass 127.0.0.1:9000;
php-fpm.conf 中配置：listen=127.0.0.1:9000;

unix socket通信方式
(php-fpm.sock 是一个文件, 由 php-fpm 生成)

nginx.conf 中配置：fastcgi_pass unix:/tmp/php-fpm.sock;
php-fpm 中配置：listen = /tmp/php-fpm.sock；

直接配置使用unix socket文件之后，会遇到access deny的问题，由于socket文件本质上还是一个文件，存在权限控制问题，默认由root用户创建，因此nginx进程无权限访问，应该配置如下命令：

; Set permissions for unix socket, if one is used. In Linux, read/write
; permissions must be set in order to allow connections from a web server. Many
; BSD-derived systems allow connections regardless of permissions.
; Default Values: user and group are set as the running user
;                 mode is set to 0660
listen.owner = www
listen.group = www 
listen.mode = 0660

可以配置nginx和php-fpm都是用www用户，这样就不会存在权限问题，当然也可以创建不同的用户，然后加入同一个组，便于分配权限。

php-fpm.conf 配置

熟悉 php-fpm 的配置，能帮助我们优化服务器性能

emergency_restart_threshold = 60
emergency_restart_interval = 60s

表示在 emergency_restart_interval 所设值内出现 SIGSEGV 或者 SIGBUS 错误的 php-cgi 进程数如果超过 emergency_restart_threshold 个，php-fpm 就会优雅重启。这两个选项一般保持默认值

process_control_timeout = 0

设置子进程接受主进程复用信号的超时时间. 可用单位: s(秒), m(分), h(小时), 或者 d(天) 默认单位: s(秒). 默认值: 0.

listen = 127.0.0.1:9000

fpm 监听端口，即 nginx 中 php 处理的地址，一般默认值即可。可用格式为: ‘ip:port’, ‘port’, ‘/path/to/unix/socket’. 每个进程池都需要设置.

request_slowlog_timeout = 10s
#当一个请求该设置的超时时间后，就会将对应的PHP调用堆栈信息完整写入到慢日志中. 设置为 ’0′ 表示 ‘Off’
slowlog = log/$pool.log.slow
慢请求的记录日志,配合request_slowlog_timeout使用

PHP 进程配置


pm
pm指的是process manager，指定进程管理器如何控制子进程的数量，它为必填项，支持3个值    
(1)static: 使用固定的子进程数量，由pm.max_children指定(可以同时存活的子进程的最大数量)
(2)dynamic：基于下面的参数动态的调整子进程的数量，至少有一个子进程(会使用下边几个配置)
pm.start_servers: 启动时创建的子进程数量，默认值为min_spare_servers + max_spare_servers - min_spare_servers) / 2
pm.min_spare_servers: 空闲状态的子进程的最小数量，如果不足，新的子进程会被自动创建
pm.max_spare_servers: 空闲状态的子进程的最大数量，如果超过，一些子进程会被杀死
(3)ondemand: 启动时不会创建子进程，当新的请求到达时才创建，有下边两个配置
pm.max_children
pm.process_idle_timeout 子进程的空闲超时时间，如果超时时间到没有新的请求可以服务，则会被杀死

区别：
如果pm设置为 static，那么其实只有pm.max_children这个参数生效。系统会开启设置数量的php-fpm进程
如果pm设置为 dynamic，那么pm.max_children参数失效，后面3个参数生效
系统会在php-fpm运行开始 的时候启动pm.start_servers个php-fpm进程，
然后根据系统的需求动态在pm.min_spare_servers和pm.max_spare_servers之间调整php-fpm进程数
还有一个比较重要的配置：
pm.max_requests
每一个子进程的最大请求服务数量，如果超过了这个值，该子进程会被自动重启。在解决第三方库的内存泄漏问题时，这个参数会很有用。默认值为0，指子进程可以持续不断的服务请求

PHP-FPM 进程池

php-fpm.conf 中默认配置了一个进程池，我们可以打开我们的 php-fpm.conf 看一下，下边是我的：

CGI、FastCGI、PHP-FPM - 图8

现在我们执行一下: ps -aux|grep php-fpm

CGI、FastCGI、PHP-FPM - 图9

会看见有一个 master，10 个 worker 进程，和我们配置的一样（www 为进程池名）

想配置多个，这样做即可：

CGI、FastCGI、PHP-FPM - 图10

在 nginx 中 fastcgi_pass 这个地方配置使用哪个进程池即可