Nginx 是如何处理每一个请求的

最新推荐文章于 2024-05-29 10:56:01 发布

雜貨鋪老闆

最新推荐文章于 2024-05-29 10:56:01 发布

阅读量493

点赞数

分类专栏： nginx 文章标签： nginx

nginx 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

基于名字的虚拟主机
Nginx 首先会决定哪个服务器应该处理这次请求。我们先以一个简单的配置看起，这里三个虚拟主机都监听到端口 *:80：

[plain] view plain copy print ?

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;
...
}

在这一配置中，Nginx 仅仅根据请求头中的 "Host" 属性来决定将把当前请求路由到哪台服务器。如果该属性的值没有匹配到任意一台主机名，或者当前请求压根就没有包含这一属性，那么 Nginx 会将当前请求路由到这一端口的默认服务器。在上面的配置中，默认服务器是第一个 - 这是 Nginx 的标准默认行为。当然，也可以在 listen 指令中使用 default_server 参数来显式指定默认服务器：

[plain] view plain copy print ?

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

default_server 参数自 0.8.21 版本起开始生效。在早期版本中应该使用 default 参数。
如何防止处理没有定义主机名的请求

如果不允许头中没有 "Host" 属性的请求，可以定义 server 以丢弃这些请求：

[plain] view plain copy print ?

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

这里，server 名被设置为空串，这将匹配没有 “Host” 头的请求，之后一个特殊的非标准的 HTTP 码 444 会在关闭连接的同时返回。

自版本 0.8.48 起，这是 server 名的默认设置，因此可以忽略 server_name "" 的写法。在早期版本中，机器的主机名会被用作默认的 server 名。

基于名字和基于 IP 的混合的虚拟主机
我们继续看一下复杂一些的配置，这里虚拟主机监听不同地址：

[plain] view plain copy print ?

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 指令。然后，Nginx 继续检测当前请求的 "Host" 属性是否匹配 server 块的 server_name 入口。如果服务器名没有找到，当前请求会被默认服务器处理。例如，一个端口 192.168.1.1:80 接收到的关于 www.example.com 的请求会被默认的 192.168.1.1:80 端口服务器处理，比如，第一台服务器，因为没有找到这一端口定义的 www.example.com。
上面说明过，默认服务器参数是监听端口的一个属性，可以针对不同端口定义不同的默认服务器：

[plain] view plain copy print ?

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;
...
}

一个简单地 PHP 站点配置
我们看一下 Nginx 是如何为一个典型而又简单的 PHP 站点的请求选择定位的：

[plain] view plain copy print ?

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 首先会找出最匹配前缀的位置，而不会考虑其出现顺序。在上面的配置中，唯一匹配前缀 location 的是 “/”，因为其可以匹配任何请求，它将被用作最后一个选择。然后 Nginx 会检查配置文件中一一列出的正则表达式。第一个匹配的表达式会停止查找并使用这一 location。如果没有任何正则表达式匹配这一请求，Nginx 会使用前面找到的最准确的前缀表达式 location。
注意所有 location 匹配测试只使用请求的 URI 部分，而不使用参数部分。这是因为请求串中的参数可以以多种方式给出，例如：

[plain] view plain copy print ?

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

此外，一些人会使用以下请求串添加任何东西：

[plain] view plain copy print ?

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

现在我们看一下以上配置下的请求是如何被处理的：

一个 “/logo.gif” 的请求首先会被 “/” 匹配，然后被正则表达式 “\.(gif|jpg|png)$” 匹配，因此，它将被后一个 location 处理。使用指令 “root /data/www”，这一请求会被映射到文件 /data/www/logo.gif，然后文件被发送给客户端。
一个 “/index.php” 的请求也会先被 “/” 匹配，然后被正则表达式 “\.(php)$” 匹配。因此，它将被后一个 location 处理，这一请求会被传递给一个监听到 localhost:9000 的 FastCGI 服务器。fastcgi_param 指令设置 FastCGI 参数 SCRIPT_FILENAME 为 “/data/www/index.php”，FastCGI 将执行该文件。$document_root 变量等同于 root 指令的值，$fastcgi_script_name 变量等同于请求 URI，比如，“/index.php”。
一个 “/about.html” 的请求会仅仅被 location “/” 匹配，因此，它将被这一 location 处理。使用指令 “root /data/www”，这一请求会被映射到 /data/www/about.html 文件，这一文件会被发送给客户端。
处理一个 “/” 的请求有些复杂。它只会被前缀 location “/” 匹配，因此，它将由这一 location 处理。然后 index 指令会根据 “root /data/www” 指令检测 index 文件的存在。如果 /data/www/index.html 文件不存在，并且 /data/www/index.php 文件存在，然后这一指令会进行一个内部重定向到 “/index.php”，然后 Nginx 会再次寻找 location 对其进行匹配，就像这一请求时被一个客户端请求的一样。正如我们上面看到的，这一重定向请求将会最终被 FastCGI 服务器处理。

原文链接： http://nginx.org/en/docs/http/request_processing.html。