最近有幸看到一篇文章，详细描述了CGI的进化史。虽然之前也整理过CGI、FastCGI、PHP-FPM相关的笔记，但是并没有理解其中的原理。从理解CGI的角度。CGI早期的Web应用程序非常简单。客户端通过浏览器发起请求，服务器端直接返回响应。随着互联网的发展，简单的Web应用已经不能满足开发者的需求。我们希望web服务器功能更多，发展迅速，让不同语言的开发者加入。CGI协议的诞生是Web服务器等领域的开发者在保证遵守该协议的基础上可以自由发挥其余部分，实现该协议的脚本称为CGI程序。CGI协议规定了CGI脚本需要设置的环境变量和其他一些信息。CGI程序完成某种功能，可用PHP、Python、Shell或C语言编写。在CGI之前，其他语言如果需要访问Mysql或者Memcache都需要使用C语言，但是有了CGI协议，我们的Web处理流程可以变成如下图：FastCGICGI程序的诞生有个致命的缺陷：每时客户端发起请求，服务器将请求转发给CGI，WEB服务器请求操作系统生成新的CGI解释器进程（如php-cgi），CGI进程处理完一个请求后退出，等待直到下一个请求来创建一个新进程。我们知道，要执行一个PHP程序，首先要解析php.ini文件，然后进行模块初始化等一系列工作。每次都重复这个是一种资源浪费。FastCGI协议在CGI协议的基础上做了如下改动：FastCGI旨在支持常驻（long-lived）应用进程，减少fork-and-execute带来的开销。来自Web服务器的连接，使FastCGI进程可以独立部署。FastCGI监控的服务器和套接字以消息的形式发送环境变量和其他数据。我们把实现FastCGI协议的程序称为FastCGI程序。FastCGI程序的交互方式如下图所示显示：PHP-FPMFastCGI程序的诞生已经很不错了，但是我们的要求总是有点苛刻，它还有一些明显的缺点：当我们更改配置文件时(php.ini),php-cgi(FastCGIprogram)无法顺利重启。我们fork的进程数与请求量成正比。请求繁忙时，fork进程较多。php-cgi的动态调整还没有做。上面提到的php-cgi实现的FastCGI问题还没有正式解决。三方帮我们解决了，就是php-fpm。无需依赖php-cgi即可独立运行。也就是说，它自己实现了FastCGI协议，支持进程平滑重启，具有进程管理功能。进程包括两类进程：master进程和worker进程。master进程只有一个，负责监听端口和接收来自WebServer的请求，而worker进程一般有多个（具体数量根据实际需要配置），每个进程内嵌一个PHP解释器进程，这是真正的PHP代码。执行地点。参考链接FromCGItoFastCGItoPHP-FPM
