标签：common 交互 请求 语言 进程 做了 windows 部门 cat
不识庐山真面目，只缘身在此山中，仅仅是做php开发完成业务逻辑，可能会被困在web服务这座山里面，都不清楚这些服务的运作，相互关系，特别是如果有专门的服务器运维的话，就更加容易忽略这些东西了，今天抽时间对这些做了个总结。
在本地开发的时候因为是用的windows系统，安装集成开发环境XAMMP，点击几个启动按钮就可以进行php web开发了，傻瓜式操作当然方便，但如果完全依赖傻瓜式操作，以后就可能变成真的傻瓜了。
服务器上用的是linux系统，用的是mysql + nginx +php 来实现web服务，现在来分别看看这几个服务，然后看看这几个服务的相互关系。
nginx 和 php
nginx和php有什么关系，以及怎么关系起来的？运行一个php程序怎么通过nginx向客户端提供服务？
简单的说一下nginx，nginx是一个web服务，支持http协议，可以接收客户端的http请求，是客户端浏览请求的入口，nginx好比一个提供处理客户http请求的通讯部门。
然后来说一下php，php是一种编程语言，可以实现web应用，可以按照客户需求实时的做出各种各样的页面。把php也比作一个部分的话，php就是一个页面创作部门，但php这个部门本身不直接接受客户端的http请求。
这样一来，两者的关系就清晰了，nginx是客户http请求的出入口，接到客户请求后，转交给php部门，告诉php部门客户都需要什么样的网页，php只管按照请求解析生成对应的网页，然后交回给nginx。
以上是用比喻说明两者的大概流程关系，但是实际细节当然要复杂一些，因为要用程序语言来实现这些关系并不简单。
现实中如果有两个部门需要合作，通常需要中间对接人，那么这里的中间对接人是谁呢？这里要先提一下CGI （Common G）， CGI是实现了和web服务器通讯的标准规范（这里就是和nginx的标准规范），规范明确指出了双方交流需要给定什么参数，以及参数的格式等，遵循这套规范的脚本语言就可以和web服务器打交道了，但是打交道多的话，需要考虑效率问题，于是又对这个进行了升级，然后有了FastCGI ，目前来说效率相对高，且适合php和nginx进行对接的是php-fpm，php-fpm是 PHP（Web Application）对 Web Server 提供的 FastCGI 协议的接口程序，这里可以理解为nginx和php交流的中间人，每次nginx接到http请求后，会看一下文件名，如果发现是php文件，就按要求和php-fpm交互，把相应的参数提交过去，php-fpm接到参数后，进行对应的解析，返回成html页面，nginx接到数据后，再将数据返回。
如图所示，我的web服务器在没有人访问的情况下依然看到很多 php-fpm进程，其中第一个 php-fpm是 master process，这种感觉就像是一个老大带着一帮小弟正在待命随时准备干活一样，当nginx接到请求后，把对应的参数交给php-fpm master process，也就是他们的老大，老大接到东西后又把活交给其他php-fpm，至于为什么要再这么中转一次，是因为php没完成一次工作，都要初始话，读取配置文件，然后开工，收工，既然每次开工前的准备工作都一样，那么这样肯定会造成效率的浪费，于是就有了个 master process帮大家先把准备工作做好，然后接到请求后把任务转发给其他的php-fpm，而且可以动态的控制其他php-fpm的数量,这里我尝试kill掉几个php-fpm子进程后，发现又有新的php-fpm出来了。要调整这些进程数量，可以在php-fpm.conf进行修改优化。
标签：common 交互 请求 语言 进程 做了 windows 部门 cat
原文地址：http://www.cnblogs.com/luckylihuizhou/p/6387171.html
