1. 一般web服务器接受到浏览器的请求时，如果是静态资源的话就直接将其返回给浏览器，如果是动态资源的话那就没有现成的资源返回了，那这个时候cgi就出场了
2. cgi可以理解为一种协议or一类处理程序，就是动态去生成文件，从程序上来理解就是web服务器exec这样一个进程，然后交给他一些输入参数，他就慢慢的处理完后把结果返回给web服务器，那从协议层面来说cgi协议就是规范了web服务器和cgi程序的一些输入输出参数的含义
3.所以可以有很多不同的cgi程序，别可以执行php脚本的or可以执行python脚本的，只要符合这类规范就能供web服务器调用，当然它的缺点就是每次都需要去启动这个cgi程序，这会使得处理速度很慢
4.针对这种缺陷加以改进就成了fastcgi，同样的他也可以理解为一种协议or一个程序，它跟cgi的不同就是不需要每次去exec，它会事先启动起来，作为一个cgi的管理服务器存在，预先启动一系列的子进程来等待处理，然后等待web服务器发过来的请求，一旦接受到请求就交由子进程处理，这样由于不需要在接受到请求后启动cgi，会快很多。
5.phpfpm是php对fastcgi的一种具体实现，它的启动后会创建多个cgi子进程，然后主进程负责管理子进程，同时它对外提供一个socket，那web服务器当要转发一个动态请求时只需要按照fastcgi协议要求的格式将数据发往这个socket的就可以了，那phpfpm创建的子进程去争抢这个socket连接，谁抢到了谁处理并将结果返回给web服务器，那phpfpm主进程干什么了？比方说其中一个子进程异常退出了怎么办，那phpfpm会去监控他一旦发现一个cgi子进程就会又启动一个，还有其他诸多管理功能
6 phpfpm作为一个独立的进程存在 通过socket与nginx建立连接，而mod_php 是作为一个模块被加载进了apache服务器，同时他们两作为cgi调度管理器，他们对其管理的方式也不一样
通俗的可以把服务器看作餐厅，用户请求看作来用餐的顾客，服务器处理请求看作解决顾客的就餐问题（响应输出一份饭）。
服务器上静态资源看作已做好的饭，只要放到餐盒里就可以返回给顾客，动态资源需要厨房大厨现成做份再放到餐盒里返回给顾客。
mod_php这个大厨有个特点，看见有顾客进门就点火，不管顾客要不要现做的，有点浪费资源
php_fpm这个大厨有好多小弟一直点着火（多个处理进程），等有顾客说要现做，大厨就安排小弟做份返回给客户
cgi也是个大厨，不过他等到顾客要现做，他才点火，做饭，然后熄火。等待下一个要现做的到来
fastcgi呢就是个大厨雇了一帮小弟，专门做需要现场做的饭，大厨只管分派任务，小弟真正操锅做饭
这个问题可以分两个层面讨论：
1. PHP 解释器是否嵌入 Web 服务器进程内部执行
mod_php 通过嵌入 PHP 解释器到 Apache 进程中，只能与 Apache 配合使用，而 cgi 和 fast-cgi 以独立的进程的形式出现，只要对应的Ｗeb服务器实现 cgi 或者 fast-cgi 协议，就能够处理 PHP 请求。
mod_php 这种嵌入的方式最大的弊端就是内存占用大，不论是否用到 PHP 解释器都会将其加载到内存中，典型的就是处理CSS、JS之类的静态文件是完全没有必要加载解释器。
2. 单个进程处理的请求数量
mod_php 和 fast-cgi 的模式在每个进程的生命周期内能够处理多个请求，而 cgi 的模式处理一个请求就马上销毁进程，在高并发的场景下 cgi 的性能非常糟糕。
综上，如果对性能有极高的要求，可以将静态请求和动态请求分开，这时 Nginx + php-fpm 是比较好的选择。
PS: cgi、fastcgi 通常指 Web 服务器与解释器通信的协议规范，而 php-fpm 是 fastcgi 协议的一个实现。