解读web服务器与php的工作原理

最近决定重读php手册（好吧，其实之前也没怎么读，尴尬脸），既然是重读，那就从php的安装开始咯，然后被手册中出现的各种新词搞懵逼了，什么cgi、fastcgi、sapi、fpm，苍天啊，这些都是什么鬼？经过一番谷歌、百度、知乎，自己总结出一点浅薄的知识，暂且记录，以后有新发现再回来填坑。

还是先简单说一下一个完整的请求过程吧。

• 首先用户点击一个链接，发起一个url请求
• web服务器会判断这是一个静态的请求，还是动态的。如果是静态的直接查找资源返回给浏览器，这里主要说一下动态的请求
• 如果是一个动态的请求，web服务器是没有能力处理的，需要交给一些后台的编程语言处理，比如说php、java、asp等等。敲黑板啦，请注意这里，web服务器像apache、nginx等都是用C语言写的，如何和不同的后端语言进行交流呢？
  
  这里就有不同的方式，按照php的流程控制，这里应该来一个switch语句或者if else语句，哈哈。

第一种：官方手册称之为handler(谷歌翻译为：处理程序)

工作流程大概是这样的，他会直接加载php模块，每一次动态的请求都会产生一个进程，但是他们两者之间还是没办法交流啊，是的，php会提供一个统一的接口sapi(Server Application Programming Interface)来和web服务器交流（至于到底是哪种接口，怎么工作的，我还不清楚，希望有大牛帮忙指点）。

这种方式有两个缺点：

（1）每一次的请求都会产生一个进程，所有如果遇到高并发的时候，就很容易死翘翘了。

（2）php和web服务器的耦合度很高，如果出现问题，很难判断到底是谁的错误。

以前没理解的一些细节：

以前我们在配置服务器的时候，让apache能够解析php代码，是这样修改httpd.conf文件的

//加载php模块
LoadModule php5_module D:/php/php5apache2_2.dll
AddType application/x-httpd-php .php

//添加index.php
<IfModule dir_module>
   DirectoryIndex index.html  index.htm index.php
</IfModule>

注意：上面的web服务器也就是apache第一个先找的文件是.html或者.htm文件为后缀的，因为这样的话就不需要和php通信了嘛，自己能办到的事就先不麻烦别人了

扯的有点远了，回来继续说第二种。

第二种：cgi的方式

cgi是sapi的一种实现方式。它的工作原理大概是这样的：web服务器要让php去处理动态请求，但是前面提到两者语言不通啊，就好比你和一个日本人交流，都听不懂对方说的话，怎么办，大家都说英语吧。这里也是一样，不过使用的是cgi。web服务器要告诉php我这边收到的HTTP header、url、post数据等，通过cgi这种标准协议，将数据传输过去，然后php通过cgi就会解析php.ini文件，初始化执行环境，处理请求。最后再通过cgi将处理的结果返回给服务器，服务器将数据返回给浏览器。

是不是一切都很完美，嗯，等等，如果遇到高并发怎么办？老兄，你可不可以快点？搞得和《疯狂动物城》里的“闪电”一样，你能不能早点把该办的事情办好，高并发来的时候可不可以多几个人手办事？

时间过了几年，“闪电”终于快退休了，出来了fastcgi。 它会和apache一起启动，启动一个master,解析配置文件，初始化执行环境，然后生成多个cgi，等待调用。一切都很完美，有一种金星完美手势的既视感。

但是童靴们，前面说过了，cgi是一种协议，fastcgi也是一种协议，它不过是比cgi要好点，但是终究改变不了本质，他自己是没有进程管理的。php-cgi是php官方自带的fastcgi管理器，但是很弱鸡呀，主要有以下两个缺点：

（1）php-cgi变更php.ini配置之后需要重启php-cgi才能让新的php-ini生效，不可以平滑重启（终于知道为什么每次更改配置文件之后要重启了）

（2）直接杀死php-cgi进程，php就不运行了。

后来php-fpm就诞生了，php-fpm能够调度php-fpmphp-cgi进程的程序，进行管理。