Nginx 处理一个HTTP 请求的全过程
前面给大家讲了 Nginx 是如何处理 HTTP请求头部的 ,接下来就到了真正处理 HTTP 请求的阶段了。先看下面这张图,这张图是 Nginx 处理 HTTP 请求的示意图,虽然简单,但是却很好的说明了整个过程。
1. Read Request Headers:解析请求头。
2. Identify Configuration Block:识别由哪一个 location 进行处理,匹配 URL。
3. Apply Rate Limits:判断是否限速。例如可能这个请求并发的连接数太多超过了限制,或者 QPS 太高。
4. Perform Authentication:连接控制,验证请求。例如可能根据 Referrer 头部做一些防盗链的设置,或者验证用户的权限。
5. Generate Content:生成返回给用户的响应。为了生成这个响应,做反向代理的时候可能会和上游服务(Upstream Services)进行通信,然后这个过程中还可能会有些子请求或者重定向,那么还会走一下这个过程(Internal redirects and subrequests)。
6. Response Filters:过滤返回给用户的响应。比如压缩响应,或者对图片进行处理。
以上这七个步骤从整体上介绍了一下处理流程,下面还会再说一下实际的处理过程。
下面介绍一下详细的 11 个阶段,每个阶段都可能对应着一个甚至多个 HTTP 模块,通过这样一个模块对比,我们也能够很好的理解这些模块具体是怎么样发挥作用的。
8. POST_READ:在 read 完请求的头部之后,在没有对头部做任何处理之前,想要获取到一些原始的值,就应该在这个阶段进行处理。这里面会涉及到一个 realip 模块。
9. SERVER_REWRITE:和下面的 REWRITE 阶段一样,都只有一个模块叫 rewrite 模块,一般没有第三方模块会处理这个阶段。
10. FIND_CONFIG:做 location 的匹配,暂时没有模块会用到。
12. POST_WRITE:处于 REWRITE 之后,也是暂时没有模块会在这个阶段出现。
13. PREACCESS:是在 ACCESS 之前要做一些工作,例如并发连接和 QPS 需要进行限制,涉及到两个模块:limt_conn 和 limit_req
14. ACCESS:核心要解决的是用户能不能访问的问题,例如 auth_basic 是用户名和密码,access 是用户访问 IP,auth_request根据第三方服务返回是否可以去访问。
15. POST_ACCESS:是在 ACCESS 之后会做一些事情,同样暂时没有模块会用到。
16. PRECONTENT:在处理 CONTENT 之前会做一些事情,例如会把子请求发送给第三方的服务去处理,try_files 模块也是在这个阶段中。
17. CONTENT:这个阶段涉及到的模块就非常多了,例如 index, autoindex, concat等都是在这个阶段生效的。
以上的这些阶段都是严格按照顺序进行处理的,当然,每个阶段中各个 HTTP 模块的处理顺序也很重要,如果某个模块不把请求向下传递,后面的模块是接收不到请求的。而且每个阶段中的模块也不一定所有都要执行一遍,下面就接着讲一下各个阶段模块之间的请求顺序。
如下图所示,每一个模块处理之间是有序的,那么这个顺序怎么才能得到呢?其实非常简单,在源码 ngx_module.c 中,有一个数组 ngx_module_name ,其中包含了在编译 Nginx 的时候的 with 指令所包含的所有模块,它们之间的顺序非常关键,在数组中顺序是相反的。
"ngx_http_random_index_module",
"ngx_http_auth_request_module",
灰色部分的模块是 Nginx 的框架部分去执行处理的,第三方模块没有机会在这里得到处理。
在依次向下执行的过程中,也可能不按照这样的顺序。例如,在access 阶段中,有一个指令叫 satisfy,它可以指示当有一个满足的时候就直接跳到下一个阶段进行处理,例如当 access 满足了,就直接跳到 try_files 模块进行处理,而不会再执行 auth_basic、auth_request 模块。
在 content 阶段中,当 index 模块执行了,就不会再执行 auto_index 模块,而是直接跳到 log 模块。
下面开始详细讲解一下各个阶段。先来看下第一个阶段postread 阶段,顾名思义,postread 阶段是在正式处理请求之前起作用的。
postread 阶段,是11 个阶段的第 1 个阶段,这个阶段刚刚获取到了请求的头部,还没有进行任何处理,我们可以拿到一些原始的信息。例如,拿到用户的真实 IP 地址
我们知道,TCP 连接是由一个四元组构成的,在四元组中,包含了源 IP 地址。而在真实的互联网中,存在非常多的正向代理和反向代理。例如最终的用户有自己的内网 IP 地址,运营商会分配一个公网 IP,然后访问某个网站的时候,这个网站可能使用了 CDN 加速一些静态文件或图片,如果 CDN 没有命中,那么就会回源,回源的时候可能还要经过一个反向代理,例如阿里云的 SLB,然后才会到达 Nginx。
我们要拿到的地址应该是运营商给用户分配的公网 IP 地址 115.204.33.1,对这个 IP 来进行并发连接的控制或者限速,而 Nginx 拿到的却是 2.2.2.2,那么怎么才能拿到真实的用户 IP 呢?
l X-Forwardex-For 是用来传递IP 的,这个头部会把经过的节点 IP 都记录下来
l X-Real-IP:可以记录用户真实的 IP 地址,只能有一个
例如 binary_remote_addr、remote_addr 这样的变量,其实就是真实的 IP,这样做连接限制也就是 limit_conn 模块才有意义,这也说明了,limit_conn 模块只能在 preaccess 阶段,而不能在 postread 阶段生效。
l 默认不会编译进 Nginx需要通过 --with-http_realip_module 启用功能
l 变量:如果还想要使用原来的 TCP 连接中的地址和端口,需要通过这两个变量保存realip_remote_addr realip_remote_port
l 指令set_real_ip_from指定可信的地址,只有从该地址建立的连接,获取的 realip 才是可信的real_ip_header指定从哪个头部取真实的 IP 地址,默认从 X-Real-IP 中取,如果设置从 X-Forwarded-For 中取,会先从最后一个 IP 开始取real_ip_recursive换回地址,默认关闭,打开的时候,如果X-Forwarded-For 最后一个地址与客户端地址相同,会过滤掉该地址
Syntax: set_real_ip_from address | CIDR | unix:;
Context: http, server,location
Syntax: real_ip_header field | X-Real-IP | X-Forwarded-For | proxy_protocol;
Default: real_ip_header X-Real-IP;
Context: http, server,location
Syntax: real_ip_recursive on | off;
Default: real_ip_recursive off;
Context: http, server, location
上面关于 real_ip_recursive 指令可能不太容易理解,我们来实战练习一下,先来看 real_ip_recursive 默认关闭的情况:
关于如何编译 Nginx,详见: https://iziyang.github.io/2020/03/10/1-nginx/
./configure --prefix=自己指定的目录 --with-http_realip_module
#屏蔽默认的 nginx.conf 文件的 server 块内容,并添加一行
include /Users/mtdp/myproject/nginx/test_nginx/conf/example/*.conf;
# 在 example 目录下建立 realip.conf,set_real_ip_from 可以设置为自己的本机 IP
server_name ziyang.realip.com;
error_log /Users/mtdp/myproject/nginx/nginx/logs/myerror.log debug;
set_real_ip_from 192.168.0.108;
real_ip_header X-Forwarded-For;
return 200 "Client real ip: $remote_addr\n";
在上面的配置文件中,我设置了可信代理地址为本机地址,real_ip_recursive 为默认的 off,real_ip_header 设为从 X-Forwarded-For 中取。
➜ test_nginx curl -H 'X-Forwarded-For: 1.1.1.1,192.168.0.108' ziyang.realip.com
然后再来测试 real_ip_recursive 打开的情况:
server_name ziyang.realip.com;
error_log /Users/mtdp/myproject/nginx/nginx/logs/myerror.log debug;
set_real_ip_from 192.168.0.108;
real_ip_header X-Forwarded-For;
return 200 "Client real ip: $remote_addr\n";
➜ test_nginx curl -H 'X-Forwarded-For: 1.1.1.1,2.2.2.2,192.168.0.108' ziyang.realip.com
所以这里面也可看出来,如果使用X-Forwarded-For 获取 realip 的话,需要打开 real_ip_recursive ,并且,realip 依赖于 set_real_ip_from 设置的可信地址。
那么有人可能就会问了,那直接用 X-Real-IP 来选取真实的 IP 地址不就好了。这是可以的,但是 X-Real-IP 是 Nginx 独有的,不是 RFC 规范,如果客户端与服务器之间还有其他非 Nginx 软件实现的代理,就会造成取不到 X-Real-IP 头部,所以这个要根据实际情况来定。
首先 rewrite 阶段分为两个,一个是 server_rewrite 阶段,一个是 rewrite,这两个阶段都涉及到一个 rewrite 模块,而在 rewrite 模块中,有一个 return 指令,遇到该指令就不会再向下执行,直接返回响应。
l HTTP 1.0 标准301:永久重定向302:临时重定向,禁止被缓存
l HTTP 1.1 标准303:临时重定向,允许改变方法,禁止被缓存307:临时重定向,不允许改变方法,禁止被缓存308:永久重定向,不允许改变方法
error_page 的作用大家肯定经常见到。当访问一个网站出现 404 的时候,一般不会直接出现一个 404 NOT FOUND,而是会有一个比较友好的页面,这就是 error_page 的功能。
Syntax: error_page code ... [=[response]] uri;
Context: http, server, location, if in location
2. error_page 500 502 503 504 /50x.html;
3. error_page 404 =200 /empty.gif;
6. error_page 403 http://example.com/forbidden.html;
7. error_page 404 =301 http://example.com/notfound.html;
server_name ziyang.return.com;
19. 当 server 下包含 error_page 且 location 下有 return 指令的时候,会执行哪一个呢?
20. return 指令同时出现在 server 块下和同时出现在 location 块下,它们有合并关系吗?
l 在本机的hosts 文件中绑定 ziyang.return.com 为本地的 IP 地址
➜ test_nginx curl ziyang.return.com/text
<head><title>403 Forbidden</title></head>
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx/1.17.8</center>
这个时候可以看到,是 error_page 生效了,返回的响应是 403。
那么假如打开了 location 下 return 指令的注释呢?
➜ test_nginx curl ziyang.return.com/text
这时候, return 指令得到了执行。也就是第一个问题,当 server 下包含 error_page 且 location 下有 return 指令的时候,会执行 return 指令。
下面再看一下 server 下的 return 指令和 location 下的 return 指令会执行哪一个。
l 打开server 下 return 指令的注释,reload 配置文件
➜ test_nginx curl ziyang.return.com/text
<head><title>405 Not Allowed</title></head>
<center><h1>405 Not Allowed</h1></center>
<hr><center>nginx/1.17.8</center>
21. 当 server 下包含 error_page 且 location 下有 return 指令的时候,会执行哪一个呢?会执行 location 下的 return 指令。
22. return 指令同时出现在 server 块下和同时出现在 location 块下,它们有合并关系吗?没有合并关系,先遇到哪个 return 指令就先执行哪一个。
rewrite 指令用于修改用户传入 Nginx 的 URL。来看下rewrite 的指令规则:
Syntax: rewrite regex replacement [flag];
l 将regex 指定的 URL 替换成 replacement 这个新的 URL可以使用正则表达式及变量提取
l 当replacement 以 http:// 或者https:// 或者 $schema 开头,则直接返回302 重定向
l 替换后的URL 根据 flag 指定的方式进行处理replacement
server_namerewrite.ziyang.com;
error_loglogs/rewrite_error.log notice;
rewrite /first(.*) /second$1 last;
rewrite /redirect1(.*)$1 permanent;
rewrite /redirect2(.*)$1 redirect;
rewrite /redirect3(.*) http://rewrite.ziyang.com$1;
rewrite /redirect4(.*) http://rewrite.ziyang.com$1 permanent;
23. return 指令 与 rewrite 指令的顺序关系?
24. 访问 /first/3.txt,/second/3.txt,/third/3.txt 分别返回的是什么?
l 在本机的hosts 文件中绑定 rewrite.ziyang.com 为 127.0.0.1
首先访问 rewrite.ziyang.com/first/3.txt,结果如下:
➜ ~ curl rewrite.ziyang.com/first/3.txt
为什么结果是 second! 呢?应该是 third! 呀,可能有人会有这样的疑问。实际的匹配步骤如下:
rewrite /first(.*) /second$1 last;
下面将 rewrite /second(.*) /third$1; 这条指令加上 break flag,rewrite /second(.*) /third$1 break;
继续访问rewrite.ziyang.com/first/3.txt,结果如下:
➜ ~ curl rewrite.ziyang.com/first/3.txt
这时候返回的是 3.txt 文件的内容 test3。实际的匹配步骤如下:
rewrite /first(.*) /second$1 last;
因此,这个过程实际请求的 URL 是 rewrite.ziyang.com/third/3.txt,这样自然结果就是test3 了。你还可以试试访问 rewrite.ziyang.com/third/2.txt 看看会返回什么。
配置文件中还有 4 个 location,你可以分别试着访问一下,结果是这样的:
Context: http, server, location, if
这个指令打开之后,会把 rewrite 的日志写入 logs/rewrite_error.log 日志文件中,这是请求/first/3.txt 的日志记录:
2020/05/06 06:24:05 [notice] 86959#0: *25 "/first(.*)" matches "/first/3.txt", client: 127.0.0.1, server: rewrite.ziyang.com, request: "GET /first/3.txt HTTP/1.1", host: "rewrite.ziyang.com"
2020/05/06 06:24:05 [notice] 86959#0: *25 rewritten data: "/second/3.txt", args: "", client: 127.0.0.1, server: rewrite.ziyang.com, request: "GET /first/3.txt HTTP/1.1", host: "rewrite.ziyang.com"
2020/05/06 06:24:05 [notice] 86959#0: *25 "/second(.*)" matches "/second/3.txt", client: 127.0.0.1, server: rewrite.ziyang.com, request: "GET /first/3.txt HTTP/1.1", host: "rewrite.ziyang.com"
2020/05/06 06:24:05 [notice] 86959#0: *25 rewritten data: "/third/3.txt", args: "", client: 127.0.0.1, server: rewrite.ziyang.com, request: "GET /first/3.txt HTTP/1.1", host: "rewrite.ziyang.com"
if 指令也是在rewrite 阶段生效的,它的语法如下所示:
Syntax: if (condition) { ... }
l 条件condition 为真,则执行大括号内的指令;同时还遵循值指令的继承规则(详见我之前的文章 Nginx的配置指令 )
28. 将变量与正则表达式做匹配大小写敏感,~ 或者 !~大小写不敏感,~* 或者 !~*
31. 检查文件、目录、软链接是否存在,使用 -e 或者 !-e
if ($http_user_agent ~ MSIE) { # 与变量 http_user_agent 匹配
rewrite ^(.*)$ /msie/$1 break;
if ($http_cookie ~* "id=([^;]+)(?:;|$)") { # 与变量 http_cookie 匹配
if ($request_method = POST) { # 与变量 request_method 匹配,获取请求方法
if ($slow) { # slow 变量在 map 模块中自定义,也可以进行匹配
当经过 rewrite 模块,匹配到 URL 之后,就会进入 find_config 阶段,开始寻找 URL 对应的 location 配置。
Syntax: location [ = | ~ | ~* | ^~ ] uri { ... }
Syntax: merge_slashes on | off;
这里面有一个 merge_slashes 指令,这个指令的作用是,加入 URL 中有两个重复的 /,那么会合并为一个,这个指令默认是打开的,只有当对 URL 进行 base64 之类的编码时才需要关闭。
location 的匹配规则是仅匹配 URI,忽略参数,有下面三种大的情况:
l 前缀字符串常规匹配=:精确匹配^~:匹配上后则不再进行正则表达式匹配
对于这些规则刚看上去肯定是很懵的,完全不知道在说什么,下面来实战看几个例子。
server_name location.ziyang.com;
error_log logs/error.log debug;
return 200 'first regular s match!\n';
return 200 'longest regular s match!\n';
return 200 'stop regular s match!\n';
return 200 'longest prefix string match!\n';
return 200 'prefix string match!\n';
那么究竟会匹配哪一个呢?Nginx 其实是遵循一套规则的,如下图所示:
全部的前缀字符串是放置在一棵二叉树中的,Nginx 会分为两部分进行匹配:
37. 先遍历所有的前缀字符串,选取最长的一个前缀字符串,如果这个字符串是 = 的精确匹配或 ^~ 的前缀匹配,会直接使用
38. 如果第一步中没有匹配上 = 或 ^~,那么会先记住最长匹配的前缀字符串 location
39. 按照 nginx.conf 文件中的配置依次匹配正则表达式
40. 如果所有的正则表达式都没有匹配上,那么会使用最长匹配的前缀字符串
➜ test_nginx curl location.ziyang.com/Test1
➜ test_nginx curl location.ziyang.com/Test1/
➜ test_nginx curl location.ziyang.com/Test1/Test2
➜ test_nginx curl location.ziyang.com/Test1/Test2/
➜ test_nginx curl location.ziyang.com/Test1/Test3
l /Test1/ 匹配location ^~ /Test1/
l /Test1/Test2 匹配location ~* /Test1/(\w+)$
l /Test1/Test2/ 匹配location /Test1/Test2
l /Test1/Test3 匹配location ^~ /Test1/
41. 遍历所有可以匹配上的前缀字符串,总共有两个^~ /Test1//Test1
42. 选取最长的前缀字符串 /Test1/,由于前面有 ^~ 禁止正则表达式匹配,因此直接使用 location ^~ /Test1/ 的规则
下面就来到了 preaccess 阶段。我们经常会遇到一个问题,就是如何限制每个客户端的并发连接数?如何限制访问频率?这些就是在 preaccess 阶段处理完成的,顾名思义,preaccess 就是在连接之前。先来看下 limit_conn 模块。
这里面涉及到的模块是ngx_http_limit_conn_module ,它的基本特性如下:
l 生效阶段:NGX_HTTP_PREACCESS_PHASE 阶段
l 默认编译进Nginx,通过 --without-http_limit_conn_module 禁用
l 生效范围全部worker 进程(基于共享内存)进入 preaccess 阶段前不生效限制的有效性取决于 key 的设计:依赖 postread 阶段的 realip 模块取到真实 IP
这里面有一点需要注意,就是 limit_conn key 的设计,所谓的 key 指的就是对哪个变量进行限制,通常我们取的都是用户的真实 IP。
Syntax: limit_conn_zone key zone=name:size;
Syntax: limit_conn zone number;
Context: http, server, location
Syntax: limit_conn_log_level info | notice | warn | error;
Default: limit_conn_log_level error;
Context: http, server, location
Syntax: limit_conn_status code;
Default: limit_conn_status 503;
Context: http, server, location
下面又到了实战的环节了,通过一个实际的例子来看一下以上的几个指令是怎么起作用的。
limit_conn_zone $binary_remote_addr zone=addr:10m;
#limit_req_zone $binary_remote_addr zone=one:10m rate=2r/m;
error_log logs/myerror.log info;
#limit_req zone=one burst=3 nodelay;
l 在本地的hosts 文件中添加 limit.ziyang.com 为本机 IP
在这个配置文件中,做了两条限制,一个是 limit_rate限制为 50 个字节,并发连接数 limit_conn 限制为 1。
➜ test_nginx curl limit.ziyang.com
这时候访问 limit.ziyang.com 这个站点,会发现速度非常慢,因为每秒钟只有 50 个字节。
<head><title>500 Internal Server Error</title></head>
<center><h1>500 Internal Server Error</h1></center>
<hr><center>nginx/1.17.8</center>
第一个问题限制并发连接数的问题已经解决了,下面来看第二个问题。
这里面生效的模块是ngx_http_limit_req_module ,它的基本特性如下:
l 生效阶段:NGX_HTTP_PREACCESS_PHASE 阶段
l 默认编译进Nginx,通过 --without-http_limit_req_module 禁用
l 生效范围全部worker 进程(基于共享内存)进入 preaccess 阶段前不生效
leaky bucket 叫漏桶算法,其他用来限制请求速率的还有令牌环算法等,这里面不展开讲。
漏桶算法的原理是,先定义一个桶的大小,所有进入桶内的请求都会以恒定的速率被处理,如果请求太多超出了桶的容量,那么就会立刻返回错误。用一张图解释一下。
这张图里面,水龙头在不停地滴水,就像用户发来的请求,所有的水滴都会以恒定的速率流出去,也就是被处理。漏洞算法对于突发流量有很好的限制作用,会将所有的请求平滑的处理掉。
l 定义共享内存(包括大小),以及 key 关键字和限制速率
Syntax: limit_req_zone key zone=name:size rate=rate ;
rate 单位为r/s 或者 r/m(每分钟或者每秒处理多少个请求)
Syntax: limit_req zone=name [burst=number] [nodelay];
Context: http, server, location
l nodelay,如果设置了这个参数,那么对于漏桶中的请求也会立刻返回错误
Syntax: limit_req_log_level info | notice | warn | error;
Default: limit_req_log_level error;
Context: http, server, location
Syntax: limit_req_status code;
Default: limit_req_status 503;
Context: http, server, location
l limit_req 与limit_conn 配置同时生效时,哪个优先级高?
添加配置文件,这个配置文件与上一节的配置文件其实是相同的只不过需要注释一下:
limit_conn_zone $binary_remote_addrzone=addr:10m;
limit_req_zone $binary_remote_addrzone=one:10mrate=2r/m;
error_loglogs/myerror.log info;
#limit_req zone=one burst=3 nodelay;
结论:在 limit_req zone=one 指令下,超出每分钟处理的请求数后就会立刻返回 503。
➜ test_nginx curl limit.ziyang.com
<head><title>503 Service Temporarily Unavailable</title></head>
<center><h1>503 Service Temporarily Unavailable</h1></center>
<hr><center>nginx/1.17.8</center>
在没有添加 burst 参数时,会立刻返回错误,而加上之后,不会返回错误,而是等待请求限制解除,直到可以处理请求时再返回。
limit_req zone=one burst=3 nodelay;
添加了 nodelay 之后,请求在没有达到 burst 限制之前都可以立刻被处理并返回,超出了 burst 限制之后,才会返回 503。
l limit_req 与limit_conn 配置同时生效时,哪个优先级高?limit_req 在 limit_conn 处理之前,因此是 limit_req 会生效
l nodelay 添加与否,有什么不同?不添加 nodelay,请求会等待,直到能够处理请求;添加 nodelay,在不超出 burst 的限制的情况下会立刻处理并返回,超出限制则会返回 503。
经过 preaccess 阶段对用户的限流之后,就到了 access 阶段。
这里面涉及到的模块是ngx_http_access_module ,它的基本特性如下:
l 生效阶段:NGX_HTTP_ACCESS_PHASE 阶段
l 默认编译进Nginx,通过 --without-http_access_module 禁用
Syntax: allow address | CIDR | unix: | all;
Context: http, server, location, limit_except
Syntax: deny address | CIDR | unix: | all;
Context: http, server, location, limit_except
access 模块提供了两条指令 allow 和 deny ,来看几个例子:
对于用户访问来说,这些指令是顺序执行的,当满足了一条之后,就不会再向下执行。这个模块比较简单,我们这里不做实战演练了。
auth_basic 模块是用作用户认证的,当开启了这个模块之后,我们通过浏览器访问网站时,就会返回一个 401 Unauthorized,当然这个 401 用户不会看见,浏览器会弹出一个对话框要求输入用户名和密码。这个模块使用的是 RFC2617 中的定义。
l 基于HTTP Basic Authutication 协议进行用户密码的认证
l 默认编译进Nginx--without-http_auth_basic_moduledisable ngx_http_auth_basic_module
Syntax: auth_basic string | off;
Context: http, server, location, limit_except
Syntax: auth_basic_user_file file;
Context: http, server, location, limit_except
这里面我们会用到一个工具叫 htpasswd,这个工具可以用来生成密码文件,而 auth_basic_user_file 就依赖这个密码文件。
l 在example 目录下生成密码文件 auth.pass
htpasswd -bc auth.pass ziyang 123456
error_log logs/error.log debug;
auth_basic_user_fileexample/auth.pass;
l 在/etc/hosts 文件中添加 access.ziyang.com
这时候访问 access.ziyang.com 就会弹出对话框,提示输入密码:
l 功能:向上游的服务转发请求,若上游服务返回的响应码是 2xx,则继续执行,若上游服务返回的响应码是 2xx,则继续执行,若上游服务返回的是 401 或者 403,则将响应返回给客户端
l 原理:收到请求后,生成子请求,通过反向代理技术把请求传递给上游服务
l 默认未编译进Nginx,需要通过 --with-http_auth_request_module 编译进去
Syntax: auth_request uri | off;
Context: http, server, location
Syntax: auth_request_set $variable value;
Context: http, server, location
error_log logs/error.log debug;
auth_basic_user_file example/auth.pass;
proxy_pass http://127.0.0.1:8090/auth_upstream;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
l 这个配置文件中,/ 路径下会将请求转发到另外一个服务中去,可以用 nginx 再搭建一个服务
l 如果这个服务返回 2xx,那么鉴权成功,如果返回 401 或 403 则鉴权失败
Context: http, server, location
satisfy 指令有两个值一个是 all,一个是 any,这个模块对acces 阶段的三个模块都生效:
如果 satisfy 指令的值是 all 的话,就表示必须所有 access 阶段的模块都要执行,都通过了才会放行;值是 any 的话,表示有任意一个模块得到执行即可。
44. 如果有 return 指令,access 阶段会生效吗?return 指令属于 rewrite 阶段,在 access 阶段之前,因此不会生效。
45. 多个 access 模块的顺序有影响吗?ngx_http_auth_request_module, ngx_http_auth_basic_module, ngx_http_access_module,有影响
46. 输对密码,下面可以访问到文件吗?location /{ satisfy any; auth_basic "test auth_basic"; auth_basic_user_file examples/auth.pass; deny all; }可以访问到,因为 satisfy 的值是 any,因此只要有模块满足,即可放行。
47. 如果把 deny all 提到 auth_basic 之前呢?依然可以,因为各个模块执行顺序和指令的顺序无关。
48. 如果改为 allow all,有机会输入密码吗?没有机会,因为 allow all 是 access 模块,先于 auth_basic 模块执行。
讲到了这里,我们再来回顾一下 Nginx 处理 HTTP 请求的 11 个阶段:
现在我们已经来到了 precontent 阶段,这个阶段只有 try_files 这一个指令。
Syntax: try_files file ... uri;
server_nametryfiles.ziyang.com;
error_log logs/myerror.log info;
try_files/system/maintenance.html
$uri $uri/index.html $uri.html
try_files $uri $uri/index.html $uri.html =404;
l 访问/first 实际上到了 lasturl,然后返回 200
➜ test_nginx curl tryfiles.ziyang.com/second
<head><title>404 Not Found</title></head>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.17.8</center>
➜ test_nginx curl tryfiles.ziyang.com/first
mirror 模块可以实时拷贝流量,这对于需要同时访问多个环境的请求是非常有用的。
l 模块:ngx_http_mirror_module 模块,默认编译进 Nginx通过 --without-http_mirror_module 移除模块
l 功能:处理请求时,生成子请求访问其他服务,对子请求的返回值不做处理
Context: http, server,location
Syntax: mirror_request_body on | off;
Default: mirror_request_body on;
Context: http, server, location
l 配置文件如下所示,需要再开启另外一个 Nginx 来接收请求
server_name mirror.ziyang.com;
error_log logs/error_log debug;
proxy_pass http://127.0.0.1:10020$request_uri;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
下面开始就到了 content 阶段,先来看 content 阶段的 static 模块,虽然这是位于 content 阶段的最后一个处理模块,但是这里先来介绍它。
先来一下 root 和 alias 这两个指令,这两个指令都是用来映射文件路径的。
Context: http, server, location, if in location
l 差别:root会将完整 URL 映射进文件路径中,alias 只会将 location 后的 URL 映射到文件路径
error_log logs/myerror.log info;
location ~ /alias/(\w+\.txt) {
return 200 '$request_filename:$document_root:$realpath_root\n';
➜ test_nginx curl static.ziyang.com/alias/1.txt
➜ test_nginx curl static.ziyang.com/alias/
<title>Welcome to nginx!</title>
➜ test_nginx curl static.ziyang.com/root/
<head><title>404 Not Found</title></head>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.17.8</center>
➜ test_nginx curl static.ziyang.com/root/1.txt
<head><title>404 Not Found</title></head>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.17.8</center>
这是为什么呢?是因为,root 在映射 URL 时,会把 location 中的路径也加进去,也就是:
l static.ziyang.com/root/实际访问的是 html/root/
l static.ziyang.com/root/1.txt实际是 html/first/1.txt/root/1.txt
l static.ziyang.com/alias/实际上是正确访问到了 html 文件夹,由于后面有 / 的存在,因此实际访问的是 html/index.html
l static.ziyang.com/alias/1.txt实际访问的是 html/first/1.txt ,文件存在
return 200 '$request_filename:$document_root:$realpath_root\n';
这里有一个问题,在访问 /RealPath/1.txt 时,这三个变量的值各为多少?
l document_root:由 URI和 root/alias 指令生成的文件夹路径(可能包含软链接的路径)
l realpath_root:将document_root 中的软链接替换成真实路径
为了验证这三个变量,在 html 目录下建立一个软链接指向 first 文件夹:
➜ html curl static.ziyang.com/realpath/1.txt
/Users/mtdp/myproject/nginx/test_nginx/html/realpath/1.txt:/Users/mtdp/myproject/nginx/test_nginx/html/realpath/:/Users/mtdp/myproject/nginx/test_nginx/html/first
l /Users/mtdp/myproject/nginx/test_nginx/html/realpath/1.txt
l /Users/mtdp/myproject/nginx/test_nginx/html/realpath/
l /Users/mtdp/myproject/nginx/test_nginx/html/first
Default: types { text/html html; image/gif gif; image/jpeg jpg; }
Context: http, server, location
Syntax: default_type mime-type;
Default: default_type text/plain;
Context: http, server, location
Syntax: types_hash_bucket_size size;
Default: types_hash_bucket_size 64;
Context: http, server, location
Syntax: types_hash_max_size size;
Default: types_hash_max_size 1024;
Context: http, server, location
Syntax: log_not_foundon | off;
Context: http, server, location
在生产环境中,经常可能会有找不到文件的情况,错误日志中就会打印出来:
[error] 10156#0: *10723 open() "/html/first/2.txt/root/2.txt" failed (2: No such file or directory)
现在有另外一个问题,当我们访问目录时最后没有带 / ,static 模块会返回 301 重定向,那么这个规则是怎么定义的呢,看下面三个指令:
Syntax: server_name_in_redirect on | off;
Default: server_name_in_redirect off;
Context: http, server, location
Syntax: port_in_redirect on | off;
Context: http, server, location
Syntax: absolute_redirect on | off;
Default: absolute_redirect on;
Context: http, server, location
server_namereturn.ziyang.com dir.ziyang.com;
absolute_redirect 默认是打开的,我们把它关闭了,看下是怎么返回的:
➜ test_nginx curl localhost:8088/first -I
HTTP/1.1 301 Moved Permanently
Date: Tue, 12 May 2020 00:31:36 GMT
下面再把 absolute_redirect 打开(默认是打开的,因此注释掉就行了),看下返回什么:
➜ test_nginx curl localhost:8088/first -I
HTTP/1.1 301 Moved Permanently
Date: Tue, 12 May 2020 00:35:49 GMT
Location: http://return.ziyang.com:8088/first/
可以看到,这时候就返回了域名,而且返回的是我们配置的主域名加端口号,这是因为, server_name_in_redirect 和 port_in_redirect 这两个指令打开了,如果关闭掉这两个指令,看下返回什么:
➜ test_nginx curl localhost:8088/first -I
HTTP/1.1 301 Moved Permanently
Date: Tue, 12 May 2020 00:39:31 GMT
Location: http://localhost/first/
这两个指令都设置为 off 之后,会发现返回的不再是主域名加端口号,而是我们请求的域名和端口号,如果在请求头中加上 Host ,那么就会用 Host 请求头中的域名。
l 功能:指定/ 结尾的目录访问时,返回 index 文件内容
l 语法:Syntax: index file ...; Default: index index.html; Context: http, server, location
这个模块,当我们访问以 / 结尾的目录时,会去找 root 或 alias 指令的文件夹下的 index.html,如果有这个文件,就会把文件内容返回,也可以指定其他文件。
l 模块:ngx_http_autoindex_module ,默认编译进 Nginx,使用 --without-http_autoindex_module 取消
l 功能:当URL 以 / 结尾时,尝试以html/xml/json/jsonp 等格式返回 root/alias 中指向目录的目录结构
l 语法:# 开启或关闭 Syntax: autoindex on | off; Default: autoindex off; Context: http, server, location # 当以 HTML 格式输出时,控制是否转换为 KB/MB/GB Syntax: autoindex_exact_size on | off; Default: autoindex_exact_size on; Context: http, server, location # 控制以哪种格式输出 Syntax: autoindex_format html | xml | json | jsonp; Default: autoindex_format html; Context: http, server, location # 控制是否以本地时间格式显示还是UTC 格式 Syntax: autoindex_localtime on | off; Default: autoindex_localtime off; Context: http, server, location
server_name autoindex.ziyang.com;
这里我把 index b.html 这条指令给注释掉了,而 index 模块是默认编译进 Nginx 的,且默认指令是 index index.html ,因此,会去找是否有 index.html 这个文件。
l 打开浏览器,访问 autoindex.ziyang.com:8080,html 目录下默认是有 index.html 文件的,因此显示结果为:
l 打开index b.html 指令注释。由于 html 文件夹下并不存在 b.html 这个文件,所以请求会走到 autoindex 模块,显示目录:
后面的文件大小显示格式就是由autoindex_exact_size on; 这条指令决定的。
下面介绍一个可以提升小文件性能的模块,这个模块是由阿里巴巴开发的,在淘宝网中有广泛应用。
l 模块开发者:Tengine( https://github.com/alibaba/nginx-http-concat ) --add-module=../nginx-http-concat/
l 功能:合并多个小文件请求,可以明显提升 HTTP 请求的性能
l 指令:#在 URI 后面加上 ??,通过 ”,“ 分割文件,如果还有参数,则在最后通过 ? 添加参数 concat on | off default concat off Context http, server, location concat_types MIME types Default concat_types: text/css application/x-javascript Context http, server, location concat_unique on | off Default concat_unique on Context http, server, location concat_max_files numberp Default concat_max_files 10 Context http, server, location concat_delimiter string Default NONE Context http, server, locatione concat_ignore_file_error on | off Default off Context http, server, location
这里就不做实战了,感兴趣的同学可以自己去编译一下这个模块,做一下实验,我把配置文件放在这里:
server_name concat.ziyang.com;
error_log logs/myerror.log debug;
下面终于来到了 11 个阶段的最后一个阶段,记录请求访问日志的 log 模块。
Syntax: log_format name [escape=default|json|none] string ...;
Default: log_format combined "...";
log_format combined '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent ' '"$http_referer"
Syntax: access_log path [format [buffer=size] [gzip[=level]] [flush=time] [if=condition]];
Default: access_log logs/access.log combined;
Context: http, server, location, if in location, limit_except
l path 路径可以包含变量:不打开 cache 时每记录一条日志都需要打开、关闭日志文件
l 日志缓存功能:批量将内存中的日志写入磁盘写入磁盘的条件:所有待写入磁盘的日志大小超出缓存大小;达到 flush 指定的过期时间;worker 进程执行 reopen 命令,或者正在关闭。
l 日志压缩功能:批量压缩内存中的日志,再写入磁盘buffer 大小默认为 64KB压缩级别默认为 1(1最快压缩率最低,9最慢压缩率最高)打开日志压缩时,默认打开日志缓存功能
Syntax: open_log_file_cache max=N [inactive=time] [min_uses=N] [valid=time];
Default: open_log_file_cache off;
Context: http, server, location
l max:缓存内的最大文件句柄数,超出后用 LRU 算法淘汰
l inactive:文件访问完后在这段时间内不会被关闭。默认 10 秒
l min_uses:在inactive 时间内使用次数超过 min_uses 才会继续存在内存中。默认 1
l valid:超出valid 时间后,将对缓存的日志文件检查是否存在。默认 60 秒
到了这里,我们已经将 Nginx 处理 HTTP 请求的 11 个阶段全部梳理了一遍,每个阶段基本都有对应的模块。相信对于这样一个全流程的解析,大家都能够看懂 Nginx 的配置了,在此之上,还能够按照需求灵活配置出自己想要的配置,这样就真正的掌握了 11 个阶段。
联系客服