Nginx 的 Http 模块介绍（上）
1. http 请求 11 个处理阶段介绍
Nginx 将一个 Http 请求分成多个阶段，以模块为单位进行处理。其将 Http请求的处理过程分成了 11 个阶段，各个阶段可以包含任意多个 Http 的模块并以流水线的方式处理请求。这 11 个 Http 阶段如下所示：
typedef enum {NGX_HTTP_POST_READ_PHASE = 0, NGX_HTTP_SERVER_REWRITE_PHASE, NGX_HTTP_FIND_CONFIG_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 个阶段的处理顺序，以及每个阶段中涉及到的相关模块以及模块之间的顺序。
1.1 POST_READ 阶段
POST_READ 阶段是 Nginx 接收到 Http 请求完整头部后的处理阶段，这里主要使用的是 realip 模块获取用户的真实地址，方便后续对该 IP 进行限速或者过滤其请求等。
1.2 SERVER_REWRITE 和 REWRITE 阶段
SERVER_REWRITE 和后面的 REWRITE 阶段一般是使用 rewrite 模块修改 Http请求的 uri，实现请求的控制。
1.3 FIND_CONFIG 阶段
FIND_CONFIG 阶段只是做 location 的匹配项。
1.4 PREACCESS、ACCESS 和 POST_ACCESS 阶段
PREACCESS、ACCESS 和 POST_ACCESS 是和 Http 请求访问权限相关的阶段。PREACCESS 阶段是在连接之前要做的访问控制, 这个阶段有 limit_conn 和 limit_req 等模块工作。ACCESS 阶段是解决用户能不能访问，比如根据用户名、密码限制用户访问(auth_basic 模块)、根据 ip 限制用户访问(access 模块)以及第三方模块认证限制用户的访问(auth_request模块)。POST_ACCESS 是在 ACCESS 之后要做的一些工作。
1.5 TRY_FILES 阶段
TRY_FILES 阶段为访问静态文件资源而设置的。有时候又称之为 PRECONTENT 阶段，即在 CONTENT 阶段之前做的事情。主要是 try_files 模块在此阶段工作。
1.6 CONTENT
最重要的 CONTENT 是处理 Http 请求内容的阶段，大部分 HTTP 模块介入这个阶段，比如 index、autoindex、concat 以及反向代理的模块都是在这里生效的。
1.7 LOG 阶段
LOG 是处理完请求后的日志记录阶段，如 access_log 模块。
Tips: 所有的 Http请求必须都是从上到下，一个接一个阶段执行的。
2. realip 模块
realip 模块是在 postread 阶段生效的，它的作用是:当本机的 nginx 处于一个反向代理的后端时获取到真实的用户 ip。 如果没有 realip 模块，Nginx 中的 $remote_addr 可能就不是客户端的真实 ip 了，而是代理主机的 ip。
realip模块的配置实例如下:
set_real_ip_from 10.10.10.10;# real_ip_recursive off;real_ip_recursive on;real_ip_header X-Forwarded-For;
set_real_ip_from 是指定我们信任的后端代理服务器，real_ip_header 是告诉 nginx 真正的用户 ip 是存在 X-Forwarded-For 请求头中的。
当 real_ip_recursive 设置为 off 时，nginx 会把 real_ip_header 指定的 Http头中的最后一个 ip 当成真实 ip;
而当 real_ip_recursive 为 on 时，nginx 会把 real_ip_header 指定的 Http头中的最后一个不是信任服务器的 ip (前面设置的set_real_ip_from)当成真实 ip。通过这样的手段，最后拿到用户的真实 ip。
3. rewrite 模块
rewrite 模块可以看到它在 SERVER_REWRITE 和 REWRITE 阶段都有介入。rewrite 模块的主要功能是改写请求的 uri。它是 Nginx 默认安装的模块。rewrite 模块会根据正则匹配重写 uri，然后发起内部跳转再匹配 location, 或者直接做30x重定向返回客户端。rewrite 模块的指令有 break, if, return, rewrite, set 等，这些都是我们常用到的。
3.1 return 指令
Syntax: return code [text];
# return code URL;
# return URL;
Default: —
Context: server, location, if
return 指令返回后，Http 请求将在 return 的阶段终止，后续阶段将无法进行，所以许多模块得不到执行。
return 200 "hello, world"
3.2 rewrite 指令
Syntax: 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: 返回 301 重定向
3.3 if 指令
Syntax: if (condition) { ... }
Default: —
Context: server, location
if 指令的条件表达式:
检查变量是否为空或者为 0
将变量与字符串做匹配，使用 = 或者 !=
将变量与正则表达式做匹配:
~ 或者 !~ 大小写敏感
~* 或者 !~* 大小写不敏感
检查文件是否存在 -f 或者 !-f
检查目录是否存在 -d 或者 !-d
检查文件、目录、软链接是否存在 -e !-e
是否为可执行文件 -x 或者 !-x
实例
if ($request_medthod = POST){return 405;
}if($invalid_refer){return 403;
}
4. location 匹配
location 匹配是在 FIND_CONFIG 阶段进行的，我们需要掌握 location 的匹配规则和匹配顺序。
4.1 location 匹配规则
4.2 location 匹配顺序
“=” 精准匹配，如果匹配成功，则停止其他匹配
普通字符串指令匹配，优先级是从长到短(匹配字符越多，则选择该匹配结果)。匹配成功的location如果使用^~，则停止其他匹配（正则匹配）
正则表达式指令匹配，按照配置文件里的顺序(从上到下)，成功就停止其他匹配
如果正则匹配成功，使用该结果;否则使用普通字符串匹配结果
有一个简单总结如下：
(location =) > (location 完整路径) > (location ^~ 路径) > (location ,* 正则顺序) > (location 部分起始路径) > (location /)
即：
(精确匹配）> (最长字符串匹配，但完全匹配) >（非正则匹配）>（正则匹配）>（最长字符串匹配，不完全匹配）>（location通配）
5. 实验
5.1 realip 模块使用
realip 模块默认没有被编译进 Nginx 的，我们需要在源码编译阶段使用–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，那么 Nginx 会往前找一位，认为 1.1.1.1 是用户的真实ip。
$ ./nginx -s reload
$ curl -H "X-Forwarded-For: 1.1.1.1,218.19.206.164" http://主机ip:8007
client real ip： 1.1.1.1
5.2 return 指令和 if 指令联合使用
一个简单配置如下：
server {server_name return_and_if.test.com;listen 8008;root html;# 404错误跳转到403.html页面，根路径由root指令指定error_page 404 /403.html;# return 405 '405 Not Allowed!\n';location / {if ( $request_method = POST ) {return 200 "Post Request!\n";}}
}
先测试if指令，当请求方法为 POST 时，我们能得到 ‘post request!’ 这样的字符串输出。GET 请求时候，针对 404 情况，会跳转到/403.html，我们准备一个 403.html 页面，里面写上’403, forbidden!’ 这一行内容，开始下面的 Http 请求:
$ curl -XPOST http://180.76.152.113:8008
Post Request!$ curl http://180.76.152.113:8008/a.txt
403, forbidden!
打开 return 405 这行指令，则 error_page 将不会生效，连同后面的 location 匹配也不会生效。无论我们发送如何请求，都会返回405的错误信息。这是因为 server 中的 return 指令是在 SERVER_REWRITE中执行的，而 location 匹配则是在下一个阶段 FIND_CONFIG 中执行的，所以上一个阶段在 return 后，根本不会进入后面的阶段执行。
$ curl http://180.76.152.113:8009
405 Not Allowed!
5.3 rewrite 模块使用
准备环境，首先是新建一个目录 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!'字符串。
5.4 location 匹配
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. 小结
Nginx 处理 Http 请求的 11 个阶段，并重点介绍了 前三个阶段POST_READ、REWRITE以及FIND_CONFIG以及这些阶段中涉及到的模块和指令。
![[0260].第25节：锁的不同角度分类](https://i-blog.csdnimg.cn/direct/3b051d0645ae4b6e9d9f7637d1fb7a3c.png)
