第三章路由与Rewrite使用笔记

古城微笑少年丶 2021-11-11 13:56 350阅读 0赞

## **一、路由Location的使用** ##

### **1、Location语法规则** ###

语法规则： location \[=|~|~\*|^~\] /uri/ \{… \}

首先匹配 =，其次匹配^~，其次是按文件中顺序的正则匹配，最后是交给 /通用匹配。当有匹配成功时候，停止匹配，按当前匹配规则处理请求。

<table style="margin-left:2.4pt;width:421.2pt;"> 
 <tbody> 
 <tr> 
 <td style="vertical-align:top;width:66.7pt;"> 符号 </td> 
 <td style="vertical-align:top;width:354.5pt;"> 含义 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;width:66.7pt;"> = </td> 
 <td style="vertical-align:top;width:354.5pt;"> = 开头表示精确匹配 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;width:66.7pt;"> ^~ </td> 
 <td style="vertical-align:top;width:354.5pt;"> ^~开头表示uri以某个常规字符串开头，理解为匹配 url路径即可（禁止正则匹配）。 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;width:66.7pt;"> ~ </td> 
 <td style="vertical-align:top;width:354.5pt;"> ~ 开头表示区分大小写的正则匹配 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;width:66.7pt;"> ~* </td> 
 <td style="vertical-align:top;width:354.5pt;"> ~* 开头表示不区分大小写的正则匹配 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;width:66.7pt;"> !~和!~* </td> 
 <td style="vertical-align:top;width:354.5pt;"> !~和!~*分别为区分大小写不匹配及不区分大小写不匹配的正则 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;width:66.7pt;"> / </td> 
 <td style="vertical-align:top;width:354.5pt;"> 用户所使用的代理（一般为浏览器） </td> 
 </tr> 
 </tbody> 
</table>

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70][]

匹配规则优先级如下：

*  =精准匹配命中时，停止location动作，直接走精准匹配，
 *  一般匹配（含非正则）命中时，先收集所有的普通匹配，最后对比出最长的那一条
 *  如果最长的那一条普通匹配声明为非正则，直接此条匹配，停止location
 *  如果最长的那一条普通匹配不是非正则，继续往下走正则location
 *  按代码顺序执行正则匹配，当第一条正则location命中时，停止location

**默认端口及域名配置如下**：

> listen       80;
> 
> server\_name  loc.chj.com;

**1.1、精准匹配： **

\# 精准匹配测试： [http://loc.chj.com/equal/a/b/c][http_loc.chj.com_equal_a_b_c]

\# 第1，2条虽然匹配，但第三条是精准匹配，出第三条结果

# 测试路径/equal/a/b/c
    location ~ /equal/* { # 被命中，但被下面的推断：location = /equal/a/b/c
        echo '/equal/*';
    }
    
    location /equal/a/b { # 被命中，但被下面的推断：location = /equal/a/b/c
        echo '/equal/a/b';
    }
    
    location = /equal/a/b/c { # 被命中，直接执行，不等待
        echo '/equal/a/b/c';
    }

**1.2、普通匹配测试：**

\# 普通匹配测试：[http://loc.chj.com/match/a/b/c][http_loc.chj.com_match_a_b_c]

# 第1，2条虽然匹配，第三条匹配更长，出第三条结果
    # 测试路径/match/a/b/c
    location /match/a { # 被命中，但不是最长
        return 200  "/match/a";
    }
    
    location /match/a/b { # 被命中，但不是最长
        return 200  "/match/a/b";
    }
    
    location /match/a/b/c { # 被命中，且最长
         return 200  "/match/a/b/c";
    }
    
    location /match/a/b/c/d { # 不命中
        return 200  "/match/a/b/c/d";
    }

**1.3、正则匹配覆盖普通匹配测试**

#会覆盖普通匹配，不会覆盖=和^~
    location =/re/a.js {#访问/re/a.js，不会被后面的正则覆盖
        echo 'match =';
    }
    
    location ^~ /re/a/b {#访问/re/a/b开头的路径，不会被后面的正则覆盖
        echo 'math ^~/re/a/b*';
    }
    
    location /re/a.htm {#访问/re/a.htm，会被后面的正则覆盖
        echo 'match /re/a.htm';
    }
    
    location ~ /re/(.*)\.(htm|js|css)$ {#覆盖/re/a.htm路径
        echo "cover /re/$1.$2";
    }

**1.4、正则匹配成功一条后，便不再走其它正则**

\#正则匹配成功一条后，便不再走其它正则

\#最长正则匹配是第三个，但匹配第一个后便不往下走

# 测试路径/rex/a/b/c.htm
    location ~ /rex/.*\.(htm|js|css)$ { # 覆盖/re/a.htm路径
        echo "match first";
    }
    
    location ~ /rex/a/(.*)\.(htm|js|css)$ { # 覆盖/re/a.htm路径
        echo "match second";
    }
    
    location ~ /rex/a/b/(.*)\.(htm|js|css)$ { # 覆盖/re/a.htm路径
        echo "match third";
    }
    
    ## 默认路劲：
    location / {
          root   /etc/nginx/html;
          index  c.html;
    }

### **2、path匹配过程** ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 1][]

假设http请求路径为：http://192.168.0.132:8088/mvc/index?id=2 ，匹配过程如下：

*  将整个url拆解为域名/端口/path/params
 *  先由域名/端口，对应到目标server虚拟主机
 *  path部分参与location匹配，path = path1匹配部分 + path2剩余部分

**例如：**

#后台服务原始路径：http://192.168.0.132:8088/mvc/index?id=2
    #无/，访问路径：http://pxy.chj.com/mvc/index?id=2
    location /mvc {
         #此处未关闭，传递整个路径/nginx/chj/getInfo到目标ip:port
         proxy_pass http://192.168.0.132:8088;
    }
    
    #有/，访问路径 ：http://pxy.chj.com/nginx/mvc/index?id=2
    location /nginx/mvc {#匹配路径/dynamic，剩余路径/nginx/chj/getInfo
        proxy_pass http://192.168.0.132:8088/mvc;
    }
    
    # 访问路径：http://pxy.chj.com/proxy/trc_bjcg/monitor/test1
    # 访问路径2：http://www.lawcert.com/proxy/trc_bjcg/monitor/test1
    location ^~ /proxy/trc_bjcg/{
        proxy_pass http://10.200.169.11:8080/lx-bjcg-rest/;
    }

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 2][]

进入location方法体内部流程：

*  若是静态文件处理，则进入目标目录查找文件：root指令时找path1+path2对应的文件;alias指令时找path2对应的文件
 *  若是proxy代理，则形如proxy\_pass=ip:port时转发path1+path2路径到tomcat;形如proxy\_pass=ip:port/xxx时转发path2路径到tomcat。params始终跟随转发。

**例如：**

#访问路径：http://pxy.chj.com/static/d.html
    location /static {#匹配路径/static，剩余路径/a.html
        root /etc/nginx/html/;#root声明，在html文件夹，查找/static/a.html文件
    }
    
    #访问路径：http://pxy.chj.com/target/d.html
    location /target {#匹配路径/target，剩余路径/a.html
          alias /etc/nginx/html/static/;##alias声明，在static/文件夹，查找a.html文件
    }

![20190806141415521.png][]

# **二、负载均衡upstream** #

### **1、什么是负载均衡** ###

负载均衡，英文名称为Load Balance，其意思就是分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。负载均衡的本质目的就是提高网站的吞吐量(吞(请求)、吐(响应)数量)，减轻单台服务器压力，尽可能最大化利用每个服务器的资源。

### **2、负载均衡策略** ###

负载均衡策略配置在nginx/conf/nginx.conf中，根据upstream backserver\{\}配置，注意：配置在server\{\}外面。

**1）语法格式：**

upstream 负载名 \{

\[ip\_hash;\]

server ip:port  \[weight=数字\]  \[down\];

server ip:port  \[weight=数字\];

\[\]内容为可选项

**2）轮询（默认）**

upstream order \{

server 192.168.0.128:8383;

server 192.168.244.233:8383;

不配置weight（即默认weight均为1）

每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。

**3）权重weight**

upstream order \{

server 192.168.0.128:8383 weight=3;

server 192.168.244.233:8383 weight=1 down;

指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。

down 暂时不参与负载

**4）ip\_hash**

upstream order \{

ip\_hash;

server 192.168.0.128:8383;

server 192.168.244.233:8383;

每个请求按访问ip的hash结果分配，这样同一客户端的请求总是发往同一个后端服务器，可以解决session的问题。

**5）代理时的负载使用**

格式：proxy\_pass http://负载名;

如下图，其传参到下游服务器的规则，与proxy\_pass = http://ip:port 一样

![20190807152147990.png][]

到此，负载均衡和反向代理就介绍完了。我发现很多人有一个误区，分不清楚负载均衡和反向代理的区别。负载均衡主要是针对tomcat集群，nginx根据负载均衡策略访问不同的tomcat服务器，让服务器尽可能发挥出更多性能。而反向代理主要是出于安全性考虑，只需要提供nginx的公网ip，而通过内网nginx与tomcat实现通信，这样隐藏了tomcat服务器的ip地址。

那么假设tomcat集群中，有一台服务器挂了，而nginx刚好选择了该台服务器，那么会一直请求，问题来了，通过nginx怎么解决tomcat宕机容错问题呢？

**服务器宕机轮询配置规则****：**

server {
            listen   80;
            server_name  www.nginx.cn;
            location / {
                proxy_pass  http://backserver;
                index  index.html index.htm;
                     proxy_connect_timeout 1;
                     proxy_send_timeout 1;
                     proxy_read_timeout 1;
            }
    }

加入三行代码，在访问某服务器1秒内没有响应的话，自动轮询下一台服务器。

实现tomcat服务器高可用：①当有tomcat节点挂掉时候，使用keepalived脚本重启服务器；②配置nginx服务器宕机轮询规则，超时未访问自动轮询下一台服务器；③若多次重启不成功，则通过邮件通知。

问：如果在项目发布新版本时候，怎么访问服务器？

假设有主备两台服务器，主机发布版本期间无法访问主机，那么通过配置了nginx服务器宕机容错机制，nginx则会转发给备机，当主机发布版本完成后，再更新备机项目。

问：tomcat发布版本的时候，session失效怎么解决?

由于session存放在jvm内存中，重启session失效，解决办法：把session存放在redis中。

### **3、nginx配置DDOS** ###

**限制请求次数****：**

设置Nginx、Nginx Plus的连接请求在一个真实用户请求的合理范围内。比如，如果你觉得一个正常用户每两秒可以请求一次登录页面，你就可以设置Nginx每两秒钟接收一个客户端IP的请求（大约等同于每分钟个请求）。

limit_req_zone $binary_remote_addr zone=one:10m rate=2r/s;
        server {
            ...
            location /login.html {
            limit_req zone=one;
            ...
        }
    }

\`limit\_req\_zone\`命令设置了一个叫one的共享内存区来存储请求状态的特定键值，在上面的例子中是客户端IP($binary\_remote\_addr)。location块中的\`limit\_req\`通过引用one共享内存区来实现限制访问/login.html的目的。

### **4、nginx配置防盗链** ###

location ~ .*\.(jpg|jpeg|JPG|png|gif|icon)$ {
            valid_referers blocked http://www.itcats.cn www.itcats.cn;
            if ($invalid_referer) {
                return 403;
            }
    }

nginx作为服务器的入口，所有的请求都需要经过nginx再分发给tomcat，如果有一天nginx挂了怎么办？nginx怎么实现高可用？

**什么是负载均衡高可用**

nginx作为负载均衡器，所有请求都到了nginx，可见nginx处于非常重点的位置，如果nginx服务器宕机后端web服务将无法提供服务，影响严重。为了屏蔽负载均衡服务器的宕机，需要建立一个备份机。主服务器和备份机上都运行高可用（High Availability）监控程序，通过传送诸如“I am alive”这样的信息来监控对方的运行状况。当备份机不能在一定的时间内收到这样的信息时，它就接管主服务器的服务IP并继续提供负载均衡服务；当备份管理器又从主管理器收到“I am alive”这样的信息时，它就释放服务IP地址，这样的主服务器就开始再次提供负载均衡服务。

**Nginx + Keepalived实现高可用**

正常的互联网公司都会搭建nginx一主一备，主nginx挂了，备nginx就工作了。而keepalived负责

Keepalived是什么？

keepalived是集群管理中保证集群高可用的一个服务软件，用来防止单点故障。 Keepalived的作用是检测web服务器的状态，如果有一台web服务器死机，或工作出现故障，Keepalived将检测到，并将有故障的web服务器从系统中剔除，当web服务器工作正常后Keepalived自动将web服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的web服务器。

关于Keepalived用户后续补充。。

参考：[https://blog.csdn.net/itcats\_cn/article/details/82454657][https_blog.csdn.net_itcats_cn_article_details_82454657]

# **三、rewrite使用** #

## **1、语法** ##

rewrite regex replacement \[flag\];

flag=【break/last/redirect/permanent】

regex 是正则表达式

replacement 是替换值，新值

flag -- 后续处理标识

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 3][]

location /a.html {
        echo 'I am a.html';
    }
    
    location /b.html {
        echo 'I am b.html';
    }

**1****）****flag=break**

发生nginx内部重定向，path值被更新，rewrite层面的命令会中断。原控制流程逻辑不变往下走。

例如：

#此路径请求：http://rew.chj.com/aa.html  -->  I am a.html/测试页面AAA
    location /aa.html {##内部重定向
        rewrite ^/  /a.html break;##停止指令，流程不变往下走
        rewrite ^/  /b.html break;
        root   /etc/nginx/html/;
    }

**2****）****flag=last**

发生nginx内部重定向，path值被更新，rewrite层面的命令会中断。控制流程刷新，重新进行整个location层的逻辑流程。例如：

#此路径请求：http://rew.chj.com/ab.html -->  I am a.html
    location /ab.html {
        rewrite ^/  /a.html last;##停止指令，但重新location匹配
        rewrite ^/  /b.html last;
        rewrite ^/  /c.html;
        root   /etc/nginx/html/;
    }

**3****）****flag= redirect/permanent**

发生页面重定向（301永久重定向/302临时重定向），nginx流程结束，返回http响应到浏览器，页面url更新。例如：

#此路径请求：http://rew.chj.com/bb  --> http://rew.chj.com/b.html(302)
        location /bb {
        rewrite ^/  /b.html redirect;  ##  302临时重定向
        set $aa 12;
        root   html/;
    }
    
    #此路径请求：http://rew.chj.com/ba --> http://rew.chj.com/b.html(301)
    location /ba {
        rewrite ^/  /b.html permanent;  ##301永久重定向
        root   html/;
    }

**4****）****flag为空**

发生nginx内部重定向，path值被更新，rewrite层面的命令继续。最后一个rewrite完毕，刷新控制流程，重新进行location重匹配。例如：

#此路径请求：http://rew.chj.com/cc.html -->  I am a.html
    location /cc.html {
         rewrite ^/  /c.html;##指令不停，继续往下
         rewrite ^/  /b.html;
         rewrite ^/  /a.html;##最后一条，生效的是这条
         root   /etc/nginx/html/;
    }

## **2、Nginx的内置变量** ##

常用：

*  $host：请求中的主机头(Host)字段，如果请求中的主机头不可用或者空，则为处理请求的server名称
 *  $http\_HEADER ： HTTP请求头中的内容，HEADER为HTTP请求中的内容转为小写，
 *  \-变为\_(破折号变为下划线)，例如：$http\_user\_agent(Uaer-Agent的值)
 *  $remote\_addr 客户端的IP地址。
 *  $remote\_port 客户端的端口。
 *  $request\_method 这个变量是客户端请求的动作，通常为GET或POST。
 *  $request\_uri 这个变量等于包含一些客户端请求参数的原始URI
 *  $scheme 所用的协议，比如http或者是https
 *  $server\_name 服务器名称。
 *  $server\_port 请求到达服务器的端口号。
 *  $server\_protocol 请求使用的协议，通常是HTTP/1.0或HTTP/1.1。
 *  $uri 请求中的当前URI(不带请求参数，参数位于$args)
 *  $http\_origin  浏览器携带的origin头

# **四、Nginx处理请求的11个阶段** #

Nginx 处理请求的全过程一共划分为 11 个阶段（如图），按阶段由上到下依次执行 （上一阶段的所有指令执行完毕，才进入下一阶段）

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 4][]

**各阶段的含义如下：**

*  post-read: 接收到完整的http头部后处理的阶段，在uri重写之前。一般跳过 
 *  server-rewrite: location匹配前，修改uri的阶段，用于重定向，location块外的重写指令（多次执行） 
 *  find-config: uri寻找匹配的location块配置项（多次执行） 
 *  rewrite: 找到location块后再修改uri，location级别的uri重写阶段（多次执行） 
 *  post-rewrite: 防死循环，跳转到对应阶段 
 *  preaccess:  权限预处理
 *  access: 判断是否允许这个请求进入
 *  post-access: 向用户发送拒绝服务的错误码，用来响应上一阶段的拒绝
 *  try-files: 访问静态文件资源
 *  content : 内容生成阶段，该阶段产生响应，并发送到客户端 
 *  log: 记录访问日志

### **2、示例** ###

**Nginx配置如下：**

server {
        listen 80 ;
        server_name  idx.chj.com;
        
        location / {
             root   /etc/nginx/html/static;
             index  e.html;
         }
        
        location  /test {
            set $a 100;
            echo  '$a';
            set $a 200;
            echo  '$a';
          }
    
          location /e.html {  
            echo "I am e";  
          }
    
        error_page   500 502 503 504  /50x.html;
    
        location = /50x.html {
            root   html;
        }
    }

访问[http://idx.chj.com/test][http_idx.chj.com_test]返回结果：200 200（为什么不是100 200呢？）

因为Nginx生命周期处理阶段是一个阶段处理完成才进行下一个阶段的处理，所以在server\_rewrite与rewrite循环阶段，echo $a的值会被一次循环处理，在最后读取的时候两次读取出来的结果实际上都是最后一次set值以后的结果，所以结果都为200。

# **五、下载并解压echo模块** #

### **1、下载echo-nginx-module** ###

> wget https://github.com/openresty/echo-nginx-module/archive/v0.61.tar.gz

将文件放到： /usr/local/src目录下面

解压：tar -zxf v0.61.tar.gz

### **2、增加第三方插件echo命令：** ###

进入nginx源码目录执行如下命令：

> ./configure --add-module=/usr/local/src/echo-nginx-module-0.61

编译：

> make
> 
> make install

安装编译完整后查询版本：

[root@localhost nginx-1.9.15]# nginx -V
    nginx version: nginx/1.9.15
    built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)
    configure arguments: --add-module=/usr/local/src/echo-nginx-module-0.61

注意：

有时候该模块安装完编译正常但是echo访问还是有问题，实际上是echo模块还未生效，需要强杀Nginx进程，然后重启Nginx服务。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 5][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70]: /images/20211109/f1bf802f51674ebab2cc3a3e2f4f9faa.png
[http_loc.chj.com_equal_a_b_c]: http://loc.chj.com/equal/a/b/c
[http_loc.chj.com_match_a_b_c]: http://loc.chj.com/match/a/b/c
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 1]: /images/20211109/8c9535dfe40a4377bb3b0535ea1d02dd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 2]: /images/20211109/2fdc9488f83e48a1804659ab64101fae.png
[20190806141415521.png]: /images/20211109/97fc277f950942ec9965143f4768af1a.png
[20190807152147990.png]: /images/20211109/25e9d4cf86ad41a4a6384cdba9da2231.png
[https_blog.csdn.net_itcats_cn_article_details_82454657]: https://blog.csdn.net/itcats_cn/article/details/82454657
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 3]: /images/20211109/66810af4416643e7b5ccec1c256037d6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 4]: /images/20211109/7ad33f9780b74afa8b3983784e996143.png
[http_idx.chj.com_test]: http://idx.chj.com/test
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NjYxNDU4_size_16_color_FFFFFF_t_70 5]: /images/20211109/1009b29cb3f847bfa9fe1834bea23d88.png