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以及这些阶段中涉及到的模块和指令。前面讲到的指令都是 中的高频指令，必须要熟练掌握。
602392714
清零编程群