本小节,我们将主要介绍 Nginx 中 Http 请求 11 个阶段中的最后几个重要的阶段以及相关的模块,并演示其用法。
1. try_files 阶段
这个阶段又称为 precontent 阶段,是 content 阶段的前置处理阶段,该阶段主要介入的模块是 ngx_http_try_files_module 模块。该模块依次访问多个 URI 对应得文件(由 root 或者 alias 指令指定),当文件存在时直接返回内容,如果所有文件不存在,则按最后一个 URL 结果或者 code 返回。
Syntax: try_files file ... uri;
try_files file ... =code;
Default: —
Context: server, location
2. content 阶段
content 阶段中最主要的 static 模块,该模块提供了root 和 alias 这两个常用的指令。二者的用法如下:
Syntax: alias path
Default: —
Context: location
Syntax: root path
Default: root html
Context: http, server, location, if in location
可以看到,单从指令用法上就可以看到不少区别,首先是 alias 指令没有默认值,而且该指令只能在 location 中使用。而 root 可以存在与 http、server、location 等多个指令块中,还可以出现在 if 指令中。另外,最最主要的不同是两个指令会以不同的方式将请求映射到服务器文件上。root 指令会用[root 路径 + location 路径]的规则映射静态资源请求,而 alias 会使用 alias 的路径替换 location 路径。
此外 alias 后面必须要用“/”结束,否则会找不到文件的,而 root 则可有可无。来看下面一个例子:
location ^~ /test {
root /root/html/;
}
location ^~ /test2/ {
alias /root/html/;
}
对于 http 请求: http://ip:端口/test/web1.html
访问的是主机 上全路径为 /root/html/test/web1.html
的静态资源;而请求http://ip:端口/test2/web1.html
访问的是全路径为/root/html/web1.html
的静态资源,/test2/已经被替换掉了。
在 static 模块中,还提供了 3 个变量供我们使用,分别是:
- request_filename: 访问静态资源的完整路径
- document_root: 访问静态资源文件所在目录
- realpath_root: 如果 document_root 是软链接,则改变量会将其替换成真正的地址
同样是上面的例子,稍做改动:
location /web {
default_type text/html;
alias /root/test/web;
return 200 '$request_filename:$document_root:$realpath_root\n';
}
访问 http://ip:端口//web/web1.html
, 返回的结果为:
/root/test/web/web1.html:/root/test/web:/root/test/web
在 content 阶段,在 static 模块之前,还会执行的模块有 index 和 autoindex模块。index 模块提供了 index 指令,用于指定/访问时返回 index 文件内容。
autoindex 模块会根据配置决定是否以列表的形式展示目录下的内容,这个功能在后续实战中搭建内部 pip 源中会用到。
Syntax: index file ...;
Default: index index.html;
Context: http, server, location
# 示例,访问 uri=/ 时,返回静态资源 index.html 文件中的内容
location / {
index index.html;
}
# 是否开启目录显示,默认Nginx是不会显示目录下的所有文件
Syntax: autoindex on | off;
Default: autoindex off;
Context: http, server, location
# 显示出文件的实际大小
Syntax: autoindex_exact_size on | off;
Default: autoindex_exact_size on;
Context: http, server, location
# 显示格式,默认是html形式显示
Syntax: autoindex_format html | xml | json | jsonp;
Default: autoindex_format html;
Context: http, server, location
# 显示时间,设置为on后,按照服务器的时钟为准
Syntax: autoindex_localtime on | off;
Default: autoindex_localtime off;
Context: http, server, location
3. log 阶段
log 阶段是 http 请求 11 个阶段中的最后一个阶段,这个阶段主要的任务就是记录请求的访问日志。这个阶段主要涉及的是 ngx_http_log_module 这个模块。该模块提供了几个常用指令,如 access_log 和 log_format 指令,分别定义了请求日志的记录文件以及记录的日志格式。
# 官方例子
log_format compression '$remote_addr - $remote_user [$time_local] '
'"$request" $status $bytes_sent '
'"$http_referer" "$http_user_agent" "$gzip_ratio"';
access_log /spool/logs/nginx-access.log compression buffer=32k;
# access_log指令用法
Syntax: access_log path [format [buffer=size] [gzip[=level]] [flush=time] [if=condition]];
access_log off;
Default: access_log logs/access.log combined;
Context: http, server, location, if in location, limit_except
# log_format指令用法
Syntax: log_format name [escape=default|json|none] string ...;
Default: log_format combined "...";
Context: http
# 是否打开日志缓存
Syntax: open_log_file_cache max=N [inactive=time] [min_uses=N] [valid=time];
open_log_file_cache off;
Default: open_log_file_cache off;
Context: http, server, location
4. 案例测试
4.1 try_files 模块的示例
在测试机器的 /root/test/web 目录下有 2 个 html 文件,分别为 web.html 和 web2.html, 没有 web3.html。我们编写如下的 server 块,监听 8013 端口。首先访问 http://主机ip:8013/web 时,根据配置情况,Nginx 首先查找是否存在 /root/test/web/web3.html 文件,没有找到会继续向下,找$uri,也就是/root/test/web 文件,不存在。继续找 KaTeX parse error: Expected 'EOF', got ',' at position 15: uri/index.html,̲即/root/test/web…uri/web1.html时文件存在,故返回/root/test/web/web1.html文件内容。如果该文件还不存在,则还会继续批评额哦@lasturi,最后返回’lasturi!'这样的字符串。而在访问 http://主机ip:8013/return_code 时,由于无法匹配静态资源,根据配置最后返回404错误码,出现 Nginx 默认的 404 错误页面。
server {
server_name try_files.com;
listen 8013;
root /root/test/;
default_type text/plain;
location /web {
# 找/root/test/index.html
# try_files /index.html
try_files /web/web3.html
$uri $uri/index.html $uri/web1.html
@lasturi; #最后匹配这个
}
location @lasturi {
eturn 200 'lasturi!\n';
}
location /return_code {
try_files $uri $uri/index.html $uri.html =404;
}
}
4.2 access_log 指令用法示例
我们只需要在 http 指令块中配置 log_format 指令和 access_log 指令即可。测试的配置如下:
...
http {
...
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log logs/access.log main;
# 和上面的日志格式无关
server {
listen 8000;
return 200 '8000, server\n';
}
...
}
...
log_format 指令是指定打印日志的格式,access_log 指令指定日志输出的路径以及指定使用前面定义的日志格式。在配置好日志相关的指令后,重启 Nginx,并发送一个 Http 请求,就可以在对应的路径上看到相关的日志信息了。
# 模拟发送http请求
[shen@shen Desktop]$ curl http://180.76.152.113:8000
8000, server
[shen@shen Desktop]$ curl -H "X-Forwarded-For: 1.1.1.1" http://180.76.152.113:8000
# 查看打印的日志,和前面配置的日志格式进行对比
[root@server nginx]# tail -2 logs/access.log
103.46.244.226 - - [02/Feb/2020:20:52:05 +0800] "GET / HTTP/1.1" 200 13 "-" "curl/7.29.0" "-"
103.46.244.226 - - [02/Feb/2020:20:57:03 +0800] "GET / HTTP/1.1" 200 13 "-" "curl/7.29.0" "1.1.1.1"
5. 小结
本节内容介绍了 Http 请求 11 个阶段中的最后几个,分别是 try_files 阶段、content 阶段和 log 阶段,同时还有对应阶段中生效的指令。这些在配置静态资源访问时非常有用,因为主要是涉及到读取静态资源的内容。最后的 log 模块也是非常重要的一步,良好的日志记录有助于我们后续排查问题以及分析系统性能瓶颈。今天 Http 请求的 11 个处理阶段正式讲完,后面还需要多多深入每个阶段的指令学习和实验,彻底掌握 Nginx 的 Http 模块。