Nginx处理php的步骤 处理请求的流程
2014-01-26 14:32
567 查看
nginx配置文件
以上配置是处理.php结尾的文件,也就是php文件。意思是所有以.php为结尾的文件,都送到本机9000端口由php-cgi来处理。
Nginx的模块有三种角色:
* handlers 处理http请求并构造输出
* filters 处理handler产生的输出
* load-balancers 当有多于一个的后端服务器时,选择一台将http请求发送过去
一个handler有三种返回方式:正常;错误;放弃处理转由默认的handler来处理(典型地如处理静态文件的时候)。
如果handler的作用是把请求反向代理到后端服务器,那么就是刚才说的模块的第三种角色load-balancer了。load-balancer主 要是负责决定将请求发送给哪个后端服务器。Nginx目前支持两种load-balancer模块:round-robin(轮询,处理请求就像打扑克时 发牌那样)和IP hash(众多请求时,保证来自同一ip的请求被分发的同一个后端服务器)。
如果handler返回(译者注:就是http响应,即filter的输入)正确无误,那么fileter就被调用了。每个location配置里都可以 添加多个filter,所以说(比如)响应可以被压缩和分块。多个filter的执行顺序是编译时就确定了的。filter采用了经典的“接力链表 (CHAIN OF RESPONSIBILITY)”模式:一个filter被调用并处理,接下来调用下一个filter,直到最后一个filter被调用完成,Nginx 才真正完成响应流程。
最帅的部分是在 filter链中,每个filter不会等待之前的filter完全完工,它可以处理之前filter正在输出的内容,这有一点像Unix中的管道。 Filter的操作都基于buffers_,buffer通常情况下等于一个页的大小(4k),你也可以在nginx.conf里改变它的大小。这意味 着,比如说,模块可以在从后端服务器收到全部的响应之前,就开始压缩这个响应并流化(stream to)给客户端了。好牛逼啊~ 总结一下上面的内容,一个典型的周期应当是这样的:当nginx接收到一个客户端发送 HTTP request → Nginx基于location的配置选择一个合适的handler → (如果有) load-balancer选择一个后端服务器 → Handler处理请求并顺序将每一个响应buffer发送给第一个filter → 第一个filter讲输出交给第二个filter → 第二个给第三个 → 第三个给第四个 → 以此类推 → 最终响应发送给客户端
这里如果是请求的php文件,location就会把请求送到本机9000端口由php-cgi来处理并构造输出buffer,再把buffer发送给第一个filter,一直传递到最后一个filter,最终响应发送给客户端。
location ~ .*\.(php|php5)?$ { #fastcgi_pass unix:/tmp/php-cgi.sock; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi.conf; }
以上配置是处理.php结尾的文件,也就是php文件。意思是所有以.php为结尾的文件,都送到本机9000端口由php-cgi来处理。
Nginx的模块有三种角色:
* handlers 处理http请求并构造输出
* filters 处理handler产生的输出
* load-balancers 当有多于一个的后端服务器时,选择一台将http请求发送过去
一个handler有三种返回方式:正常;错误;放弃处理转由默认的handler来处理(典型地如处理静态文件的时候)。
如果handler的作用是把请求反向代理到后端服务器,那么就是刚才说的模块的第三种角色load-balancer了。load-balancer主 要是负责决定将请求发送给哪个后端服务器。Nginx目前支持两种load-balancer模块:round-robin(轮询,处理请求就像打扑克时 发牌那样)和IP hash(众多请求时,保证来自同一ip的请求被分发的同一个后端服务器)。
如果handler返回(译者注:就是http响应,即filter的输入)正确无误,那么fileter就被调用了。每个location配置里都可以 添加多个filter,所以说(比如)响应可以被压缩和分块。多个filter的执行顺序是编译时就确定了的。filter采用了经典的“接力链表 (CHAIN OF RESPONSIBILITY)”模式:一个filter被调用并处理,接下来调用下一个filter,直到最后一个filter被调用完成,Nginx 才真正完成响应流程。
最帅的部分是在 filter链中,每个filter不会等待之前的filter完全完工,它可以处理之前filter正在输出的内容,这有一点像Unix中的管道。 Filter的操作都基于buffers_,buffer通常情况下等于一个页的大小(4k),你也可以在nginx.conf里改变它的大小。这意味 着,比如说,模块可以在从后端服务器收到全部的响应之前,就开始压缩这个响应并流化(stream to)给客户端了。好牛逼啊~ 总结一下上面的内容,一个典型的周期应当是这样的:当nginx接收到一个客户端发送 HTTP request → Nginx基于location的配置选择一个合适的handler → (如果有) load-balancer选择一个后端服务器 → Handler处理请求并顺序将每一个响应buffer发送给第一个filter → 第一个filter讲输出交给第二个filter → 第二个给第三个 → 第三个给第四个 → 以此类推 → 最终响应发送给客户端
这里如果是请求的php文件,location就会把请求送到本机9000端口由php-cgi来处理并构造输出buffer,再把buffer发送给第一个filter,一直传递到最后一个filter,最终响应发送给客户端。
相关文章推荐
- php文件网络请求流程(基于Nginx)
- PHP+FastCGI+Nginx动态请求处理配置
- Struts2中请求处理的流程步骤(转自《Struts2入门3.0》)
- PHP+FastCGI+Nginx动态请求处理配置
- Ubuntu下Nginx做前端代理Apache端口做处理PHP动态请求
- PHP处理Web请求流程分析
- PHP处理Web请求流程分析
- 解读PHP的Yii框架中请求与响应的处理流程
- LAMP架构客户端请求PHP(带有mysql)页面处理的流程
- Ubuntu下Nginx做前端调用Apache做PHP动态请求处理
- 解读PHP的Yii框架中请求与响应的处理流程
- IIS架构与HTTP请求处理流程(2)
- SpringMvc处理请求流程
- 【转】Http 请求处理流程(1)
- (转载)Http 请求处理流程
- Struts2请求处理流程及源码分析
- 备忘:Windows下php-cgi不能处理并发PHP请求
- PHP模拟发送POST请求之二、用PHP和JS处理URL信息
- SpringMVC 请求处理流程
- Asp.Net构架(Http请求处理流程)