httpd的几种模型和FastCGI

这里重复下httpd的几种模型：

单进程阻塞模型：

   在有多个请求到达web服务器时，第一个进入的请求被接受后，在web进行发起系统调用期间，

   web进程始终是被阻塞(不可中断睡眠)的。只有在第一个请求被响应完成后，才会接受第二个请求。

   效率极其低下。

prefork模型：

   多进程模型，web服务启动后会有一个以root身份启动的主进程，然后生成多个空闲的以Apache

   身份(RHEL的RPM包安装版本)启动的工作子进程。

   当多个请求达到web服务器后，主进程只是负责派发某个空闲工作进程去响应。

   这种模型使用select机制(I/O复用器的一种，替代linux内核去监控进程I/O的完成情况)。

   但正是由于使用select机制，默认在超过1024个请求后，CPU就会将大量时间用于切换进程，

   这就大大浪费了CPU资源，且由于进程间的内存是不共享的，所以会非常占用内存。

worker模型：

   多进程多线程模型，web服务启动后，生成一个root身份启动的主进程和多个以apache身份的

   启动的工作进程。

   在请求到达时，主进程同样负责派发工作进程去响应请求。工作进程接受请求后，会生成多个

   线程去实际的相应请求。

   好处是：内存被共享。但是面对大量请求时，CPU仍然在忙于切换，而且资源争用现象明显。

   所以在实际工作中并不比prefork模型好，所以RHEL的默认是prework。

多线程模型：

   web服务启动后，生成一个root身份启动的主进程，和多个apache身份的工作进程。

   请求到达时，主进程负责接收请求，并将请求派发给后面的工作进程。工作进程直接向内核发起

   系统调用后，不会等待I/O的完成(也就是不会被阻塞)，而是继续去响应后面的请求。

   这种模型才采用的是AIO异步模型，所以性能最好。如果主机有多个CPU核心，可以将工作进程

   绑定在固定的cpu核心上，这样可以大量减少上下文的切换。

CGI模块：

   如果客户端请求包含动态请求，那么httpd进程还需要启动一个其他进程，在得到数据后，还需要

   负责将刚刚启动进程销毁。这样就增加了httpd进程的负担。

   CGI模块就是将动态内容的执行放到了httpd内部来启动和销毁，这样虽然方便了动态内容的执行

   降低了进程管理上的复杂度，但是CPU在I/O的消耗上仍然没有减少，反而使得httpd自身臃肿了。

FastCGI：

   这是一种C/S架构的协议。FastCGI是服务器端，而web服务器则是客户端。

   FastCGI是工作在后端的一个服务器进程，它能够为特定的动态内容的执行提供环境，

   它将自己的功能注册在某个套接字(IP:port)上面，用来接受和响应httpd前端的请求。

   由于FastCGI与httpd之间是通过网络进行通信的，所以如果访问量过大时，可以讲FastCGI进程

   独立放到一个主机上，这就做分层。而当单台FastCGI扛不住压力时，仍然可以增加多台。

   就像单台httpd主机扛不住时，就会使用DNS进程负载均衡。

   

   FastCGI的工作模式类似于httpd的prefork模型，也会生成一个主进程和多个工作进程。

   平时会FastCGI会准备几个空闲工作进程备用，但请求增多时，也会增加工作进程。

   在响应完httpd的请求后，其工作进程是否销毁是受FastCGI控制的，而不是httpd。

   FastCGI在httpd2.2版本中需要手动编译，而在2.4版本中可以直接支持。

   由于是基于事件进程驱动的，所以需要安装libevent。