2022
我们一起努力

nginx静态资源缓存(nginx静态资源缓存时间)

本文目录:

  • 1、【NGINX入门】3.Nginx的缓存服务器proxy_cache配置
  • 2、node静态资源nginx部署部署后无法访问
  • 3、nginx如何实现负载均衡、限流、缓存、黑白名单和灰度发布
  • 4、基于Nginx设置浏览器协商缓存过程详解
  • 5、Nginx高可用
  • 6、缓存静态资源,不知怎么解决

【NGINX入门】3.Nginx的缓存服务器proxy_cache配置

本文介绍NGINX缓存机制,配置和参数说明。

如图所示,nginx缓存,可以在一定程度上,减少源服务器的处理请求压力。因为静态文件(比如css,js, 图片)中,很多都是不经常更新的。nginx使用proxy_cache将用户的请求缓存到本地一个目录。下一个相同请求可以直接调取缓存文件,就不用去请求服务器了。毕竟,IO密集型服务的处理是nginx的强项。

Nginx的缓存加速功能是由proxy_cache(用于反向代理和静态缓存)和fastcgi_cache(PHP动态缓存)两个功能模块完成。

Nginx缓存特点:

先上个例子:

因为我是在一台服务器上做试验,所以用了两个端口 80 和 90 进行模拟两台服务器之间的交互。

接下来讲一下配置项:

这里我设置了 图片 、 css 、 js 静态资源进行缓存。

当用户输入 域名时,解析得到 ip:port 的访问地址。 port 默认为80。所以页面请求会被当前server截取到,进行请求处理。

当解析到上述文件名结尾的静态资源,会到缓存区获取静态资源。

如果获取到对应资源,则直接返回数据。

如果获取不到,则将请求转发给 proxy_pass 指向的地址进行处理。

这里直接处理 90 端口接受到的请求,到服务器本地目录 /mnt/blog 下抓取资源进行响应。

细心的读者应该发现,我在第二段例子里,留了个彩蛋 add_header wall "hey!guys!give me a star." 。

add_header 是用于在报头设置自定义的信息。

所以,如果缓存有效的话,那么静态资源返回的报头,一定会带上这个信息。

(1)Nginx系列教程(3)nginx缓存服务器上的静态文件

(2)proxy_cache

nginx 反向代理之 proxy_cache

(3)Nginx使用upstream负载均衡和proxy_cache缓存实现反向代理

node静态资源nginx部署部署后无法访问

1、首先确认静态资源文件夹是否已经放在与 nginx.exe 同级的目录中。

2、确认 conf 文件夹中 nginx.conf 文件里 location 中 root 后面是否填写正确的静态资源文件名。

3、Nginx 服务器的目录路径不能有中文,检查路径中是否有中文,有的话,需要移出来。

4、确认以上修改没有问题后,进入任务管理器,点击详细信息,找到所有的 nginx.exe 停止运行,并清理浏览器上的缓存,重启 nginx 服务器。

5.若以上操作均没有问题,那么最后可能导致的原因是防火墙,检查防火墙是否关闭。

nginx如何实现负载均衡、限流、缓存、黑白名单和灰度发布

1.负载均衡配置

2.失败重试配置

在fail_timeout时间内失败了max_fails次请求后,认为上游服务器不可用,就会将服务地址剔除掉,fail_timeout时间后会再次将服务器加入存活列表进行重试。

limit_req_zone指令设置参数

参数说明

limit_req_zone定义在http块中,$binary_remote_addr表示保存客户端IP地址的二进制形式。

Zone定义IP状态及URL访问频率的共享内存区域。zone=keyword标识区域的名字,以及冒号后面跟区域大小。16000个IP地址的状态信息约1MB,例子区域可以存储160000个IP地址。

Rate定义最大请求速率。示例中速率不能超过每秒10个请求。

设置限流

burs排队大小,nodelay不限制单个请求间的时间。具体使用可以查看高并发场景如何使用nginx实现限流-实战篇

不限流白名单

该配置说明 192.168.1.0/24网段的ip访问是不限流的,其它限流。ip后面数字的含义

24表示子网掩码:255.255.255.0

16表示子网掩码:255.255.0.0

8表示子网掩码:255.0.0.0

1.浏览器缓存 静态资源缓存用expire

Response Header中添加了Expires和Cache-Control

所谓的静态资源一般包括一直不变的图像,如网站的logo,js、css静态文件还有可下载的内容,媒体文件

协商缓存(add_header ETag/Last-Modified value)包括html文件,经常替换的图片,经常需要修改的js、css文件和基本不变的api接口

不需要缓存包括用户隐私等敏感数据,用户经常变动的api接口

2.代理层缓存

在本地磁盘创建一个文件目录,根据我们的配置把请求资源以k(key自定义,这边用url的hash值)-v形式缓存到目录里,并根据需求对内容设置缓存时长,比如状态码为200缓存10分钟,其余的缓存1分钟等待。要清理缓存可以借助purger的功能。如果ab测试/个性化需求时应禁用浏览器缓存,否则会因为缓存导致误差。

方式一

方式二 lua+redis动态黑名单(openresty)

配置(/usr/local/openresty/nginx/conf/nginx.conf)

lua脚本编写(ip_blacklist.lua)

1.根据cookie实现灰度发布

根据cooke查询version值,根据version跳转到对应的host,如果没有匹配上的就跳转到默认配置。

2.根据来路ip实现灰度发布

基于Nginx设置浏览器协商缓存过程详解

一、强缓存与协商缓存的区别

强缓存:浏览器不与服务端协商直接取浏览器缓存

协商缓存:浏览器会先向服务器确认资源的有效性后才决定是从缓存中取资源还是重新获取资源

二、协商缓存运作原理

现在有一个这样的业务情景:后端的静态资源会不定时地发生更新,而因为浏览器默认使用强缓存,会默认从浏览器缓存中取到过时的资源。

现在我们希望浏览器每次获取资源的时候都向后端确认资源是否更新,就要设置浏览器使用协商缓存

那么后端如何判断资源是否更新了呢?这时就要用到Etag和Last-Modified两项响应头。

每次收到一个静态资源的请求时,后端都将资源的最后修改时间(Last-Modified)、根据资源内容计算出来的Etag放在响应头给前端。

前端收到响应后将这两项缓存起来,然后在下次请求同样资源的时候,将这两项的内容放到If-Modified-Since和If-None-Match这两项请求头中。

服务端收到这两项后,会与资源当前生成的Etag和Last-Modified做比较,如果两者都一致,说明资源没有更新,服务端会返回304空响应;否则,说明资源有更新,服务端会将完整的资源内容返回

实现

那么如何实现这样一个复杂的过程呢?其实很简单,只要使用nginx作为静态资源的服务器,再在响应头加上Cache-Control:no-cache就可以了。

下面来分步骤实现一下

1. 使用nginx作为静态资源的服务器

在nginx的配置中,将对静态资源的请求映射到资源的磁盘路径上

http {

  server {

  listen 80;

  ...

  location /picture/ {

    alias D:/luozixi/tcp_test/picture/;

    # alias是重定义路径

    # 比如访问127.0.0.1/picture/1_new.gif,则会映射为访问D:/luozixi/tcp_test/picture/1_new.gif

    # web应用根本不会收到请求,picture的请求都被nginx处理了

    # alias是替换,root是拼接

    autoindex on;

    }

  }

}

2. 重新加载nginx配置

3. 此时,请求静态资源的时候nginx会自动在response头中加上Etag和Last-Modified两项

4. 但是这时发现,如果不配置Cache-Contrl: no-cache,浏览器在下次请求这个资源的时候不会将请求发向后端,而是直接从缓存中获取资源

5. 在nginx中配置

location /picture/ {

  add_header Cache-Control no-cache;

  alias D:/luozixi/tcp_test/picture/;

}

6.清除浏览器缓存后第一次发起请求,会得到一个正常的200 Response,而且响应头里已经有了Cache-Control: no-cache,表示使用协商缓存

7.再次发起请求后,会发现请求头已经带上了If-Modified-Since和If-None-Match两项

8.服务端(nginx)收到这两项后,会与资源当前生成的Etag和Last-Modified做比较,如果两者都一致,说明资源没有更新,服务端会返回304空响应;否则,说明资源有更新,服务端会将完整的资源内容返回

另外,服务器验证If-Modified-Since的方式只是简单的字符串比较,即使资源的Last-Modified比If-Modified-Since要早,服务端仍认为资源有更新

9.浏览器在收到304响应后,会从浏览器缓存中取资源。因此速度非常块

三、no-cache与no-store的区别

no-cache表示不缓存过期资源,缓存会向服务器进行有效处理确认之后处理资源

而no-store才是真正的不进行缓存。

Nginx高可用

一、Nginx概念

Nginx是一个高性能的http和反向代理服务器,特点是占用内存少,并发能力强,事实上Nginx的并发能力确实在同类型的网页服务器中表现较好

Nginx专为性能优化而开发,性能就是其最重要的考量,实现上非常注重效率,能经受高负载的考验,有报告表明能支持高达50000个并发连接数

二、Nginx配置文件

第一部分全局块

从配置文件开始到events之间的内容,主要会设置一些影响Nginx服务器整体运行的配置指令,比如worker_processes 1; worker_processes值越大,可以支持的并发处理量越多

第二部分events块

events块涉及的指令主要影响Nginx服务器与用户的网络连接,比如worker_connections 1024; 支持的最大连接数

第三部分http全局块

http全局配置的指令包括文件引入、mime-type定义,日志自定义,连接超时时间,单连接请求数上限,server块等

三、反向代理

1、正向代理

在客户端(浏览器)配置代理服务器,通过代理服务器进行互联网访问

2、反向代理

我们只需要将请求发送到代理服务器,有反向代理服务器去选择目标服务器获取数据后,再返回给客户端,此时反向代理服务器和目标服务器对外就是一个服务器,暴露的是代理服务器地址,隐藏了真实服务器IP地址

配置方式

方式一

方式二指定location规则代理

四、负载均衡

增加服务器的数量,然后将请求分发到各个服务器上,将原先请求集中到单个服务器上的情况改为将请求分发到多个服务器上,将负载分发到不同的服务器,也就是我们所说的负载均衡

1、配置两台服务器负载

2、Nginx分配服务器策略

轮询(默认)

每个请求按照时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除

weight

weight代表权重默认为1,权重越高被分配的客户端越多

指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况

ip_hash

每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题

五、动静分离

Nginx动静就是动态请求和静态请求分开,减轻动态服务器的压力

方式一

Nginx配置location规则处理静态请求,可以设置expires静态资源缓存时间

autoindex 列出文件目录

方式二

配置静态服务器和动态服务器分开请求

六、高可用

一台代理服务可能出现down机导致服务不可用,无法保证高可用

高可用架构配置多台服务器比如两台服务器一台正常使用一台用来备份,通过keepalived 心跳机制进行监控当主的服务器down掉立即启用备份服务器保证服务的高可用

安装keepalived 配置keepalived.conf 添加检测脚本 绑定网卡配置虚拟ip

七、Nginx原理

1、工作模式master和worker

2、一个master和多个workers的机制好处?

①可以使用nginx -s reload 热部署,利于nginx热部署操作

②每个worker是独立的进程,如果有其中一个worker出现问题,其他worker独立的继续进行争抢,实现请求过程,不会造成服务中断

需要设置多少个worker

nginx同redis类似都采用了io多路复用机制,每个worker都是一个独立的进程,但每个进程里只有一个主线程,通过异步非阻塞的方式来处理请求,即使是成千上万个请求也不再话下。每个worker的线程可以把一个cpu的性能发挥到极致

所以worker数和服务器的cpu数相等是最为适宜的。少了浪费cup,多了会造成cpu频繁切换上下文带来消耗

3、连接数worker_connection

①发送请求,占用了worker的几个连接数?

2个或者4个

②nginx有一个master,有四个worker,每个worker支持最大的连接数1024,支持最大的并发数是多少?

普通的静态访问最大并发数是:worker_connection * worker_processes / 2

如果是http做反向代理最大并发数是worker_connection * worker_processes / 4

缓存静态资源,不知怎么解决

之前看过apach及nginx对于静态资源(含js,图片,css等)部分的缓存,用于加速并减轻后台实际web服务器的压力。

静态资源缓存是WEB服务器优化的一种手段,基本原理如下:

1.客户端浏览器请求服务器一个服务(该服务含有图片,js等静态资源),通常会对于每一个网页中的独立图片或js文件发送一个http请求

2.WEB服务器对于每个资源HTTP请求进行解析,并生成一个资源修改时间的唯一值(可以是etag或last_modified参数),放入服务器端map,key为资源url,value为资源修改时间。最后将此资源修改时间的唯一值包含在http头上返回,因为是首次请求,所以会将所有内容放在http body中一并返回给客户浏览器端

3.客户浏览器接收服服务器响应,并将服务器返回的资源修改时间作为key放入浏览器客户端,value为http body中的实际资源内容

4.客户浏览器再次请求静态资源时,会将资源修改时间一并发送给服务器

5.服务端会从最新的map中取出该资源url对应的修改时间,如果值晚于客户端请求的资源修改时间,这时会返回最新的已经修改过的资源给客户端。否则返回304 not modifed

这里记录资源修改时间的方式有etag及last_modified。最先有的是last_modified,它的工作方式就是上述介绍的,但缺点是只能精确到秒级别。也就是说当你在一秒中修改资源两次,而客户端拿到的是第一次修改,那之后就算客户端第二次再次请求也不会拿到最新的资源。

而etag的出现正是为了解决last_modified的秒级问题,于http 1.1被提出。

今天测试了下,在没有nginx等前端反向代理服务器时,tomcat竟然默认对静态资源做了缓存。

tomcat默认运用etag及last_modifed。etag与if_no_match(客户端浏览器上传时在http head中应该放的属性名)一起使用,last_modified与If-Modified-Since一起使用。

客户端首次请求时,得到请求响应数据如下:

GET [HTTP/1.1 200 OK 1ms]

GET [HTTP/1.1 200 OK 1ms]

GET [HTTP/1.1 200 OK 2ms]

我们看一下Hello.js这个请求响应具体信息:

server Apache-Coyote/1.1 (表明服务器是tomcat)

Last-Modified: Sun, 11 May 2014 10:54:33 GMT

Etag: W/"175-1399805673000"

Date: Sun, 11 May 2014 10:59:23 GMT

Content-Type: application/javascript;charset=UTF-8

Content-Length: 175

Accept-Ranges: bytes

从上面可以看到tomcat即返回了last_modified也返回了etag。

客户端再次请求时,请求数据如下:

If-None-Match: W/"175-1399805673000"

If-Modified-Since: Sun, 11 May 2014 10:54:33 GMT

响应如下:

GET [HTTP/1.1 200 OK 1ms]

GET [HTTP/1.1 304 Not Modified 1ms]

GET [HTTP/1.1 304 Not Modified 1ms]

从中我们可以看到tomcat对于静态数据作了缓存。

接着我们分析tomcat对于这部分静态缓存的判断处理,这部分逻辑是写在DefaultServlet类中,

我们可以在doGet方法中进入ServiceContext方法中找到以下源码:

// Check if the conditions specified in the optional If headers are

// satisfied.

if (cacheEntry.context == null) {

// Checking If headers

boolean included =

(request.getAttribute(Globals.INCLUDE_CONTEXT_PATH_ATTR) != null);

if (!included

!checkIfHeaders(request, response, cacheEntry.attributes)) { //这句判断是否需要返回整个资源请求

return;

}

}

上面源码的 if (!included

!checkIfHeaders(request, response, cacheEntry.attributes))

用于判断是否需要返回整个资源,如果indcluded与checkIfHeaders方法返回的都是false,这时就直接返回,说明资源未修改,或者是缓存不支持的请求方式。

我们接着查看checkIfHeaders方法:

/**

* Check if the conditions specified in the optional If headers are

* satisfied.

*

* @param request The servlet request we are processing

* @param response The servlet response we are creating

* @param resourceAttributes The resource information

* @return boolean true if the resource meets all the specified conditions,

* and false if any of the conditions is not satisfied, in which case

* request processing is stopped

*/

protected boolean checkIfHeaders(HttpServletRequest request,

HttpServletResponse response,

ResourceAttributes resourceAttributes)

throws IOException {

return checkIfMatch(request, response, resourceAttributes)

checkIfModifiedSince(request, response, resourceAttributes)

checkIfNoneMatch(request, response, resourceAttributes)

checkIfUnmodifiedSince(request, response, resourceAttributes);

}

可以看到tomcat只有当这四个属性全部返回true(也就是说全部认为资源已经改变)才会返回true,这样最终会将整个资源(最新修改过的)返回客户端。

在这里,我们从上面实际过程当中看到,浏览器第二次请求资源时在http请求header中放了

If-None-Match: W/"175-1399805673000"

If-Modified-Since: Sun, 11 May 2014 10:54:33 GMT

这两个属性。

因此我们查看

checkIfModifiedSince(request, response, resourceAttributes)

checkIfNoneMatch(request, response, resourceAttributes)

这两个方法

checkIfModifiedSince源码如下:

/**

* Check if the if-modified-since condition is satisfied.

*

* @param request The servlet request we are processing

* @param response The servlet response we are creating

* @param resourceInfo File object

* @return boolean true if the resource meets the specified condition,

* and false if the condition is not satisfied, in which case request

* processing is stopped

*/

protected boolean checkIfModifiedSince(HttpServletRequest request,

HttpServletResponse response,

ResourceAttributes resourceAttributes) {

try {

long headerValue = request.getDateHeader("If-Modified-Since");

long lastModified = resourceAttributes.getLastModified();

if (headerValue != -1) {

// If an If-None-Match header has been specified, if modified since

// is ignored.

if ((request.getHeader("If-None-Match") == null)

(lastModified headerValue + 1000)) {

// The entity has not been modified since the date

// specified by the client. This is not an error case.

response.setStatus(HttpServletResponse.SC_NOT_MODIFIED);

response.setHeader("ETag", resourceAttributes.getETag());

return false;

}

}

} catch (IllegalArgumentException illegalArgument) {

return true;

}

return true;

}

源码中可以看到:

if ((request.getHeader("If-None-Match") == null)

(lastModified headerValue + 1000)) {

这句话表明只有在客户端浏览器发送的请求头中不包含If-None-Match,IfModifiedSince才会生效。

我们接着看checkIfNoneMatch,源码如下:

/**

* Check if the if-none-match condition is satisfied.

*

* @param request The servlet request we are processing

* @param response The servlet response we are creating

* @param resourceInfo File object

* @return boolean true if the resource meets the specified condition,

* and false if the condition is not satisfied, in which case request

* processing is stopped

*/

protected boolean checkIfNoneMatch(HttpServletRequest request,

HttpServletResponse response,

ResourceAttributes resourceAttributes)

throws IOException {

String eTag = resourceAttributes.getETag();

String headerValue = request.getHeader("If-None-Match");

if (headerValue != null) {

boolean conditionSatisfied = false;

if (!headerValue.equals("*")) {

StringTokenizer commaTokenizer =

new StringTokenizer(headerValue, ",");

while (!conditionSatisfied commaTokenizer.hasMoreTokens()) {

String currentToken = commaTokenizer.nextToken();

if (currentToken.trim().equals(eTag))

conditionSatisfied = true;

}

} else {

conditionSatisfied = true;

}

if (conditionSatisfied) {

// For GET and HEAD, we should respond with

// 304 Not Modified.

// For every other method, 412 Precondition Failed is sent

// back.

if ( ("GET".equals(request.getMethod()))

|| ("HEAD".equals(request.getMethod())) ) {

response.setStatus(HttpServletResponse.SC_NOT_MODIFIED);

response.setHeader("ETag", eTag);

return false;

}

response.sendError(HttpServletResponse.SC_PRECONDITION_FAILED);

return false;

}

}

return true;

}

这里:

String eTag = resourceAttributes.getETag();

String headerValue = request.getHeader("If-None-Match");

这两句比较简单,就是分别从服务器缓存和http请求头中中取出etag。

接着判断这两个etag如果相等,则conditionSatisfied为true,会执行到以下语句:

if (conditionSatisfied) {

// For GET and HEAD, we should respond with

// 304 Not Modified.

// For every other method, 412 Precondition Failed is sent

// back.

if ( ("GET".equals(request.getMethod()))

|| ("HEAD".equals(request.getMethod())) ) {

response.setStatus(HttpServletResponse.SC_NOT_MODIFIED);

response.setHeader("ETag", eTag);

return false;

}

response.sendError(HttpServletResponse.SC_PRECONDITION_FAILED);

return false;

}

这段语句中可以发现,如果资源未改变的情况下,并且请求方式为GET或者HEAD时,会返回304状态码。否则返回一个412状态码,同样不会返回资源内容。

如果上述最终

if ((request.getHeader("If-None-Match") == null)

(lastModified headerValue + 1000))

条件不成立,即资源更新了或者是第一次请求,这里会读取当前请求资源文件,并最终放入http响应中。

nginx静态资源缓存】的内容来源于互联网,如引用不当,请联系我们修改。

赞(0)
文章名称:《nginx静态资源缓存(nginx静态资源缓存时间)》
文章链接:https://www.fzvps.com/130591.html
本站文章来源于互联网,如有侵权,请联系管理删除,本站资源仅供个人学习交流,请于下载后24小时内删除,不允许用于商业用途,否则法律问题自行承担。
图片版权归属各自创作者所有,图片水印出于防止被无耻之徒盗取劳动成果的目的。

评论 抢沙发

评论前必须登录!