做为web服务器,能根据不同的url进行不同的处理算是nginx的一大主要功能,而这种路由选择都是通过配置文件中的location来完成的。这一节我们就来看看location是如何工作的。

我是T型人小付,一位坚持终身学习的互联网从业者。喜欢我的博客欢迎在csdn上关注我,如果有问题欢迎在底下的评论区交流,谢谢。


文章目录

  • 基本格式
  • 两种匹配方式
  • 前缀字符
  • 正则表达式
  • 匹配优先级
  • 实际操作验证
  • 关于url结尾的/
  • 总结


基本格式

首先来看看默认配置是怎么样的

server {
        listen       80 default_server;
        listen       [::]:80 default_server;
        server_name  _;
        root         /usr/share/nginx/html;

        # Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;

        location / {
        }

        error_page 404 /404.html;
            location = /40x.html {
        }

        error_page 500 502 503 504 /50x.html;
            location = /50x.html {
        }
    }

location字段位于server字段中,在该server中起到路由的作用,语法规则如下

location [ = | ~ | ~* | ^~ ] url { ... }

location关键字后面接一个可选的修饰符,在后面接匹配条件,最后是一个大括号里面放要执行的动作。

一个server字段中可以有多个location字段,请求进来以后nginx会按照一定的优先级顺序去对这些location进行匹配,最后按照最优匹配的动作去执行。

如果没有特别指明动作,就是将请求的路径附加在root配置后面,返回对应的静态资源。

两种匹配方式

上面的基本语法中的url有两种写法,一种是前缀字符(prefix string),另一种是正则表达式(regular expression)。

前缀字符

当请求的url中的路径部分,也就是ip和端口后面开始的那部分,以location中定义的前缀开始的话,就认为满足匹配。


例如有如下配置

location /some/path/ {
    #...
}

那么当请求的路径为/some/path/xiaofu.mp3的时候就满足匹配,但是如果请求的路径为/some/other/path/xiaofu.mp3的话就不满足匹配

正则表达式

~来表示区分大小写的正则表达式,用~*来表示不区分大小写的正则表达式。

下面的这个配置就表示请求的url中任意位置包含.html或者.htm都满足匹配

location ~ \.html? {
    #...
}

匹配优先级

上面一共有四种修饰符,我们知道了~~*是用于正则表达式的,还有两个有是干嘛的呢?

这就涉及到匹配的优先级了。

=表示精确匹配,^~表示最佳匹配,两者都对应前缀字符匹配规则,看了下面的匹配顺序就了解它们俩是干嘛用的了。

  1. 首先尝试匹配所有的前缀字符规则,以最长的重合为最优匹配
  2. 如果有=对应的精确匹配满足,也就是说请求的路径和匹配规则完全相同,就直接用精确匹配的行为,不继续进行其余任何匹配了
  3. 如果有的话,保存最长重合的前缀字符匹配。如果最长重合的前缀字符匹配有^~装饰符,不再查找正则匹配规则,按最长前缀匹配的行为
  4. 依次进行正则匹配,以第一个匹配的为最优匹配。正则匹配的优先级高于前缀字符匹配,直接使用该正则匹配的行为
  5. 如果没有满足条件的正则匹配,使用前面保存的最长前缀匹配的行为
  6. 如果前缀符号和正则都没有匹配,返回404

基于以上的匹配顺序,可以有下面的一些实际操作建议

  • 将频繁访问的路径用=来做精确匹配,可以大量节约匹配时间
  • 因为正则匹配是从前往后按照第一个为准,所以正则匹配的前后顺序很重要,通常是越细致的越靠前

实际操作验证

说了这么多,来上手实际操作一下。

修改配置如下

location = / {
    return 601;
}       
            
location / {
    return 602;
}

location /user/ {
    return 603;
}

location ^~ /images/ {
    return 604;
}

location ~* \.(gif|jpg|jpeg)$ {
    return 605;
}

这里我没有准备实际的返回资源,而是用5各不同的返回码来区分匹配结果。

测试下语法正确性

(base) [root@ai-therm ~]# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

然后重新载入一下配置

(base) [root@ai-therm ~]# systemctl reload nginx

从另一台机器上进行curl测试。

如果直接访问/,会因为精确匹配而不再继续往下,返回601

root@control-plane-1:~# curl -I 172.29.56.178/
HTTP/1.1 601 
Server: nginx/1.16.1
Date: Sat, 30 May 2020 16:20:55 GMT
Content-Length: 0
Connection: keep-alive

如果访问/user/xiaofu.mp3会因为没有合适的正则匹配而采用最长前缀批匹配返回603

root@control-plane-1:~# curl -I 172.29.56.178/user/xiaofu.mp3
HTTP/1.1 603 
Server: nginx/1.16.1
Date: Sat, 30 May 2020 16:26:34 GMT
Content-Length: 0
Connection: keep-alive

如果访问/user/xiaofu.jpg就会因为正则匹配优先级更高而返回605

root@control-plane-1:~# curl -I 172.29.56.178/user/xiaofu.jpg
HTTP/1.1 605 
Server: nginx/1.16.1
Date: Sat, 30 May 2020 16:26:38 GMT
Content-Length: 0
Connection: keep-alive

如果访问/images/xiaofu.jpg就会因为最佳匹配而忽略正则匹配规则返回604

root@control-plane-1:~# curl -I 172.29.56.178/images/xiaofu.jpg
HTTP/1.1 604 
Server: nginx/1.16.1
Date: Sat, 30 May 2020 16:29:06 GMT
Content-Length: 0
Connection: keep-alive

最后如果访问/test/xiaofu.html会因为没有别的匹配而只能进行/匹配返回602

root@control-plane-1:~# curl -I 172.29.56.178/test/xiaofu.html
HTTP/1.1 602 
Server: nginx/1.16.1
Date: Sat, 30 May 2020 16:33:55 GMT
Content-Length: 0
Connection: keep-alive

关于url结尾的/

  • 如果是location中的匹配规则,后面是否加/没有任何影响
  • 如果是请求的url中路径的根目录,例如http://1.2.3.4http://1.2.3.4/是没有区别的,因为浏览器会默认帮我们加上这个/
  • 非根目录下的/有无影响较大。例如http://1.2.3.4/some/path/会去/some/path/目录下寻找默认文件进行返回,而http://1.2.3.4/some/path则会去/some/目录下返回名叫path的文件,如果找不到才会在末尾再加上/进行重定向继续查找/some/path/目录下的默认文件

总结

  • 先进行前缀字符串匹配,再进行正则匹配。但是正则匹配优先级更高。
  • 前缀字符串按照最长匹配选择最优匹配,而正则按照先后顺序选择最优匹配。所以正则匹配规则要注意先后顺序,越精细的越靠前
  • 对于频繁访问的url,使用精确匹配=来加快返回速度