原文分享自segmentfault@阴川的回答，不知道FastCgi与PHP-fpm是什么关系如有侵权请联系我删除.网上查了fastcgi和php-fpm的关系，查了快一周了，基本全部看完了。真是众说纷纭，并没有一个权威的定义。网上有人说fastcgi是一个协议，php-fpm就是实现了这个协议；有人说php-fpm是fastcgi进程的管理器，用来管理fastcgi进程；有人说php-fpm是php内核的一个补丁；有人说修改了php.弄个php-fpm出来？首先，CGI是干什么用的？CGI是为了保证web服务器传过来的数据是标准格式的，方便CGI程序的编写者。Web服务器（比如nginx）只是内容的分发者。例如，如果请求/index.html，Web服务器会在文件系统中找到这个文件并将其发送给浏览器，其中分布有静态数据。好吧，如果当前请求是/index.php，根据配置文件，nginx知道这不是一个静态文件，需要到PHP解析器去处理，那么它就简单处理请求，然后交给到PHP解析器。Nginx会将哪些数据传递给PHP解析器？必须有url、查询字符串、POST数据和HTTP标头。那么，CGI就是一个协议，规定了传输什么数据，以什么格式传递给后方处理请求。当web服务器收到/index.php的请求后，会启动相应的CGI程序，也就是PHP解析器。接下来，PHP解析器会解析php.ini文件，初始化执行环境，然后处理请求，将处理后的结果以CGI指定的格式返回，并退出进程。Web服务器然后将结果返回给浏览器。嗯，CGI是一个协议，和进程无关。那么什么是fastcgi呢？Fastcgi用于提高CGI程序的性能。提高性能，那么CGI程序的性能问题在哪里呢？“PHP解析器将解析php.ini文件并初始化执行环境”，就是这样。标准的CGI会为每个请求执行这些步骤（不累！启动过程很累！），所以每次处理的时间会比较长。这显然是不合理的！那么Fastcgi是怎么做到的呢？首先，Fastcgi会先启动一个master，解析配置文件，初始化执行环境，然后再启动多个worker。当请求进来时，master将其传递给worker，然后worker可以立即接受下一个请求。这样一来，避免了重复劳动，效率自然就高了。而当worker不够时，master可以根据配置预先启动几个worker等待；当然，当空闲的worker过多时，会停止一些，这样既提高了性能又节省了资源。这就是fastcgi的进程管理。那么PHP-FPM是什么？它是一个实现Fastcgi的程序，被PHP官方接受。众所周知，PHP的解释器是php-cgi。php-cgi只是一个CGI程序。它只能解析请求并返回结果。它不管理进程（陛下，妃子真的不行！）所以有一些程序可以调度php-cgi进程。例如，spawn-fcgi与lighthttpd分开。嗯，PHP-FPM也是这么个东西。经过长时间的发展，逐渐被大家所认可（要知道，前几年大家都在抱怨PHP-FPM稳定性差），并且越来越流行。好了，终于回到上面的问题了。网上有人说fastcgi是一个协议，php-fpm就是实现了这个协议对。有的说php-fpm是fastcgi进程的manager，用来管理fastcgi进程的pairs。php-fpm的管理对象是php-cgi。但是不能说php-fpm是fastcgi进程的manager，因为前面说fastcgi是一个协议，好像没有这个进程，即使php-fpm存在也无法管理（至少目前）。有人说php-fpm是php内核的patch，之前是对的。因为php-fpm一开始并没有包含在php内核中，所以要使用这个功能，需要找到和源码版本相同的php-fpm给内核打补丁，然后编译。后来PHP内核集成PHP-FPM后，就方便多了，直接用编译参数--enalbe-fpm就可以了。有人说修改了php.ini配置文件后，没办法顺利重启，于是php-fpm诞生了。是的，修改php.ini后，php-cgi进程无法顺利重启。php-fpm对此的处理机制是新的worker使用新的配置，现有的worker处理完手头的工作就可以休息了。通过这种机制，过渡变得平滑。还有人说PHP-CGI是PHP自带的FastCGImanager，为什么还要搞一个php-fpm呢？错误的。php-cgi只是一个解释PHP脚本的程序。
