nginx 是如何处理访问请求的

nginx 是如何处理访问请求的
=========================

编译自：
http://nginx.org/en/docs/http/request_processing.html

目录：
    name-based 虚拟主机
    对于未定义 server name 的访问请求，如何防止其被处理
    混合使用 name-based 虚拟主机和 IP-based 虚拟主机
    一个简单的 PHP 站点配置示例

 

name-based 虚拟主机
-----------------------

当一个访问请求到达 nginx，nginx 会考虑选择某一个 server 处理访问请求。
咱们以一个包含三个 server 区块的配置来说解： 

   server {
        listen      80;
        server_name example.org www.example.org;
        ...
    }

    server {
        listen      80;
        server_name example.net www.example.net;
        ...
    }

    server {
        listen      80;
        server_name example.com www.example.com;
        ...
    }

这三个虚拟主机均监听于 *:80 端口。根据上面的配置，nginx 仅经过检查请求首部中的
“HOST” 字段来决定让哪一个虚拟主机处理访问请求。若是该字段的值没有匹配任何虚拟主机，
或者请求首部中没有 “HOST” 字段，nginx 会将该请求路由到 *:80 端口的默认 server。
在上面的配置中，默认 server 是第一个 server —— 这是 nginx 的标准默认行为。
咱们也能够显式指定一个默认 server，使用 listen 指令的 default_server 参数来指定，
例如：
  

 server {
        listen      80 default_server;
        server_name example.net www.example.net;
        ...
    }

    
    Note:
    default_server 参数从 0.8.21 以后开始使用，以前是 default 参数。
    
要注意，默认 server 是监听端口的一个属性，不是 server name 的属性。稍后将进一步描述这个问题。

 

对于未定义 server name 的访问请求，如何防止其被处理
--------------------------------------------

若是但愿禁止未定义 “Host” 请求首部的访问请求，可设置一个 server 用于丢弃这样的请求：

     server {
         listen      80;
         server_name "";
         return      444;
     }

咱们在这里将 server name 设置为一个空字符串，它能匹配未携带 “Host” 请求首部的访问请求，而且返回一个特殊的状态码 444 以关闭链接，444 不是标准的 nginx 状态码。

    Note:
    从 0.8.48 版开始，这个设置变成了 nginx 的默认设置，因此 server_name "" 可被删去。
    在更早的版本中，物理主机的主机名被设置为 default server name。
    

混合使用 name-based 虚拟主机和 IP-based 虚拟主机
------------------------------------------

如今咱们看一个更复杂的配置案例，这里有多个虚拟主机监听于不一样的地址：    

server {
        listen      192.168.1.1:80;
        server_name example.org www.example.org;
        ...
    }

    server {
        listen      192.168.1.1:80;
        server_name example.net www.example.net;
        ...
    }

    server {
        listen      192.168.1.2:80;
        server_name example.com www.example.com;
        ...
    }

根据这份配置，nginx 首先检查访问请求的 IP 地址和端口号，将它与 server 区块的 listen 指令
的参数进行对比，过滤掉不匹配的 server。而后 nginx 检查访问请求的 “Host” 请求首部，将它与剩下的 server 区块中的 server_name 进行对比，看可否匹配。若是没有匹配的 server，该请求将交给 default server 处理。

例如，nginx 在 192.168.1.1:80 端口接收到对于 www.example.com 的访问请求，由于在 192.168.1.1:80 端口没有匹配的 server name，这个请求最后将被交给 192.168.1.1:80 端口的 default server 处理，也就是第一个server。

正如前面提到过，default server 是监听端口的属性，因此对于不一样的监听端口，能够分别为其定义不一样的 default server。    

server {
        listen      192.168.1.1:80;
        server_name example.org www.example.org;
        ...
    }

    server {
        listen      192.168.1.1:80 default_server;
        server_name example.net www.example.net;
        ...
    }

    server {
        listen      192.168.1.2:80 default_server;
        server_name example.com www.example.com;
        ...
    }

192.168.1.1:80 端口的默认 server 是第二个 server；
192.168.1.2:80 端口的默认 server 是第三个 server。

 

一个简单的 PHP 站点配置示例
-------------------------------

最后咱们来看一个 PHP 站点的例子，看看 nginx 是如何选择 location 处理请求的： 

server {
	    listen      80;
	    server_name example.org www.example.org;
	    root        /data/www;

	    location / {
	        index   index.html index.php;
	    }

	    location ~* \.(gif|jpg|png)$ {
	        expires 30d;
	    }

	    location ~ \.php$ {
	        fastcgi_pass  localhost:9000;
	        fastcgi_param SCRIPT_FILENAME
	                      $document_root$fastcgi_script_name;
	        include       fastcgi_params;
	    }
	}

nginx 首先根据访问请求的 URI 查找匹配的定义了 prefix 前缀的 location，并记住其中匹配的最长的前缀。在上面的例子中，定义了前缀的 location 只有一个，并且前缀为 “/”，它是最短的前缀，能匹配全部请求。由于 “/” 前缀最短，因此这个 location 老是被做为最后的备选。而后 nginx 开始检查指定了正则表达式的 location，依照配置文件中的顺序依次检查是否与访问请求的 URI 匹配，当找到第一个匹配的正则表达式，nginx 再也不继续检查后面的 location，nginx 将使用找到的第一个匹配正则表达式所对应的 location。若是没有匹配的 正则表达式，nginx 将使用以前记住的拥有最长匹配前缀的 location。

要注意的是，全部类型的 location 仅测试请求的 URI 部分，不带参数。由于在查询字符串中的参数，可能以
几种方式提供：

    /index.php?user=john&page=1
    /index.php?page=1&user=john

除此以外，在查询字符串中，任何人能够请求任何事情：

    /index.php?page=1&something+else&user=john

    

如今咱们仔细研究一下根据上面的配置，nginx 将会如何处理访问请求：

• 访问请求为 “/logo.gif”。 对于 “/logo.gif” 的请求首先被 prefix location “/” 所匹配，而后被正则表达式“\.(gif|jpg|png)$” 所匹配，所以，这个请求将被交给后者处理。使用 “root /data/www” 指令，该请求被映射为 /data/www/logo.gif，这个文件被发送给客户端。

 

• 访问请求为 “/index.php”。 对于 “/index.php” 的请求一样首先被 prefix location “/” 所匹配，而后被正则表达式 “\.(php)$”所匹配。所以这个请求将被交给后者处理。该请求被转发给一个 FastCGI 服务器，该服务器监听于：localhost:9000。fastcgi_param 指令用于设置 FastCGI 参数 SCRIPT_FILENAME，这里设置为：“/data/www/index.php”，以后 FastCGI 服务器会执行该文件。$document_root 变量的值等同于 root 指令的参数值，$fastcgi_script_name 变量的值等于请求 URI，即 “/index.php”。

 

• 访问请求为 “/about.html”。对于 “/about.html” 的请求只能被 prefix location “/” 所匹配。所以该 location 会处理这个请求。使用 “root /data/www” 指令，这个请求被映射到 /data/www/about.html 文件，该文件将被发送给客户端。

 

• 访问请求为 “/”。对于 “/” 的访问请求的处理更为复杂。它只能被 prefix location “/” 所匹配，所以该 location 会处理这个请求。而后 index 指令根据本身的参数以及 “root /data/www” 指令，开始测试是否存在 index 文件。若是 /data/www/index.html 文件不存在，而 /data/www/index.php 文件存在，index 指令会将请求经过内部重定向，重定向至 “/index.php”，而后 nginx 如同接收到客户端发来对“/index.php” 的请求开始进行处理。这个处理过程刚才已经讲解过，被重定向的请求最后会被转发给 FastCGI 服务器进行处理。