Nginx的处理HTTP的11个阶段
Nginx的处理HTTP的11个阶段
Nginx处理HTTP请求的11阶段如下图所示:
![](https://blog.hanstary.com/file/49.png)
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
这个阶段进行日志的处理