对与fastcgi和php-fpm以前确实不懂，但是看了<搞不清FastCgi与PHP-fpm之间是个什么样的关系>仍然有疑惑。
疑问：请求流程
在nginx收到一个GET的php请求后，以下是疑问：
nginx启用fastcgi分给一个work进程，然后这个work进程会去调用php-fpm，然后调用php-cgi来解析php请求。nginx看到是一个php请求后，直接调用php-fpm调用php-cgi来解析php请求。
上面的两种说法那一个是正确的。
两种说法都有问题。
php-fpm本身是一个fastcgi，但只是php专用的cgi。
简单理解，流程一般是这样的：nginx接收到需要解析php请求，就转发给php解析器(一般是php-fpm，如果你用其他fastcgi也可以)来处理，处理后的结果再交给nginx来返回给客户端。
先听我讲个我最近发生的故事：
最近我家里的淋浴的喷头坏掉了，我在想，是不是要换一个同样牌子的喷头才能接的上（但附近不一定能买到同样牌子的），或者要把一整套全换掉（感觉要花很多钱）。到了五金店我才发现多虑了，原来所有的喷头的接口都一样，也就是有一套统一的标准。
再说说你的问题：
FastCGI就类似上面的例子中的接口标准，或者也可以说是一个协议，它不是一个实实在在的东西，而是一套HTTP服务器（如Nginx、IIS）与编程语言（如PHP、Python、Perl）对接的标准。
PHP-FPM是PHP语言对接FastCGI的一个服务，它是一个实实在在的软件。
php-fpm是一个完全独立的程序,不依赖php-cgi,也不依赖php.因为php-fpm是一个内置了php解释器的FastCGI服务,启动时能够自行读取php.ini配置和php-fpm.conf配置.
附:PHP FastCGI进程管理器PHP-FPM的架构
一个master进程,支持多个pool,每个pool由master进程监听不同的端口,pool中有多个worker进程.
每个worker进程都内置PHP解释器,并且进程常驻后台,支持prefork动态增加.
每个worker进程支持在运行时编译脚本并在内存中缓存生成的opcode来提升性能.
每个worker进程支持配置响应指定请求数后自动重启,master进程会重启挂掉的worker进程.
每个worker进程能保持一个到MySQL/Memcached/Redis的持久连接,实现"连接池",避免重复建立连接,对程序透明.
"master进程采用epoll模型异步接收和分发请求,listen监听端口,epoll_wait等待连接,
然后分发给对应pool里的worker进程,worker进程accpet请求后poll处理连接"
上面这句有误,应该为:
master进程并不接收和分发请求,而是worker进程直接accpet请求后poll处理.
master进程不断调用epoll_wait和getsockopt是用来异步处理信号事件和定时器事件.
这里提一下,Nginx也类似,master进程并不处理请求,而是worker进程直接处理,
不过区别在于Nginx的worker进程是epoll异步处理请求,而PHP-FPM仍然是poll.
如果worker进程不够用,master进程会prefork更多进程,
如果prefork达到了pm.max_children上限,worker进程又全都繁忙,
这时master进程会把请求挂起到连接队列backlog里(默认值是511).
Nginx跟PHP-FPM分开,其实是很好的解耦,PHP-FPM专门负责处理PHP请求,一个页面对应一个PHP请求,
页面中所有静态资源的请求都由Nginx来处理,这样就实现了动静分离,而Nginx最擅长的就是处理高并发.
PHP-FPM是一个多进程的FastCGI服务,类似Apache的prefork的进程模型,
对于只处理PHP请求来说,这种模型是很高效很稳定的.