Nginx Http 模块介绍(上)
本部分将详细介绍 中对 Http请求的 11 个处理阶段,分成 3 个小节讲解并进行相关实验操作。
1. http 请求 11 个处理阶段介绍
将 Http 请求分成多个阶段,以模块为单位进行处理。其将 Http请求的处理过程分成了 11 个阶段,各个阶段可以包含任意多个 Http 的模块并以流水线的方式处理请求。这 11 个 Http 阶段如下所示:
typedef enum {NGX_HTTP_POST_READ_PHASE = , NGX_HTTP_SERVER_REWRITE_PHASE, NGX_HTTP_FIND_CON_PHASE, NGX_HTTP_REWRITE_PHASE, NGX_HTTP_POST_REWRITE_PHASE, NGX_HTTP_PREACCESS_PHASE, NGX_HTTP_ACCESS_PHASE, NGX_HTTP_POST_ACCESS_PHASE, NGX_HTTP_TRY_FILES_PHASE, NGX_HTTP_CONTENT_PHASE, NGX_HTTP_LOG_PHASE } ngx_http_phases;
网上有人做了非常形象的,如下图所示。我们可以看到 11 个阶段的处理顺序,以及每个阶段中涉及到的相关模块以及模块之顺序。
POST_READ 阶段是 接收到 Http 请求完整头部后的处理阶段,这里主要使用的是 realip 模块的真实地址,方便后续对该 IP 进行限速或者过滤其请求等。
SERVER_REWRITE 和后面的 REWRITE 阶段一般是使用 rewrite 模块 Http请求的 uri,实现请求的控制。
FIND_CON 阶段只是做 location 的匹配项。
PREACCESS、ACCESS 和 POST_ACCESS 是和 Http 请求访问权限相关的阶段。PREACCESS 阶段是在连接之前的访问控制, 这个阶段有 limit_conn 和 limit_req 等模块工作。ACCESS 阶段是能不能访问,比如根据、密码限制访问(auth_basic 模块)、根据 ip 限制访问(access 模块)以及第三方模块认证限制的访问(auth_request模块)。POST_ACCESS 是在 ACCESS 之后的一些工作。
TRY_FILES 阶段为访问资源而设置的。有时候又称之为 PRECONTENT 阶段,即在 CONTENT 阶段之前做的事情。主要是 try_files 模块在此阶段工作。
最重要的 CONTENT 是处理 Http 请求的阶段,大部分 HTTP 模块介入这个阶段,比如 index、autoindex、concat 以及反向代理的模块都是生效的。
LOG 是处理完请求后的日志记录阶段,如 access_log 模块。
Tips: 所有的 Http请求必须都是从上到下,接阶段执行的。
2. realip 模块
realip 模块是在 postread 阶段生效的,它的作用是:当本机的 处于反向代理的后端时到真实的 ip。 如果没有 realip 模块, 中的 $remote_addr 可能就不是客户端的真实 ip 了,而是代理主机的 ip。
realip模块的配置实例如下:
set_real_ip_from .; # real_ip_recursive off; real_ip_recursive on; real_ip_header X-Forwarded-For;
set_real_ip_from 是指定我们信任的后端代理服务器,real_ip_header 是告诉 真正的 ip 是存在 X-Forwarded-For 请求头中的。
当 real_ip_recursive 设置为 off 时, 会把 real_ip_header 指定的 Http头中的最后 ip 当成真实 ip;
而当 real_ip_recursive 为 on 时, 会把 real_ip_header 指定的 Http头中的最后不是信任服务器的 ip (前面设置的set_real_ip_from)当成真实 ip。通过这样的手段,最后拿到的真实 ip。
3. rewrite 模块
rewrite 模块可以看到它在 SERVER_REWRITE 和 REWRITE 阶段都有介入。rewrite 模块的主要是改写请求的 uri。它是 认安装的模块。rewrite 模块会根据正则匹配重写 uri,然后发起内部再匹配 location, 或者直接做30x返回客户端。rewrite 模块的指令有 break, if, return, rewrite, set 等,这些都是我们常用到的。
: return code [text];# return code URL;# return URL;Default: —Context: server, location, if
return 指令返回后,Http 请求将在 return 的阶段终止,后续阶段将无法进行,所以许多模块得不到执行。
return 200 "hello, world"
: rewrite regex replacement [flag];Default: --Context: server, location, if
1、将 regex 指定的 url 替换成 replacement 这个新的 url,可以使用正则表达式及变量。
2、当 replacement 以 http:// 或者 https:// 或者 $schema 开头,则直接返回 302
3、替换后的 url 根据 flag 指定的方式进行处理
last: 用 replacement 这个 url 进行新的 location 匹配
break: break 指令停止当前脚本指令的执行
redirect:返回 302
permanent: 返回
: if (condition) { ... }Default: — Context: server, location
if 指令的条件表达式:
检查变量是否为空或者为 0
将变量与字符串做匹配,使用 = 或者 !=
将变量与正则表达式做匹配:
~ 或者 !~ 大小写敏感
~* 或者 !~* 大小写不敏感
是否存在 -f 或者 !-f
检查目录是否存在 -d 或者 !-d
、目录、软是否存在 -e !-e
是否为可执行 -x 或者 !-x
if ($request_medthod = POST){ return ;}if($invalid_refer){ return ;}
4. location 匹配
location 匹配是在 FIND_CON 阶段进行的,我们需要掌握 location 的匹配规则和匹配顺序。
“=” 精准匹配,如果匹配成功,则停止其他匹配
普通字符串指令匹配,优先级是从长到短(匹配字符越多,则选择该匹配结果)。匹配成功的location如果使用^~,则停止其他匹配(正则匹配)
正则表达式指令匹配,按照里的顺序(从上到下),成功就停止其他匹配
如果正则匹配成功,使用该结果;否则使用普通字符串匹配结果
有简单总结如下:
(location =) > (location 完整路径) > (location ^~ 路径) > (location ,* 正则顺序) > (location 部分起始路径) > (location /)
即:
(精确匹配)> (最长字符串匹配,但完全匹配) >(非正则匹配)>(正则匹配)>(最长字符串匹配,不完全匹配)>(location)
5. 实验
realip 模块认没有被编译进 的,我们需要在源码编译阶段使用–with-http_realip_module,将 realip 模块编译进来后方可使用。接下来,我们做个简单测试,首先准备 server 块如下:
server {listen 8007;server_name localhost;set_real_ip_from 218.19.206.164;real_ip_recursive off;# real_ip_recursive on;real_ip_header X-Forwarded-For;location / { return 200 "client real ip: $remote_addr\n";}}
首先,我们将 real_ip_recursive 设置为 off,然后做一次请求:
$ curl -H "X-Forwarded-For: 1.1.1.1,218.19.206.164" http://主机ip:8007 client real ip: 218.19.206.164
这里返回的是头部参数 X-Forwarded-For 中最后 ip,如果将 real_ip_recursive 设置为 on,此时,由于 set_real_ip_from 中设置218.19.206.164为信任的方向代理 ip,那么 会往前找一位,认为 1.1.1.1 是的真实ip。
$ ./ -s reload $ curl -H "X-Forwarded-For: 1.1.1.1,218.19.206.164" http://主机ip: client real ip: .
我们写简单配置如下:
server {server_name return_and_if.test.com;listen ;root html;# 到.html,根路径由root指令指定error_page /.html;# return 405 '405 Not Allowed!\n';location / { if ( $request_method = POST ) { return "Post Request!\n"; }}}
先测试if指令,当请求为 POST 时,我们能得到 ‘post request!’ 这样的字符串。GET 请求时候,针对 情况,会到/.html,我们准备 .html ,里面写上’, forbidden!’ 这一行,开始下面的 Http 请求:
$ curl -XPOST http://180.76.152.113:8008 Post Request!$ curl http://180.76.152.113:8008/a.txt , forbidden!
如果我们打开 return 405 这行指令,则 error_page 将不会生效,连同后面的 location 匹配也不会生效。无论我们发送如何请求,都会返回405的信息。这是因为 server 中的 return 指令是在 SERVER_REWRITE中执行的,而 location 匹配则是在下阶段 FIND_CON 中执行的,所以上阶段在 return 后,根本不会进入后面的阶段执行。
$ curl http://180.76.152.113:8009 405 Not Allowed!
首先,我们准备环境,首先是新建目录 third(全路径为/root/test/third),再该目录下新建 3.txt, 里面只有一行 ‘hello, world’。接下来,我们准备 server 块,加到 Http 指令块中:
server { server_name rewrite.test.com; listen 8009; # 打开rewrite日志,可以看到对应的rewrite结果 rewrite_log on; error_log logs/rewrite_error.log notice; root /root/test/; location /first { rewrite /first/(.*) /second/$1 last; return 200 'first!'; } location /second { rewrite /second/(.*) /third/$1 break; # rewrite /second/(.*) /third/$1; return 200 'second!'; } location /third { return 200 'third!'; }}
上述配置中,要打开 rewrite_log指令,这样我们可以看到 rewrite 指令的相应日志,方便查看结果。
当我们在 /second 配置中,使用 break 时,请求命令:
$ curl http://主机ip:8009/first/3.txt hello, world
如果是不使用 break 标识,则请求结果如下:
$ curl http://主机ip:8009/first/3.txt second!
首先是 /first/3.txt 请求在 /first 中匹配,并被替换为 /second/3.txt, last 标识表示将继续进行匹配,在 /second 中,uri 又被 rewrite 成 /third/3.txt, 如果后面跟了 break 标识,表示 rewrite 到此结束,不会执行后面的 return 指令,直接请求静态资源 /third/3.txt,得到其’hello, world’;如果是没有 break 标识,则会在执行 return 指令后直接返回,并不会继续执行下去,最后返回’second!'字符串。
server { server_name location.test.com; listen 8010; location = / { return 200 "精确匹配/"; } location ~* /ma.*ch { return 200 "正则匹配/ma.*ch"; } location ~ /mat.*ch { return 200 "正则匹配/match.*"; } location = /test { return 200 "精确匹配/test"; } location ^~ /test/ { return 200 "前缀匹配/test"; } location ~ /test/he*o { return 200 "正则匹配/test/he*o"; } location / { return 200 "/"; }}
我们按照这样的 location 规则,进行匹配实验,结果如下:
# 精确匹配优先级最高$ curl http://localhost:8010/ 精确匹配/ $ curl http://localhost:8010/test 精确匹配/test# 前缀匹配优先级高于正则匹配$ curl http://180.76.152.113:8010/test/heeo 前缀匹配/test# 正则匹配,按照顺序依次匹配,如果同时匹配两个正则,则前面的优先匹配$ curl http://180.76.152.113:8010/matxxch 正则匹配/ma.*ch# 什么都匹配不到时,最后匹配/$ curl http://180.76.152.113:8010/xxxxx /
6. 小结
这里介绍了 处理 Http 请求的 11 个阶段,并重点介绍了 前三个阶段POST_READ、REWRITE以及FIND_CON以及这些阶段中涉及到的模块和指令。前面讲到的指令都是 中的高频指令,必须要熟练掌握。