关于CGI，FastCgi，php-fpm等的解释

关于CGI，FastCgi，php-fpm等的解释

php-cgi与php-fpm一样，也是一个fastcgi进程管理器；

php-cgi的问题在于:

1、php-cgi变更php.ini配置后需重启php-cgi才能让新的php-ini生效，不可以平滑重启 

2、直接杀死php-cgi进程,php就不能运行了。(PHP-FPM和Spawn-FCGI就没有这个问题,守护进程会平滑从新生成新的子进程。） 针对php-cgi的不足，php-fpm应运而生。

Fastcgi会先启一个master，解析配置文件，初始化执行环境，然后再启动多个worker。当请求过来时，master会传递给一个worker，然后立即可以接受下一个请求。

这样就避免了重复的劳动，效率自然是高。而且当worker不够用时，master可以根据配置预先启动几个worker等着；当然空闲worker太多时，也会停掉一些，这样就提高了性能，也节约了资源。这就是fastcgi的对进程的管理。

关系：
1.cgi—>Fastcgi
Nginx会传哪些数据给PHP解析器呢？url要有吧，查询字符串也得有吧，POST数据也要有，HTTP header不能少吧，好的，CGI就是规定要传哪些数据、以什么样的格式传递给后方处理这个请求的协议。
当web server(比方说Nginx)收到/index.php这个请求后，会启动对应的CGI程序，这里就是PHP的解析器。接下来PHP解析器会解析php.ini文件，

初始化执行环境，然后处理请求，再以规定CGI规定的格式返回处理后的结果，退出进程。然后web server再把结果返回给浏览器。

"PHP解析器会解析php.ini文件，初始化执行环境"，就是这里了。标准的CGI对每个请求都会执行这些步骤（不闲累啊！启动进程很累的说！），所以处理每个时间的时间会比较长。
所以Fastcgi是cgi提高性能的优化协议

2.php-cgi—>Fastcgi
PHP的解释器是php-cgi。php-cgi只是个CGI程序，他自己本身只能解析请求，返回结果，不会进程管理（皇上，臣妾真的做不到啊！）所以就出现了一些能够调度php-cgi进程的程序，

比如说由lighthttpd分离出来的spawn-fcgi。PHP-CGI是PHP自带的FastCGI管理器。

3.php-cgi—>php-fpm
php-fpm的管理对象是php-cgi
有的说，修改了php.ini配置文件后，没办法平滑重启，所以就诞生了php-fpm
是的，修改php.ini之后，php-cgi进程的确是没办法平滑重启的。php-fpm对此的处理机制是新的worker用新的配置，已经存在的worker处理完手上的活就可以歇着了，通过这种机制来平滑过度。

http://www.mike.org.cn/articles/what-is-cgi-fastcgi-php-fpm-spawn-fcgi/

http://m.lutaf.com/218.htm

https://segmentfault.com/q/1010000000256516