Nginx的处理HTTP的11个阶段

Nginx的处理HTTP的11个阶段

Nginx处理HTTP请求的11阶段如下图所示：

1.Post-Read

在这个阶段上游服务器可以通过realip模块获得客户端的真实ip。

在这个模块常用的配置如下

• set_real_ip_from:设置受信任的服务器的IP
• real_ip_header X-Forwarded-For:包含客户端真实IP的X-Forwarded-For请求头
• real_ip_recursive:
  • 若为off:就将real_ip_header指定的请求头中的最后一个IP作为客户端的真实IP
  • 若为on:就将real_ip_header指定的请求头中最后一个不受信任的服务器IP当做客户端的真实IP

注：这三个参数可以作用在配置http块、server块、location块

set_real_ip_from 1.1.1.1;
set_real_ip_from 2.2.2.2;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

2.Server-Rewrite

这个阶段主要负责虚拟服务器级别的请求URI转换

Nginx会利用rewrite指令修改server块的上下文

server{
	server_name example.com;
	rewrite ^ http://www.example.com$request_uri permanent;
}

rewrite 匹配的URI（正则表达式）重写的uri 标志位

标志位

• last:忽略后续的rewrite指令
• break:忽略后续的rewrite指令，在此处继续处理
• redirect:返回302状态码（临时重定向），会显示跳转后的地址
• permanent:返回301状态码（永久重定向），会显示跳转后的地址

关于临时重定向和永久重定向的区别，比较重要的我认为是以下两点：

• 搜索引擎处理方式 ： 搜索引擎对永久重定向和临时重定向的处理方式也有所不同。永久重定向会将旧 URL 的排名、权重和收录等指标转移到新的 URL 上，以保证网站的 SEO 和用户体验不受影响。而临时重定向不会将旧 URL 的权重转移到新的 URL 上，搜索引擎仍然会对旧 URL 进行索引。

• 浏览器的缓存行为：浏览器对永久重定向和临时重定向的缓存行为也不同。永久重定向会被浏览器缓存，下次访问时会直接跳转到新的 URL，而临时重定向不会被浏览器缓存，下次访问时仍然会访问旧的 URL。

关于last和break,这里在做一些解释：

• last:当执行 last 指令时，Nginx 会停止当前 server块内的后续处理，并在当前阶段查找其他匹配的 server 块重新进行处理。
• break: Nginx 会停止当前 server 块内的后续处理，但不会重新查找其他的 server 块，而是按照既定的流程继续执行后续的其他指令（如 location 块外的指令）。

3.Find-Config

在此阶段不会加载任何模块，nginx会按照完全匹配、最长前缀匹配和正则表达式匹配这三个规则对location块进行匹配。若为嵌套的location块进行递归查找

4.Rewrite

这个阶段与Server-Rewrite相似，他们区别在于Server-Rewrite是对于server块的跳转，而Rewrite阶段是对location块的跳转

对于Rewrite阶段的标识位

• last:忽略后续的rewrite指令,立即跳回Find-Config阶段
• break:忽略后续的rewrite指令，在此处继续处理
• redirect:返回302状态码（临时重定向），会显示跳转后的地址
• permanent:返回301状态码（永久重定向），会显示跳转后的地址

关于Rewrite阶段的last和break这里再做一些解释:

• last: 当匹配到当前 location 并执行完相关操作后，会停止在当前 location 中的处理，然后重新在 server 块中查找其他能够匹配的 location进行处理(即跳回Find-Config阶段)。
• break: 当匹配到当前 location并执行完相关操作后，停止在当前 location 中的处理，但不会重新在 server 块中查找其他能够匹配的 location ，而是直接按照当前的处理结果返回响应。

5.Post-Rewrite

由Nginx核心完成Rewrite阶段要求的“内部跳转”操作

6.Pre-Access

在这个阶段Nginx主要进行粗颗粒的访问控制

如配置限速和客户端连接数量

7.Access

这个阶段会进行Nginx会进行细颗粒度的访问控制，基本的认证方式有如下：

• ACL:ACL认证方式基于数据包的源地址、目的地址、端口号等信息进行过滤和控制。通过配置ACL规则，可以实现对网络流量的精细管理，例如允许或禁止特定IP地址或网段的访问，限制特定端口的通信等。
• HTTP基本认证:简单通俗点来讲就是用账号和密码实现访问控制
• JWT认证:通俗点讲就是，当用户登录成功后，服务器会生成一个包含用户相关信息的 JWT 令牌，这个令牌是一段经过加密处理的字符串。然后，服务器把这个令牌返回给用户。之后，用户每次向服务器发送请求时，都要在请求的头部带上这个令牌。服务器接收到请求后，会对这个令牌进行验证，确认令牌是否有效、是否被篡改以及是否过期。如果一切都没问题，服务器就知道这个用户是已经登录过并且有权进行相应的操作。
• 子请求认证: 子请求认证是对于其中的一些较小的、附属的请求进行单独的身份验证和授权的过程。 比如 就好像您要进入一个大型的活动场所，主入口检查了您的门票让您进去了。但是当您想要进入场所内的一些特殊区域，比如贵宾室或者后台，就需要再次进行单独的身份验证，这就是子请求认证。
• Lua认证: 通过在 NGINX 中集成 Lua 脚本，可以实现复杂的认证逻辑。例如，从外部数据源（如数据库、缓存或远程服务）获取用户信息来进行认证，或者根据特定的规则动态地决定是否允许访问。

8.Post-Access

在这个阶段会根据Access阶段得到的access_code进行操作

9.Pre-Content

在这个阶段会进行文件的检查，检查的上下文范围是server块和location

这里涉及try_files

try_files 文件 ... uri;

#检查$uri是否存在，不存在就执行/images/default.png
location /images/{
	try_files $uri /images/default.png;
}
#先检查$uri，再检查$uri/index.html，如果都不存在就返回404
location /{
	try_files $uri $uri/index.html $uri.html=404;
}

10.Log

这个阶段进行日志的处理