Nginx关于Rewrite执行顺序详解.docx

最新推荐文章于 2024-02-21 19:58:24 发布
最新推荐文章于 2024-02-21 19:58:24 发布 · 129 阅读 · 0
文章标签：

#nginx #rewrite #break flag #last flag #url-rewriting

本文深入解析Nginx的Rewrite模块，详细阐述了break和last的区别以及Rewrite指令的执行顺序。通过实验演示，帮助理解在不同配置下Rewrite指令是如何依次执行的，特别关注了last和break标记如何阻止后续指令执行及对URI的影响。

 

Nginx 关于 Rewrite 执行顺序详解

第一篇： break 和 last 的区别

Rewrite 模块概述

REFER:   http://wiki.nginx.org/NginxHttpRewriteModule#rewrite

 

If the directives of this module are given at the server level, then they are carried out before the location of the request is determined. If in that selected location there are further rewrite directives, then they also are carried out. If the URI changed as a result of the execution of directives inside location, then location is again determined for the new URI.

This cycle can be repeated up to 10 times, after which Nginx returns a 500 error.

Rewrite（ URL 重写）指令可以出现在 server{} 下，也可以出现在 location{} 下，它们之间是有区别的！对于出现在 server{} 下的 rewrite 指令，它的执行会在 location 匹配之前；对于出现在 location{} 下的 rewrite 指令，它的执行当然是在 location 匹配之后，但是由于 rewrite 导致 HTTP 请求的 URI 发生了变化，所以 location{} 下的 rewrite 后的 URI 又需要重新匹配 location ，就好比一个新的 HTTP 请求一样（注意由 location{} 内的 rewrite 导致的这样的循环匹配最多不超过 10 次，否则 nginx 会报 500 错误）。总的来说，如果 server{} 和 location{} 下都有 rewrite ，依然是先执行 server{} ，然后进行 location 匹配，如果被匹配的 location{} 之内还有 rewrite 指令，那么继续执行 rewrite ，同时因为 location{} 内的 rewrite 改变了 URI ，那么重写后的结果 URI 需要当做一个新的请求，重新匹配 location （应该也包括重新执行 server{} 下的 rewrite 吧）。

Last 与 break flag 的区别

关于 last flag 和 break flag 的区别，官方文档的描述是：“ last - completes processing of rewrite directives, after which searches for corresponding URI and location ”和“ break - completes processing of rewrite directives ”，都有“不让继续执行后面的 rewrite 指令”的含义，但是两者的区别并没有展开。

这里我用实验来告诉大家区别。实验准备：

1、  安装 nginx ；（如果对安装和 location 不了解的，请参考： http://eyesmore.iteye.com/blog/1141660 ）

 

2、  在 nginx 安装目录的 html 子目录下创建 4 个文件，分别叫： aaa.html ， bbb.html ， ccc.html 和 ddd.html ，文件内容分别是各自的文件名（例 aaa.html 文件内容不妨写 aaa html file ）。

3、  Nginx 配置文件初始化是：

 

error_log  logs/error.log info;  #URL 重写模块的日志会写入此文件

 

   server {

        listen       9090;

        server_name  localhost;

        root html;

        rewrite_log on;   # 打开 URL 重写模块的日志开关，以便写入 error_log

   

        location  /aaa.html {

            rewrite "^/aaa\.html$"  /bbb.html;

            rewrite "^/bbb\.html$"  /ddd.html;

        }  

   

        location  /bbb.html {

            rewrite "^/bbb\.html$" /ccc.html;

        }  

}

上述配置注意两点： 1 、打开 rewrite 模块的日志开关，以便 rewrite 执行日志写入 error_log （注： rewrite 日志写入 error_log 的级别是 notice ，所以要注意 error_log 日志级别，此处用 info ）； 2 、定义了两个 location ，分别是 /aaa.html 和 /bbb.html ，但是在 /aaa.html 中，把 /aaa.html 重写成 /bbb.html ，接着又把 /bbb.html 重写成 /ddd.html ；在 /bbb.html 中，把 /bbb.html 重写成 /ccc.html 。

 

[ 测试 1] 没有 last 和 break 标记时：请求 aaa.html

[root@web108 ~]# curl http://localhost:9090/aaa.html

ddd html file

[root@web108 ~]#

Error_log 的日志内容：

2011/08/07 22:13:23 [notice] 9066#0: *85 "^/aaa\.html$" matches "/aaa.html" , client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/07 22:13:23 [notice] 9066#0: *85 rewritten data: "/bbb.html" , args: "", client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/07 22:13:23 [notice] 9066#0: *85 "^/bbb\.html$" matches "/bbb.html" , client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/07 22:13:23 [notice] 9066#0: *85 rewritten data: "/ddd.html" , args: "", client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/07 22:13:23 [info] 9066#0: *85 client 127.0.0.1 closed keepalive connection

 

URL 重写模块的日志告诉我们：对于一个 HTTP 请求“ GET /aaa.html ”，重写过程是：先 /aaa.html 被重写为 /bbb.html ；然后 rewritten data: /bbb.html ，继续执行后面的 rewrite 指令，进而被重写为 /ddd.html ，然后 rewrittern data: /ddd.html 后面没有重写了（其实此时 /ddd.html 需要再次重新匹配 location 的，只是日志没有体现出来，接下来的测试 2 会体现这点），于是输出 /ddd.html 的内容。

 

[ 测试 2] 使用 last 标记时：请求 aaa.html

将上述 location /aaa.html {} 修改成：

location  /aaa.html {

       rewrite "^/aaa\.html$"  /bbb.html   last ;

      rewrite "^/bbb\.html$"  /ddd.html;

}  

 

测试结果：

[root@web108 ~]# curl http://localhost:9090/aaa.html

ccc html file

[root@web108 ~]#

 

Error_log 日志：

2011/08/07 22:24:31 [notice] 18569#0: *86 "^/aaa\.html$" matches "/aaa.html" , client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/07 22:24:31 [notice] 18569#0: *86 rewritten data: "/bbb.html" , args: "", client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/07 22:24:31 [notice] 18569#0: *86 "^/bbb\.html$" matches "/bbb.html" , client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/07 22:24:31 [notice] 18569#0: *86 rewritten data: "/ccc.html" , args: "", client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/07 22:24:31 [info] 18569#0: *86 client 127.0.0.1 closed keepalive connection

 

不知道读者看到 GET /aaa.html 显示的结果“ ccc html file ”会不会惊讶：“为什么结果不是 bbb html file ”。下面解释下整个过程：首先 /aaa.html 匹配了 location /aaa.html {} ，于是执行 rewrite "^/aaa\.html$"  /bbb.html last ，把 /aaa.html 重写为 /bbb.html ，同时由于 last flag 的使用，后面的 rewrite 指令（指的是 rewrite "^/bbb\.html$"  /ddd.html ）不会被执行。似乎此时应该输出“ bbb html file ”才对，但是我们看看 nginx 官方解释：“ last - completes processing of rewrite directives, after which searches for corresponding URI and location ”意思是说 last 不再匹配后面的 rewrite 指令，但是紧接着需要对重写后的 URI 重新匹配 location 。让我们再看看官方的“ If the directives of this module are given at the server level, then they are carried out before the location of the request is determined. If in that selected location there are further rewrite directives, then they also are carried out. If the URI changed as a result of the execution of directives inside location, then location is again determined for the new URI. This cycle can be repeated up to 10 times, after which Nginx returns a 500 error. ”因此，重新匹配的时候，匹配到了新的 location /bbb.html {} ，执行“ rewrite "^/bbb\.html$" /ccc.html ”，最后的内容是“ ccc html file ”。

 

[ 测试 3] 使用 break 标记时：请求 aaa.html

将上述 location /aaa.html {} 修改成使用 break 标记：

location  /aaa.html {

      rewrite "^/aaa\.html$"  /bbb.html  break ;

      rewrite "^/bbb\.html$"  /ddd.html;

}  

测试结果：

[root@web108 ~]# curl http://localhost:9090/aaa.html

bbb html file

[root@web108 ~]#

 

日志结果：

2011/08/07 22:37:49 [notice] 21069#0: *89 "^/aaa\.html$" matches "/aaa.html" , client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/07 22:37:49 [notice] 21069#0: *89 rewritten data: "/bbb.html" , args: "", client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/07 22:37:49 [info] 21069#0: *89 client 127.0.0.1 closed keepalive connection

 

我想这个结果不用多做解释了，充分体现了 break 和 last 的区别：“ last - completes processing of rewrite directives, after which searches for corresponding URI and location ”和“ break - completes processing of rewrite directives ”。 Break 和 last 都能阻止继续执行后面的 rewrite 指令，但是 last 如果在 location 下用的话，对于重写后的 URI 会重新匹配 location ，但是 break 则不会重新匹配 location 。简单的说， break 终止的力度比 last 更加彻底（为了记忆的方便，我们可以把重新后的 URI 重新匹配 location 理解为“ URI 匹配 location 的循环语句的下一次迭代”，高级程序设计里面 break 一般用做退出循环，所以 break 不仅终止继续执行 rewrite ，而且退出 URI 重新匹配 location 的循环迭代）。

 

 

 

 

Nginx 关于 Rewrite 的迭代 第二篇

例题 1

配置：

error_log  logs/error.log info;

 

server {

        listen       9090;

        server_name  localhost;

        root html;

        rewrite_log on;

 

        rewrite "^/aaa\.html$"  /bbb.html;

 

        location  /ccc.html {

            rewrite "^/ccc\.html$"  /eee.html;

        }

 

        location  /bbb.html {

            rewrite "^/bbb\.html$" /ccc.html;

            rewrite "^/ccc\.html$" /ddd.html;

        }  

}   

结果：

[root@web108 ~]# curl http://localhost:9090/aaa.html

ddd html file

[root@web108 ~]#

 

日志：

2011/08/08 10:05:41 [notice] 31592#0: *90 "^/aaa\.html$" matches "/aaa.html" , client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/08 10:05:41 [notice] 31592#0: *90 rewritten data: "/bbb.html" , args: "", client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/08 10:05:41 [notice] 31592#0: *90 "^/bbb\.html$" matches "/bbb.html" , client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/08 10:05:41 [notice] 31592#0: *90 rewritten data: "/ccc.html" , args: "", client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/08 10:05:41 [notice] 31592#0: *90 "^/ccc\.html$" matches "/ccc.html" , client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/08 10:05:41 [notice] 31592#0: *90 rewritten data: "/ddd.html" , args: "", client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/08 10:05:41 [notice] 31592#0: *90 "^/aaa\.html$" does not match "/ddd.html" , client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/08 10:05:41 [info] 31592#0: *90 client 127.0.0.1 closed keepalive connection

 

解释：

GET /aaa.html 请求，首先执行 server 级的 rewrite 指令，被重写为 /bbb.html ，然后匹配到 location /bbb.html {} ，接着执行 location 级的 rewrite 指令，先重写为 /ccc.html ，再重写为 /ddd.html ；由于 URI 被 location 级的 rewrite 指令重写了，因此需要重新进行 location 的匹配，相当于重写后的 URI 被当做一个新的请求，会重新执行 server 级的 rewrite ，然后重新匹配 location ，日志“ 2011/08/08 10:05:41 [notice] 31592#0: *90 "^/aaa\.html$" does not match "/ddd.html" , client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090" ”体现了重新匹配 location 的流程。

 

例题 2

配置：

error_log  logs/error.log info;

 

server {

        listen       9090;

        server_name  localhost;

        root html;

        rewrite_log on;

 

        rewrite "^/aaa\.html$"  /bbb.html;

                   rewrite "^/ccc\.html$"  /ddd.html;

        

        location  /bbb.html {

            rewrite "^/bbb\.html$" /ccc.html;

        }  

                   location  /ddd.html {

             rewrite "^/ddd\.html$" /eee.html;

        }

}   

结果：

[root@web108 ~]# curl http://localhost:9090/aaa.html

eee html file

[root@web108 ~]#

 

日志：

2011/08/08 10:21:00 [notice] 2218#0: *91 "^/aaa\.html$" matches "/aaa.html" , client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/08 10:21:00 [notice] 2218#0: *91 rewritten data: "/bbb.html" , args: "", client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/08 10:21:00 [notice] 2218#0: *91 "^/ccc\.html$" does not match "/bbb.html" , client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/08 10:21:00 [notice] 2218#0: *91 "^/bbb\.html$" matches "/bbb.html" , client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/08 10:21:00 [notice] 2218#0: *91 rewritten data: "/ccc.html" , args: "", client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/08 10:21:00 [notice] 2218#0: *91 "^/aaa\.html$" does not match "/ccc.html" , client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/08 10:21:00 [notice] 2218#0: *91 "^/ccc\.html$" matches "/ccc.html" , client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/08 10:21:00 [notice] 2218#0: *91 rewritten data: "/ddd.html" , args: "", client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/08 10:21:00 [notice] 2218#0: *91 "^/ddd\.html$" matches "/ddd.html" , client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/08 10:21:00 [notice] 2218#0: *91 rewritten data: "/eee.html" , args: "", client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/08 10:21:00 [notice] 2218#0: *91 "^/aaa\.html$" does not match "/eee.html" , client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/08 10:21:00 [notice] 2218#0: *91 "^/ccc\.html$" does not match "/eee.html" , client: 127.0.0.1, server: localhost, request: "GET /aaa.html HTTP/1.1", host: "localhost:9090"

2011/08/08 10:21:00 [info] 2218#0: *91 client 127.0.0.1 closed keepalive connection

 

解释：

第一次迭代 location 匹配

GET /aaa.html ，首先执行 server 级的重写，“ rewrite "^/aaa\.html$"  /bbb.html ”把 /aaa.html 重写为 /bbb.html ，但 /bbb.html 没匹配上“ rewrite "^/ccc\.html$"  /ddd.html ”，最终保留 /bbb.html ；接着，匹配 location /bbb.html {} ，执行 location 级的 rewrite 指令，把 /bbb.html 重写为 /ccc.html ，由于 URI 被 location 级 rewrite 重写，因此需要重新迭代 location 匹配。

 

第二次迭代 location 匹配

对于第一次迭代结果 /ccc.html ，首先依然是执行 server 级的 rewrite 指令，“ rewrite "^/aaa\.html$"  /bbb.html; ”跟 /ccc.html 不匹配，但“ rewrite "^/ccc\.html$"  /ddd.html; ”把 /ccc.html 重写为 /ddd.html ； server 级 rewrite 执行完后，接着 location 匹配， /ddd.html 匹配到 location /ddd.html {} ，执行 location 级的 rewrite 指令，把 /ddd.html 重写为 /eee.html 。同样由于 URI 被 location 级的 rewrite 指令重写，于是需要重新迭代 location 匹配。

 

第三次迭代 location 匹配

对于第二次迭代结果 /eee.html ，首先依然执行 server 级的 rewrite 指令，“ rewrite "^/aaa\.html$"  /bbb.html; ”和“ rewrite "^/ccc\.html$"  /ddd.html; ”，只不过它们都没匹配上 /eee.html ，接着 /eee.html 进行 location 匹配，也没有，最终结果是 /eee.html ，返回“ eee html file ”页面。

 

 

最后说明下，如果把上述配置修改成server级rewrite和location的编辑顺序调整：

server {
        listen       9090;
        server_name  localhost;
        root html;
        rewrite_log on;

              
        location  /bbb.html {
            rewrite "^/bbb\.html$" /ccc.html;
        }  
        location  /ddd.html {
            rewrite "^/ddd\.html$" /eee.html;
        }

 

        rewrite "^/aaa\.html$"  /bbb.html;
        rewrite "^/ccc\.html$"  /ddd.html;
}

结果是不会受影响的，也就是说location匹配迭代总是先执行server级rewrite，再进行location匹配，再执行location级的rewrite，如果URI因location级rewrite指令重写，则需要进行下一次迭代。但总的迭代次数不超过10次，否则nginx报500错误。

 

简单伪代码描述下rewrite执行过程：

 

boolean match_finish = false;
int match_count = 0;
while(!match_finish && match_count < 10) {
        match_count ++;
    （1）按编辑顺序执行server级的rewrite指令；
    （2）按重写后的URI匹配location；
    （3）
        String uri_before_location = uri;
        按编辑顺序执行location级的rewrite指令；
        String uri_after_location = rewrite(uri);
        if(uri_before_location != uri_after_location) {
            match_finish = false;           
        } else {
            match_finish = true;
        }
        if(location rewrite has last flag) {
            continue;//表示不执行后面的rewrite，直接进入下一次迭代
        }
        if(location rewrite has break flag) {
            break;//表示不执行后面的rewrite，并退出循环迭代
        }
}
if(match_count <= 10) {
    return HTTP_200;
} else {
    return HTTP_500;
}

nginx-location配置技术详解.docx
07-18
除了基础的location匹配外，nginx配置中还包括重写规则（ReWrite），这些规则允许根据特定的条件对URL进行改写。在重写规则中，可以使用不同的flag来控制重写的动作和行为，如“last”表示继续处理后续的location...
nginx rewrite
微光
07-26 2954
rewrite功能就是，使用nginx提供的全局变量或自己设置的变量，结合正则表达式和标记位实现URL重写以及重定向。 比如：更换域名后需要保持旧的域名能跳转到新的域名上、某网页发生改变需要跳转到新的页面、网站防盗链等等需求。...
Nginx 关于 Rewrite 执行顺序详解
怪手大分的专栏
05-22 8324
Rewrite（ URL 重写）指令可以出现在 server{} 下，也可以出现在 location{} 下，它们之间是有区别的！对于出现在 server{} 下的 rewrite 指令，它的执行会在 location 匹配之前；对于出现在 location{} 下的 rewrite 指令，它的执行当然是在 location 匹配之后，但是由于 rewrite 导致 HTTP 请求的 URI 发生
Nginx关于location的匹配规则详解.docx
scdxmoe的专栏
12-09 407
http://eyesmore.iteye.com/blog/1141660 http://iteye.com/eyesmore/ 有些童鞋的误区 1、 location 的匹配顺序是“先匹配正则，再匹配普通”。 矫正： location 的匹配顺序其实是“先匹配普通，再匹配正则”。我这么说，大家一定会反驳我，因为按“先匹配普通，再匹配正则”解释不了大家平时习惯的按“先匹配正则，再
nginx的location配置详解
qq_35451317的博客
01-09 889
语法规则： location [=||*|^~] /uri/ { … } 1.location = 开头表示精确匹配 ^~ 开头表示uri以某个常规字符串开头，理解为匹配 url路径即可。nginx不对url做编码，因此请求为/static/20%/aa，可以被规则^~ /static/ /aa匹配到（注意是空格）。 ~ 开头表示区分大小写的正则匹配 ~* 开头表示不区分大小写的正则匹配 !和!...
Linux系统——nginx服务介绍
一坨小橙子的博客
02-21 3329
Nginx概述、nginx模块、Input/Output模型、编译安装nginx、平滑升级热升级、命令、信号、配置全局配置隐藏修改版本、修改进程、绑定cpu、PID、调整优先级、调试work进程个数、event、http（server虚拟主机、location、root和alias、）等调优
iot php源码,开源IOT-物联网系统设计方案及源码.docx
weixin_32579395的博客
03-12 571
?开源IOT-物联网系统设计方案及源码框架:PHP Laravel?jQuery (Javascript 主要用于Ajax)jQuery Mobile(可选)(我觉得我有点懒，于是从原来做的项目直接拿了出来)Bootstrap (可选) (其实没有多大实际用处，只是因为好看和jQuery Mobile一样)语言:Processing/C/C++ Arduino用?Python 如果你有Raspbe...
nginx 代理01（持续更新）
Jerry00713的博客
02-20 1553
【代码】nginx 代理（持续更新）
nginx rewrite规则怎么配置-.docx
09-26
**Nginx Rewrite规则配置详解** 在Web服务器优化和URL管理中，Nginx的Rewrite规则扮演着重要角色。它允许我们根据特定条件重写请求的URL，从而实现动态URL到静态URL的转换、URL规范化、路径重定向等。Nginx的...
Nginx 配置详解.docx
11-16
Nginx支持包括FastCGI、SSL、Virtual Host、URL Rewrite、Gzip等在内的多种功能，同时也支持众多第三方模块的扩展。 在web服务器的日常使用中，Nginx最常用的功能之一是作为Http代理和反向代理服务器。其中，反向...
Robotstudio传送链动态跟踪技术[代码]
最新发布
11-24
本文详细介绍了ABB公司推出的Robotstudio离线编程与仿真软件在传送链动态跟踪技术中的应用。文章围绕机器人对传送带上动态工件的精准识别与加工，系统讲解了动态目标识别、路径规划、同步控制与安全策略等核心技术。通过Solution2配置文件和实操视频，帮助用户掌握从仿真设计到实际部署的完整流程。内容涵盖Robotstudio基础功能、工作单元构建、动态目标识别技术实现、机器人路径规划与轨迹控制、安全策略配置与碰撞检测，以及Solution2项目文件结构与工程交付流程。适用于工业自动化与机器人开发领域的工程师和技术人员，为其提供了一套完整的传送链跟踪技术解决方案。
Redis安全漏洞全解析[项目源码]
11-24
本文详细解析了Redis未授权访问漏洞的成因、影响版本及防御措施，包括主从复制原理分析与本地靶场实战。文章首先介绍了Redis的基本概念和特点，随后深入探讨了未授权访问漏洞的成因、影响版本及防御措施。接着，详细讲解了在CentOS 7上部署Redis的步骤，包括安装准备、下载安装、服务管理和防火墙配置。文章还提供了Redis未授权访问漏洞的验证方法和演示，包括定时任务、SSH公钥写入和Web目录shell写入等利用方式。此外，还介绍了Redis主从复制机制、持久化与主从复制的关系，以及单机模拟Redis主从复制的步骤。最后，文章通过Vulfocus靶场实战演练，展示了Redis Lua沙盒绕过命令执行(CVE-2022-0543)和Redis未授权访问漏洞的利用方法。
分布式微服务企业级系统设计与实现(源码+论文)
11-24
分布式微服务企业级系统是一个基于Spring、SpringMVC、MyBatis和Dubbo等技术的分布式敏捷开发系统架构。该系统采用微服务架构和模块化设计，提供整套公共微服务模块，包括集中权限管理（支持单点登录）、内容管理、支付中心、用户管理（支持第三方登录）、微信平台、存储系统、配置中心、日志分析、任务和通知等功能。系统支持服务治理、监控和追踪，确保高可用性和可扩展性，适用于中小型企业的J2EE企业级开发解决方案。 该系统使用Java作为主要编程语言，结合Spring框架实现依赖注入和事务管理，SpringMVC处理Web请求，MyBatis进行数据持久化操作，Dubbo实现分布式服务调用。架构模式包括微服务架构、分布式系统架构和模块化架构，设计模式应用了单例模式、工厂模式和观察者模式，以提高代码复用性和系统稳定性。 应用场景广泛，可用于企业信息化管理、电子商务平台、社交应用开发等领域，帮助开发者快速构建高效、安全的分布式系统。本资源包含完整的源码和详细论文，适合计算机科学或软件工程专业的毕业设计参考，提供实践案例和技术文档，助力学生和开发者深入理解微服务架构和分布式系统实现。 【版权说明】源码来源于网络，遵循原项目开源协议。付费内容为本人原创论文，包含技术分析和实现思路。仅供学习交流使用。
STM32H743 IAP UART升级[项目源码]
11-24
本文详细介绍了基于STM32H743ZIT6微控制器的IAP（在应用编程）实现方法，通过UART接口进行固件在线升级。内容涵盖STM32H7系列内存架构解析（包括ITCM、DTCM、AXI SRAM等区域特性与地址分配）、Flash擦写操作流程（解锁-擦除-写入-上锁）、Bootloader与APP程序的设计与配置（包括MPU、RCC、串口等模块初始化），以及完整的代码实现与操作步骤。重点分析了如何通过串口接收二进制文件并写入指定Flash区域，实现安全可靠的固件更新机制，适用于工业现场设备远程升级场景。
FPGA滑动平均滤波器[可运行源码]
11-24
本文详细介绍了FPGA数字信号处理中的滑动平均滤波器及其在ASK解调系统中的应用。文章首先解释了ASK解调系统中判决门限的选择问题，指出2ASK和4ASK信号需要获取直流分量作为判决门限。随后，重点阐述了滑动平均滤波器的原理，包括其频率响应与CIC滤波器的一致性，并提供了256点滑动平均滤波器的FPGA实现代码。代码展示了如何使用寄存器移位存储数据并计算均值，同时讨论了综合器优化代码的作用。最后，文章通过仿真结果验证了滑动平均滤波器在2ASK和4ASK解调中的有效性，并指出了初始阶段数据不足可能带来的误差问题。
Nginx Rewrite规则执行顺序深度解析
首先，从标题《Nginx关于Rewrite执行顺序详解.docx》可以明确，该文档的核心内容聚焦于Nginx中Rewrite规则的执行顺序问题。这并非一个简单的语法介绍，而是涉及Nginx内部处理请求时多个阶段的复杂交互过程。理解...
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值