麦都-平台开发组

Nginx处理php的步骤 处理请求的流程

写作时间:2018-05-07

nginx配置文件 

location ~ .*\.(php|php5)?$
    {
        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,最终响应发送给客户端。