Nginx学习:HTTP核心模块(九)浏览器缓存与try_files
浏览器缓存在 Nginx 的 HTTP 核心模块中其实只有两个简单的配置,这一块也是 HTTP 的基础知识。之前我们就一直在强调,学习 Nginx 需要的就是各种网络相关的基础知识,其中更重要的就是 HTTP 和 TCP 相关的内容。另外一个 try_files 配置指令也是 Nginx 中非常常用的一个指令,用于找不到指定的路径文件时,可以去按顺序查找备用的一些文件路径,非常实用。
浏览器缓存
在 HTTP 协议中,有许多和浏览器缓存有关的选项,而在 Nginx 的核心配置中,也有两个与之相关的配置。
if_modified_since
if_modified_since 是由浏览器发送的,让服务端来判断返回 200 还是 304 ,在 Nginx 中,它用于指定响应的修改时间与 if_modified_since 请求头的比较方法。
if_modified_since off | exact | before;
默认值是 exact ,每个选项分别代表:
off 忽略 “If-Modified-Since” 请求头 (0.7.34)
exact 精确匹配
before 响应的修改时间小于等于 “If-Modified-Since” 请求头指定的时间
etag
etag 是由服务器端生成的,客户端通过发送 If-Match 或者 If-None-Match 这个条件判断请求来验证资源是否修改。Nginx 中,这个配置可以开启或关闭为静态文件自动计算 “ETag” 响应头。
etag on | off;
它的默认值是 on 。
测试
正常情况下,我们第一次打开某个静态页面,是没有 if_modified_since 的,服务端会返回 ETag 和 Last-Modified 以及 200 状态码。
然后第二次请求的时候,浏览器就会带上 if_modified_since ,服务端会返回 304 表示使用本地缓存就可以了。
这是在默认情况下。现在我们修改 Nginx 的配置,先将 if_modified_since 设置为 off ,然后强刷页面之后再进行普通刷新 ,会发现不管是强刷还是普通刷新,响应头和请求虽然没有什么变化,但服务端都只会返回 200 了。也就是说,服务端不会去比较浏览器发送过来的 if_modified_since 值来判断是否返回 304 。
接下来测试 etag ,这个就麻烦一点,首先,我们要将 if_modified_since 设置为 before ,意思就是访问的静态资源文件的修改时间小于当前浏览器提供的 If-Modified-Since 时,才返回 200 。这样的话,如果我们手动修改文件的时间,将时间修改到当前时间之后很长的一段时间,那么就可以让浏览器在非强刷的状态下一直返回 304 。
touch -m -d "2023-09-08 12:23:04" /usr/local/nginx/html/aaa.html
默认 etag 为 on 的情况下,你再次修改文件的时间,依然会正常返回一次 200 。这就是 etag 的作用,它是根据文件一些属性进行综合 Hash 从而返回一个值,客户端保存上回的 etag 值后传送到服务端进行比对。而如果现在你将 etag 设置为 off 的话,那么再次请求就不会有 Etag 响应头返回了,这时修改文件的时间,甚至是修改文件的内容(注意修改内容后还要手动修改一下文件的修改时间,否则 if_modified_since 就会生效返回 200 了),后面的请求也将一直会是 304 (非强刷)。
ps.浏览器强刷其实就是浏览器不带任何和 HTTP 缓存有关的请求头进行一次请求访问。
Etag 最主要解决的其实是 if_modified_since 的一些缺点,比如说有些时候可能我们只是周期性地修改一下文件,但文件内容不发生变化(只是文件修改时间变动),这时其实可以不用重新 200 响应的。另外还有 if_modified_since 只支持到秒级,而 Etag 的 Hash 变化是跟随文件变动的,因此它的粒度更细一些。还有一种情况就是某些服务器不能精确的得到文件的最后修改时间,这也会导致 if_modified_since 产生问题,更典型的就是客户端时间和服务器时间不同步,比如有的人的电脑可能时间一直就是错的。
这一块的内容是 HTTP 的基础知识,而且写文字也不太好描述怎么测试,大家可以关注下后期的视频哈,在视频中咱们再好好演示。
try_files
按指定顺序检查文件是否存在,并且使用第一个找到的文件来处理请求,那么处理过程就是在当前上下文环境中进行的。
try_files file ... uri;
try_files file ... =code;
其实就是我们不确定用户访问的路径或者文件存不存在,这时可以按照 try_files 指定的顺序来展示指定的 URI ,通常它都会和 $uri
变量一起搭配使用,$uri
变量就是当前访问的 location 地址。说白了,就是给请求的链接准备好备胎,能够为用户带来更优良的用户体验。
文件路径是根据 root 指令和 alias 指令,将 file 参数拼接而成。 可以在名字尾部添加斜线以检查目录是否存在,比如“$uri/”。 如果找不到任何文件,将按最后一个参数指定的uri进行内部跳转。 比如:
location /tf1/ {
try_files $uri /50x.php;
}
现在试试访问 /tf1 ,会发现显示的是 50x.php 的内容,如果 /tf1 下面有页面的话,那么直接访问就可以查看到指定的页面。这种感觉是不是有点像 error_page ,其实上面的内容就相当于是下面这样的代码。
location /tf1/ {
error_page 404 /50x.php;
}
$uri
变量表示的是规范以后的 URI ,也就是拼接请求之后完整的 URI 路径。不过这个变量的值可能会随着请求的处理过程而改变,比如,当进行内部跳转时,或者使用默认页文件时。
这下就看出来了吧,try_files 按顺序,如果第一个 $uri
找到文件了,就直接使用这个文件,如果没找到,就找第二个,依次类推,我们也可以一直向后多写几个 uri ,直到有一个能够找到对应的文件。
location /tf2/ {
try_files $uri /tf2/1.html /tf2/2.html;
}
在 tf2 目录下,建立了两个文件,然后访问 /tf2 ,会显示 1.html 的内容,访问 /tf2/2.html ,正常显示 2.html 的内容,按顺序来说 $uri
是第一位的,后面的顺序哪个先找到就按哪个来。因此,除了指定访问 /tf2/2.html 之外,其它链接都会打开 1.html (如果有 404 的 error_page 设置,则直接走 404 的)。那么如果是跳转 uri 呢?比如我们跳转到 php 的 URI 上。
location /tf3/ {
try_files $uri /50x.php /404.php;
}
随便访问 /tf3 或者目录中的任意不存在的路径,我这里会弹出下载,查看请求 Content-Type 会变成 application/octet-stream ,下载的文件是 php 的源码。注意,这里是个坑点,不要在静态配置中进行这样的 try_files 。换成带 PHP 相关配置的再试试。
location /tf4/ {
try_files $uri /tf4/1.php /1.php =404;
fastcgi_pass unix:/var/sock/php-fpm/www.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
现在访问 /tf4 会显示到最外面那个我们之前测试的时候打印所有 $_SERVER
内容的 1.php 页面。如果我们创建 tf4 目录,并且添加一个 1.php ,并打印 echo "this is tf4/1.php.";
那么,再次刷新,页面就会展示 this is tf4/1.php. 。这样才能正常的显示 php 。不过我们直接用静态配置去 try_files 动态文件也有别的方法,就是使用命名 location 。
location /tf5/ {
try_files $uri @tf5php;
}
location @tf5php {
root html;
fastcgi_pass unix:/var/sock/php-fpm/www.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root/tf5php/index.php;
include fastcgi_params;
}
访问 /tf5 或者 /tf5/xxx.html ,都会打开 tf5php 目录下的 index.php 文件。注意,这里演示的是从 静态 文件到 php 文件,如果是 /tf5/xxx.php 则会被之前我们配置过的 ~ \.php
的配置拿走,不会走到这边来。
我们再来看看响应码的问题。
location /tf6/ {
try_files $uri $uri/ /xxx.html =401;
}
这一段表示的是如果前面 uri... 部分都没有匹配到,那么就会返回 401 的状态码。大家可以自己试一下访问 /tf6 下的任意文件,最后返回的都是 401 状态。
好了,我们再来看一下 Laravel 文档中给的一个 Nginx 配置,其中有一段内容是大部分 PHP 应用在部署的时候也都会要求写上的。
location / {
try_files $uri $uri/ /index.php?$query_string;
}
在全局的 location 中,访问 uri 页面或者 uri/ 目录,找不到文件的话,会转给 /index.php,并且把请求行的 GET 参数转给 /index.php 文件。通常现代化的框架都是单一入口,index.php 总是可以接收请求的,如果确实还是找不到,也将由 PHP 应用来进行对应的 404 或者 500 处理。
另外,try_files 还可以做一件非常常见的事,就是显示默认图片。
location /images/ {
try_files $uri /images/default.gif;
}
正常的图片路径找不到图片了,就使用默认的图片来代替,这也是很多网站的基本需求。
总结
今天的内容不难吧,加起来就是三个配置项,不过我们做了很多的测试。缓存对于现代化的 Web 开发来说非常重要,而 HTTP 缓存则是最前端的面向客户一级的缓存。对于静态资源来说,有着非常重要的作用,可以大大减少服务器的压力。而 try_files 的灵活则为我们带来了更多的特色功能,类似于默认图片这类的配置都能够非常简单方便。
不过估计大家平常可能对这几个指令用得也并不多,毕竟缓存那两个都有默认值,我们保持默认就好了。而 try_files 通常最多的就是用在上文所说的全局路径的处理上,是使用 Laravel 时必备的一个配置。但是,通过今天的学习,相信咱们将来在需要的时候,也能马上想起来这些配置指令的用法,能够更加灵活自如的运用它们。学习,就是这样一步一步的不断积累,一次一次的不停实践。
参考文档:文章来源:https://www.toymoban.com/news/detail-619031.html
http://nginx.org/en/docs/http/ngx_http_core_module.html文章来源地址https://www.toymoban.com/news/detail-619031.html
到了这里,关于【Nginx12】Nginx学习:HTTP核心模块(九)浏览器缓存与try_files的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!