ASP.NET Core中的Http缓存使用

Http响应缓存可减少客户端或代理对web服务器发出的请求数。响应缓存还减少了web服务器生成响应所需的工作量。响应缓存由Http请求中的header控制。

ASP.NET Core对其都有相应的实现,并不需要了解里面的工作细节,即可对其进行良好的控制。

了解Http缓存

Http协议中定义了许多缓存,但总体可以分为强缓存和协商缓存两类。

强缓存

强缓存是指缓存命中时,客户端不会向服务器发请求,浏览器F12能看到响应状态码为200sizefrom cache,它的实现有以下几种方式:

Expires - 绝对时间

示例:Expires:Thu,31 Dec 2037 23:59:59 GMT,就表示缓存有效期至2037年12月31日,在这之前浏览器都不会向服务器发请求了(除非按F5/Ctrl+F5刷新)。

Cache-Control - 相对时间/更多控制

绝对时间是一个绝对时间,因为计算时不方便;而且服务端是依据服务器的时间来返回,但客户端却需要依据客户的时间来判断,因此也容易失去控制。

Cache-Control有以下选项(可以多选):

  1. max-age: 指定一个时间长度,在这个时间段内缓存是有效的,单位是秒(s)。例如设置Cache-Control:max-age=31536000,也就是说缓存有效期为31536000/24/60/60=365天。
  2. s-maxage: 同max-age,覆盖max-age、Expires,但仅适用于共享缓存,在私有缓存中被忽略。
  3. public: 表明响应可以被任何对象(发送请求的客户端、代理服务器等等)缓存。
  4. private: 表明响应只能被单个用户(可能是操作系统用户、浏览器用户)缓存,是非共享的,不能被代理服务器缓存。
  5. no-cache: 强制所有缓存了该响应的用户,在使用已缓存的数据前,发送带验证器的请求到服务器。(不是字面意思上的不缓存)
  6. no-store: 禁止缓存,每次请求都要向服务器重新获取数据。
  7. must-revalidate: 指定如果页面是过期的,则去服务器进行获取。(意思是浏览器在某些情况下,缓存失效后仍可使用老缓存,加了这个头,失效后就必须验证,并不是字面上有没有过期都验证)

其中最有意思的要数no-cachemust-revalidate了,因为它们的表现都不是字面意义。

no-cache并不是字面上的不缓存,而是会一直服务端验证(真实意义很像字面上的must-revalidate)。

must-revalidate是只是为了给浏览器强调,缓存过期后,千万要遵守约定重新验证。

协商缓存

协商缓存是指缓存命中时,服务器返回Http状态码为304但无内容(Body),没命中时返回200有内容。

在要精细控制时,协商缓存比强缓存更有用,它有Last-ModifiedETag两种。

Last-Modified/If-Modify-Since(对比修改时间)

示例:

服务器:Last-Modified: Sat, 27 Jun 2015 16:48:38 GMT
客户端:If-Modified-Since: Sat, 27 Jun 2015 16:48:38 GMT

ETag/If-None-Match(对比校验码)

服务器:ETag: W/"0a0b8e05663d11:0"
客户端:If-None-Match: W/"0a0b8e05663d11:0"

清缓存要点

  1. F5刷新时,强缓存失效
  2. Ctrl+F5刷新时 强缓存和协商缓存都失效

ASP.NET Core的Http缓存

ASP.NET Core中提供了ResponseCacheAttribute来实现缓存,它的定义如下:

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = false, Inherited = true)]
public class ResponseCacheAttribute : Attribute, IFilterFactory, IFilterMetadata, IOrderedFilter
{
  public ResponseCacheAttribute();
  public string CacheProfileName { get; set; }
  public int Duration { get; set; }
  public bool IsReusable { get; }
  public ResponseCacheLocation Location { get; set; }
  public bool NoStore { get; set; }

  public int Order { get; set; }
  public string VaryByHeader { get; set; }
  public string[] VaryByQueryKeys { get; set; }
}

其中,ResponseCacheLocation定义了缓存的位置,是重点:

//   Determines the value for the "Cache-control" header in the response.
public enum ResponseCacheLocation
{
  //   Cached in both proxies and client. Sets "Cache-control" header to "public".
  Any = 0,
  //   Cached only in the client. Sets "Cache-control" header to "private".
  Client = 1,
  //   "Cache-control" and "Pragma" headers are set to "no-cache".
  None = 2
}

注意看源文件中的注释,Any表示Cache-Control: publicClient表示Cache-Control: privateNone表示Cache-Control: no-cache

注意ResponseCacheLocation并没有定义将缓存放到服务器的选项。

其中Duration表示缓存时间,单位为秒,它将翻译为max-age

另外可以通过VaryByHeaderVaryByQueryKeys来配置缓存要不要通过headerquery string来变化,其中VaryByHeader是通过Http协议中的Vary头来实现的,VaryByQueryKeys必须通过Middleware来实现。

不要误会,所有ResponseCacheAttribute的属性配置都不会在服务端缓存你的响应数据(虽然你可能有这种错觉),它和输出缓存不同,它没有状态,只用来做客户端强缓存。

如果不想缓存,则设置NoStore = true,它会设置cache-control: no-store,我们知道no-store的真实意思是不缓存。一般还会同时设置Location = ResponseCacheLocation.None,它会设置cache-control: no-cache(真实意思是表示一定会验证)。

注意单独设置Location = ResponseCacheLocation.None而不设置NoStore并不会有任何效果。

示例1

这是一个很典型的使用示例:

public class HomeController : Controller
{
  [ResponseCache(Duration = 3600, Location = ResponseCacheLocation.Client)]
  public IActionResult Data()
  {
    return Json(DateTime.Now);
  }
}

我定义了3600秒的缓存,并且cache-control应该为private,生成的Http缓存头可以通过如下C#代码来验证:

using var http = new HttpClient();
var resp1 = await http.GetAsync("https://localhost:55555/home/data");
Console.WriteLine(resp1.Headers.CacheControl.ToString());
Console.WriteLine(await resp1.Content.ReadAsStringAsync());

输入结果如下:

max-age=3600, private
"2020-03-07T21:35:01.5843686+08:00"

另外,ResponseCacheAttribute也可以定义在Controller级别上,表示整个Controller都受到缓存的影响。

CacheProfileName示例

另外,如果需要共用缓存配置,可以使用CacheProfileName,将缓存提前定义好,之后直接传入这个定义名即可使用:

.ConfigureServices(s =>
{
  s.AddControllers(o =>
  {
    o.CacheProfiles.Add("3500", new CacheProfile
    {
      Duration = 3500,
      Location = ResponseCacheLocation.Client,
    });
  });
});

这样我就定义了一个名为3500的缓存,稍后在Controller中我只需传入CacheProfileName = 3500即可:

public class HomeController : Controller
{
  [ResponseCache(CacheProfileName = "3500")]
  public IActionResult Data()
  {
    return Json(DateTime.Now);
  }
}

总结

Http缓存分为强缓存和协商缓存,ASP.NET Core提供了便利的ResponseCacheAttribute实现了强缓存,还能通过Profile来批量配置多个缓存点。

ASP.NET MVC并没有提供协商缓存实现,因为这些多半和业务逻辑相关,需要自己写代码。静态文件是特例,Microsoft.AspNetCore.StaticFiles中提供有,因为静态文件的逻辑很清晰。

ASP.NET中的OutputCacheAttributeASP.NET Core中不复存在,取而代之的是app/services.AddResponseCaching(),这些和Http协议不相关。

有机会我会具体聊聊这些缓存。

到此这篇关于ASP.NET Core中的Http缓存使用的文章就介绍到这了,更多相关ASP.NET Core Http缓存内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • Asp.Net Core2.1前后使用HttpClient的两种方式

    前言 在.Net Core应用开发中,调用第三方接口也是常有的事情,HttpClient使用人数.使用频率算是最高的一种了,在.Net Core中,HttpClient的使用方式随着版本的升级也发生了一些变化,本次就讲解一下Asp.Net Core2.1前后使用的两种方式. 一.原先HttpClient使用方式 一般来讲,喜欢要用的时候才会选择去获取资源,因此,当在有需求时才会用HttpClient去调用资源,便会使用如下这种方式或其它方式获取资源. //do something... usin

  • ASP.NET Core中间件计算Http请求时间示例详解

    ASP.NET Core通过RequestDelegate这个委托类型来定义中间件 public delegate Task RequestDelegate(HttpContext context); 可将一个单独的请求委托并行指定为匿名方法(称为并行中间件),或在类中对其进行定义.可通过Use,或在Middleware类中配置要传递给委托执行的方法(参数类型HttpContext,返回值类型Task). public static IApplicationBuilder Use(this IA

  • ASP.NET Core 1.0 部署 HTTPS(.NET Core 1.0)

    最近要做一个项目,正逢ASP.Net Core 1.0版本的正式发布.由于现代互联网的安全要求,HTTPS加密通讯已成主流,所以就有了这个方案. 本方案启发于一个旧版的解决方案: ASP.NET Core 1.0 部署 HTTPS (.NET Framework 4.5.1) http://www.cnblogs.com/qin-nz/p/aspnetcore-using-https-on-dnx451.html?utm_source=tuicool&utm_medium=referral  在

  • ASP.NET Core针对一个使用HttpClient对象的类编写单元测试详解

    介绍 几年前,微软引入了HttpClient类来替代HttpWebRequest来发送Web请求.这个新的类更易于使用,更加简洁,更具有异步性,且易于扩展. HttpClient类有一个可以接受HttpMessageHandler类对象的构造函数.HttpMessageHandler类对象可以接受一个请求(HttpRequestMessage), 并返回响应(HttpResponseMessage).它的功能完全取决于它的实现.默认情况下HttpClient使用的是HttpClientHandl

  • ASP.NET Core Kestrel 中使用 HTTPS (SSL)

    在ASP.NET Core中,如果在Kestrel中想使用HTTPS对站点进行加密传输,可以按照如下方式 申请证书 这一步就不详细说了,有免费的和收费的,申请完成之后会给你一个*.pfx结尾的文件. 添加NuGet包  nuget中查找然后再程序中添加引用Microsoft.AspNetCore.Server.Kestrel.Https 配置  把*.pfx结尾的文件拷贝的程序的Web根目录,然后修改Programs.cs文件: public class Program { public sta

  • ASP.NET Core中调整HTTP请求大小的几种方法详解

    一.前言 之所以称ASP.NET Core是一个Web开发平台,源于它具有一个极具扩展性的请求处理管道,我们可以通过这个管道的定制来满足各种场景下的HTTP处理需求.ASP. NET Core应用的很多特性,比如路由.认证.会话.缓存等,也同时定制消息处理管道来实现的.我们甚至可以通过管道定制在ASP.NET Core平台上创建我们自己的Web框架,实际上MVC和SingalR这两个重要的Web框架也是采用这样的方式创建的. HTTP协议自身的特性决定了任何一个Web应用的工作方式都是监听.接收

  • ASP.NET Core中的Http缓存使用

    Http响应缓存可减少客户端或代理对web服务器发出的请求数.响应缓存还减少了web服务器生成响应所需的工作量.响应缓存由Http请求中的header控制. 而ASP.NET Core对其都有相应的实现,并不需要了解里面的工作细节,即可对其进行良好的控制. 了解Http缓存 Http协议中定义了许多缓存,但总体可以分为强缓存和协商缓存两类. 强缓存 强缓存是指缓存命中时,客户端不会向服务器发请求,浏览器F12能看到响应状态码为200,size为from cache,它的实现有以下几种方式: Ex

  • ASP.NET Core中使用Redis实现缓存

    目录 一.前言 二.安装StackExchange.Redis 三.添加配置 四.Redis帮助类 五.添加服务依赖项 六.在控制器中使用 七.测试 一.前言 我们这里以StackExchange.Redis为例,讲解如何在ASP.NET Core中如何使用Redis实现缓存.首先需要安装Redis和RedisDesktopManager.RedisDesktopManager用来查看Redis缓存里面的数据.如何安装Redis这里不在讲述. 二.安装StackExchange.Redis 在N

  • Asp.net core中RedisMQ的简单应用实现

    最近一个外部的项目,使用到了消息队列,本来是用rabbitmq实现的,但是由于是部署到别人家的服务器上,想尽量简化一些,项目中本来也要接入了redis缓存,就尝试使用redis来实现简单的消息队列. 使用redis做消息队列有两种方法,一种是使用pub/sub,另一种是使用list结构,配合brpop来消费.这两种方式各有特点,这里简述一下: pub/sub模式,支持多客户端消费,但是不支持持久化,这就意味着客户端断开的时间内发布的消息将会全部舍弃掉. list配合brpop,默认不支持多客户端

  • 详解如何在ASP.NET Core中使用IHttpClientFactory

    利用IHttpClientFactory可以无缝创建HttpClient实例,避免手动管理它们的生命周期. 当使用ASP.Net Core开发应用程序时,可能经常需要通过HttpClient调用WebAPI的方法以检查终结点是否正常工作.要实现这一点,通常需要实例化HttpClient并使用该实例来调用你的方法.但是直接使用HttpClient也有一些缺点,主要与手动管理实例的生命周期有关. 你可以使用IHttpClientFactory创建HttpClient来避免这些问题.IHttpClie

  • ASP.NET Core中使用LazyCache的全过程

    前言 微软的 ASP.NET Core 已经是一个非常流行的用于构建 高性能, 模块化 并能运行在 Windows, Linux, MacOS 上的 WEB 框架,通常能够让程序保持高性能的一个有效途径就是通过缓存热链上的数据来应对高频的请求. LazyCache 是一款基于内存的易于使用和线程安全的缓存组件,值得注意的是,这里的 Lazy 指的是 LazyCache 永远不会在 缓存未命中 时触发一次以上的缓存委托函数,因为内置了锁,换句话说,Lazy 减少了不必要的计算开销,这篇文章我们将会

  • 如何在ASP.NET Core中使用HttpClientFactory

    ASP.Net Core 是一个开源的,跨平台的,轻量级模块化框架,可用它来构建高性能的Web程序,这篇文章我们将会讨论如何在 ASP.Net Core 中使用 HttpClientFactory. 为什么要使用 HttpClientFactory 可以用 HttpClientFactory 来集中化管理 HttpClient,工厂提供了对 HttpClient 的创建,配置和调度,值得一提的是:HttpClient 一直都是 Http 请求业务方面的一等公民. HttpClient 虽好,但它

  • ASP.Net Core中的日志与分布式链路追踪

    目录 .NET Core 中的日志 控制台输出 非侵入式日志 Microsoft.Extensions.Logging ILoggerFactory ILoggerProvider ILogger Logging Providers 怎么使用 日志等级 Trace.Debug 链路跟踪 OpenTracing 上下文和跟踪功能 跟踪单个功能 将多个跨度合并到一条轨迹中 传播过程中的上下文 分布式链路跟踪 在不同进程中跟踪 在 ASP.NET Core 中跟踪 OpenTracing API 和

  • ASP.NET Core中的Options选项模式

    1.前言 选项(Options)模式是对配置(Configuration)的功能的延伸.在12章(ASP.NET Core中的配置二)Configuration中有介绍过该功能(绑定到实体类.绑定至对象图.将数组绑定至类)而选项模式又有个选项类(TOptions),该选项类作用是指:把选项类中的属性与配置来源中的键关联起来.举个例,假设json文件有个Option1键,选项类中也有个叫Option1的属性名,经过选项配置,这样就能把json中的键的值映射到选项类属性值中.也可以理解在项目应用中,

  • 解析ASP.NET Core中Options模式的使用及其源码

    目录 1.Options模式的用法 2.Options模式源码解析 3.最佳实践 本章将和大家分享ASP.NET Core中Options模式的使用及其源码解析. 在ASP.NET Core中引入了Options这一使用配置方式,其主要是为了解决依赖注入时需要传递指定数据问题(不是自行获取,而是能集中配置).通常来讲我们会把所需要的配置通过IConfiguration对象配置成一个普通的类,并且习惯上我们会把这个类的名字后缀加上Options.所以我们在使用某一个中间件或者使用第三方类库时,经常

随机推荐