apache + php

1. PHP请求过程

首先在一个客户机上的游览器输入网址，比如我们的电脑里如果上网都会有一个DNS服务器，它的作用就是把根据域名解析成相应的IP地址，比如IP地址192.168.1.100，因为域名地址默认的端口是80端口，所以最终解析的地址是:http://192.168.1.100:80. 然后网络会根据这个ip地址找到他对应的服务器。这个服务器就是网站的根据地。网站的程序之类的都放在这台服务器上。这台服务器上会装很多软件。比如MYSQL，WEB服务器（apache服务器），qq等。在网上传过来的地址中还有一个端口号80.这个地址的IP部分的作用是找到这台服务器，而这个端口号的作用就是找到这台服务器上具体的应用了。因为WEB服务器的默认端口是80，所以这个地址找的就是这台服务区上的web服务器。因为我们这里主要讲php,所以我们就选择apache服务器。

        下面举例例子，如果我再客户端游览器输入地址，他会找到192.168.1.100这个服务器，然后根据端口会找到apache服务器。apache他会把它某个目录下的index.html里的代码通过URL地址在返回给客户端的游览器，然后游览器就会根据返回的代码解析成我们看到的网页内容。这是我们访问网页代码的情况。如果我们访问的是php文件呢

        例如在客户端游览器输入他也回把这个地址传送到192.168.1.100里的apache里的，apache一看你传过来的是Php文件，如果在服务器没装php的情况下，他也会把这个文件打开，把里面的代码全部在返回给客户端，但是客户端游览器他不能解析php文件。所以前台就会把这个文件代码全部显示出来，或者出现一个下载这个文件的情况。这种情况不是我们想要看到的。所以我们需要在服务器端在安装一个php服务，这样apache一看你发送过来的是php文件，它就会把这个文件先传给php程序，php程序先把这个文件进行解释。然后他返回给apache，而apache在返回给客户端。这样客户端就可以看到php文件解析后的页面效果了。

简单说就是：apache 是一个 web 服务器，php 是它附加的一个组件。当php安装到 apache 之后，apache 就认得 php 脚本语言了。

实际的配合过程：

当apache在启动之后，动态的加载了一些模块，当中如果需要处理php的请求，就有对应的mod_php5.so这个模块被动态加载，同时这个模块会做一个ap hook_config的动作，从而使得apache在启动起来之后，就通过hook技术，连带启动mod_php5.so这个模块的加载，接收客户端的php请求。php请求发送到webserver之后，通过这个模块接收了php请求，那么对应的php文件在运行的时候，通过php内核将相应内容转发给zend 引擎，zend引擎在解析处理的时候，与php的扩展层进行相应的配合处理，最终在扩展层处理完成之后，递归的交还控制权，最后由web server将处理的结果返回给客户端的浏览器。

简单就是：当客户端浏览器触发事件--->提交到apache服务器---->apache服务器判断是php程序，提交给php引擎程序--->php引擎程序解析并读取数据库生成相应的页面-->web服务器将处理好的页面返回给客户端

2. PHP在Apache中两种工作方式(CGI模式、Apache模块DLL)

这两种工作方式的区别：

在CGI模式下，如果客户机请求一个php文件，Web服务器就调用php.exe去解释这个文件，然后再把解释的结果以网页的形式返回给客户机；

而在模块化(DLL)中，PHP是与Web服务器一起启动并运行的。所以从某种角度上来说，以apache模块方式安装的PHP4有着比CGI模式更好的安全性以及更好的执行效率和速度。（目前用的基本都是这种模式）

3.Apache服务的三种工作模式：prefork worker event

Apache 2.X  支持插入式并行处理模块，称为多路处理模块（MPM）。在编译apache时必须选择也只能选择一个MPM，对类UNIX系统，有几个不同的MPM可供选择，它们会影响到apache的速度和可伸缩性。 

　　Prefork MPM : 这个多路处理模块(MPM)实现了一个非线程型的、预派生的web服务器，它是要求将每个请求相互独立的情况下最好的MPM，这样若一个请求出现问题就不会影响到其他请求。

　　这个MPM具有很强的自我调节能力，只需要很少的配置指令调整。最重要的是将MaxClients设置为一个足够大的数值以处理潜在的请求高峰，同时又不能太大，以致需要使用的内存超出物理内存的大小。

　　Worker MPM : 此多路处理模块(MPM)使网络服务器支持混合的多线程多进程。由于使用线程来处理请求，所以可以处理海量请求，而系统资源的开销小于基于进程的MPM。但是，它也使用了多进程，每个进程又有多个线程，以获得基于进程的MPM的稳定性。

　　每个进程可以拥有的线程数量是固定的。服务器会根据负载情况增加或减少进程数量。一个单独的控制进程(父进程)负责子进程的建立。每个子进程可以建立ThreadsPerChild数量的服务线程和一个监听线程，该监听线程监听接入请求并将其传递给服务线程处理和应答。

　　不管是Worker模式或是Prefork 模式，Apache总是试图保持一些备用的(spare)或者是空闲的子进程（空闲的服务线程池）用于迎接即将到来的请求。这样客户端就不需要在得到服务前等候子进程的产生。

　　Event MPM：以上两种稳定的MPM方式在非常繁忙的服务器应用下都有些不足。 Event MPM是解决这个问题的一种新模型，它把服务进程从连接中分离出来。在服务器处理速度很快，同时具有非常高的点击率时，可用的线程数量就是关键的资源限 制，此时Event MPM方式是最有效的。一个以Worker MPM方式工作的繁忙服务器能够承受每秒好几万次的访问量（例如在大型新闻服务站点的高峰时），而Event MPM可以用来处理更高负载。值得注意的是，Event MPM不能在安全HTTP（HTTPS）访问下工作。 这种MPM目前处于试验状态，他可能不能按照预期的那样工作。