前言
本章将介绍客户端缓存将介绍浏览器缓存和服务端缓存,使用浏览器缓存将减少对web服务器的请求次数,同时可以提升性能,避免重复的运算浪费。
ASP.NET Core对于HTTP缓存分为两种:
客户端缓存
通过设置HTTP的响应头 Cache-Control 来完成页面存储到浏览器缓存中如下所示:
其实客户端缓存的话只需要进行设置 ResponseCache 特性就可以请看如下代码片段
[ResponseCache(Duration = 100,Location = ResponseCacheLocation.Client)]
public IActionResult Index()
{
return View();
}
ResponseCacheAttribute 可应用于:
[ResponseCache] 参数
CacheProfileName使用请看如下代码片段
public void ConfigureServices(IServiceCollection services)
{
services.AddControllersWithViews(options =>
{
options.CacheProfiles.Add("default", new CacheProfile
{
Duration = 60
});
options.CacheProfiles.Add("test", new CacheProfile
{
Duration = 30
});
});
}
上述代码我们设置好了两份不一样的配置,那么我们就可以通过下面代码片段进行使用了
[ResponseCache(CacheProfileName = "default")]
public IActionResult Index()
{
return View();
}
服务端缓存
服务端缓存可以缓存页面数据和API数据,同时如果我们服务端存在数据,也就是缓存命中的情况下,会直接从缓存中取,不会再进入我们的方法。
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCaching(options =>
{
options.UseCaseSensitivePaths = false;
options.MaximumBodySize = 1024;
options.SizeLimit = 100 * 1024*1024;
});
}
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
app.UseResponseCaching();
}
服务端缓存配置如下
属性 | 描述 |
---|---|
MaximumBodySize | 响应正文的最大可缓存大小(以字节为单位)。 默认值为 64 * 1024 * 1024 (64 MB)。 |
SizeLimit | 响应缓存中间件的大小限制(以字节为单位)。 默认值为 100 * 1024 * 1024 (100 MB)。 |
UseCaseSensitivePaths | 确定是否将响应缓存在区分大小写的路径上。 默认值是 false。 |
[ResponseCache(Duration = 30, VaryByQueryKeys = new[] { "q" })]
public IActionResult Index(int q)
{
_logger.LogWarning($"我是一个路径:{HttpContext.Request.Host}");
return View(model:DateTime.Now.ToString());
}
VaryByQueryKeys
使用 MVC/web API 控制器或 Razor Pages 页面模型时, [ResponseCache]属性指定为响应缓存设置适当的标头所需的参数。 严格需要中间件的 [ResponseCache] 属性的唯一参数 VaryByQueryKeys,这与实际 HTTP 标头不对应。 有关详细信息,请参阅 响应缓存在 ASP.NET Core。
如果不使用 [ResponseCache] 属性,响应缓存可能会与 VaryByQueryKeys不同。
我们再看看如上代码效果
ResponseCache中间件使用的 HTTP 标头
响应头 | 描述 |
---|---|
Authorization | 如果标头存在,则不会缓存。 |
Cache-Control | 中间件仅考虑用 public 缓存指令标记的缓存响应。 |
Pragma | 请求中的 Pragma: no-cache 标头将产生与 Cache-Control: no-cache相同的效果。 如果存在此标头,则由 Cache-Control 标头中的相关指令重写。 考虑向后兼容 HTTP/1.0。 |
Set-Cookie | 如果标头存在,则不会缓存响应。 请求处理管道中设置一个或多个 cookie 的任何中间件会阻止响应缓存中间件缓存响应(例如,基于 cookie 的 TempData 提供程序)。 |
Vary | Vary 标头用于根据另一个标头改变缓存的响应。 例如,通过编码来缓存响应,包括 Vary: Accept-Encoding 响应头,该响应头将缓存标头为 Accept-Encoding: gzip 和 Accept-Encoding: text/plain 的请求的响应。 永远不会存储响应头值为 * 的响应。 |
Expires | 除非被其他 Cache-Control 标头重写,否则不会存储或检索此响应头过时的响应。 |
If-None-Match | 如果值不为 *,响应的 ETag 与提供的任何值都不匹配,则将从缓存中提供完整响应。 否则,将提供304(未修改)响应。 |
If-Modified-Since | 如果 If-None-Match 标头不存在,则在缓存的响应日期比提供的值更新时,将从缓存中提供完整响应。 否则,将提供304-未修改响应 |
Date | 从缓存提供时,如果未在原始响应中提供,则中间件会设置 Date 标头。 |
Content-Length | 从缓存提供时,如果未在原始响应中提供,则中间件会设置 Content-Length 标头。 |
Age | 忽略原始响应中发送的 Age 标头。 中间件在为缓存的响应提供服务时计算一个新值。 |
缓存条件
Reference
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Caching_FAQ
https://docs.microsoft.com/en-us/aspnet/core/performance/caching/middleware?view=aspnetcore-3.1
https://github.com/hueifeng/BlogSample/tree/master/src/ResponseCachingDemo
作者:@冯辉
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文链接
出处:https://www.cnblogs.com/yyfh/archive/2020/02/25/12361255.html
ASP.NET Core ResponseCache进行缓存操作
原文:https://www.cnblogs.com/lonelyxmas/p/12363978.html