asp.net core 系列之Response caching(1)

這篇文章簡單的講解了response caching:

講解了cache-control，及對其中的頭和值的做用，及設置來控制response caching;

簡單的羅列了其餘的緩存技術：In-memory caching ， Distributed Cache ， Cache Tag Helper ， Distributed Cache Tag Helper ；

講解了使用ResponseCache attribute來控制response caching生成合適的頭

 主要翻譯於官網，水平有限，見諒

Overview

響應緩存減小了客戶端或者代理到web服務器的請求的次數。響應緩存也能夠減小web服務器的生成響應的執行的工做量。響應緩存被頭部控制，頭部指出了你想要客戶端，代理和中間件怎樣緩存響應。

ResponseCache attribute 參加設置響應緩存頭部，which clients may honor when caching responses. (當緩存響應時，客戶端會受這些屬性影響)。Response Caching Middleware 能夠被用來在服務器上緩存響應。 中間件可使用ResponseCacheAttribute屬性來影響服務端緩存行爲。 

HTTP-based response caching 

HTTP 1.1 Caching specification(規格，詳述，說明書)描述了網絡緩存應該怎樣表現(Internet caches should behave.) 。 主要的用於緩存的HTTP頭,是Cache-Control, 它被用於指定緩存指令。這個指令控制緩存行爲，當請求從客戶端到服務端的時候，而且當響應從服務端返回客戶端的時候。

公共的Cache-Control 指令在下表中被展現了：

其餘緩存頭在緩存中扮演的角色，羅列在下面了：

注意：Cache-Control，是用在從請求中的HTTP頭，能夠用來控制服務器中緩存行爲。

HTTP-based caching respects request Cache-Control directives

HTTP 1.1 Caching specification for the Cache-Control header (HTTP 1.1 緩存規格對於Cache-Control頭)要求一個緩存遵照一個有效的Cache-Control 頭，這個Cache-Control頭是被客戶端發送的。一個客戶端能夠發送一個帶no-cache的header值,而且強制要求服務器爲每一個請求生成一個新的響應。

老是遵照客戶端Cache-Control請求頭是有意義的，若是你考慮HTTP緩存的目標。在官方的說明書下，

緩存意味着減小潛在因素和網絡管理，對知足請求跨客戶端，代理和服務器網絡。它不是一種控制原服務器上的加載的必須的方式。

當使用Response Caching 中間件時，開發者是無法對緩存行爲控制的。由於中間件附着於官方緩存說明書。當決定提供一個緩存響應時,對這個中間件的計劃豐富(planned enhancements to the middleware)對於達到配置中間件來忽視請求的Cache-Control頭的目的，是一個機會(Planned enhancements to middleware are an opportunity to middleware to ignore a request’s Cache-Control header when deciding to serve a cached response.)。計劃的豐富提供了一個機會來更好的控制服務器加載。

Other caching technology in ASP.NET Core 在ASP.NET Core上的其餘緩存技術

• In-memory caching 內存緩存

　　　　In-memory caching 使用服務器內存來存儲緩存數據。這種類型的緩存適合使用sticky session（sticky:不動的）的一個或者多個服務器。Sticky sessions 意味着從客戶端發出的請求老是路由到同一臺服務器處理。

　　　　更多信息：Cache in-memory in ASP.NET Core.

• Distributed Cache 分佈式緩存

　　　　使用一個分佈式緩存來存儲數據在內存中，當應用部署在雲上或者服務器集羣上時。緩存是在這些處理請求的服務器之間共享的。客戶端能夠提交一個請求，請求能夠被組羣裏的任意服務器處理，若是緩存數據對於客戶端是可用的。ASP.NET Core提供了SQL Server和Redis分佈式緩存。

　　　　更多信息：Distributed caching in ASP.NET Core.

• Cache Tag Helper

　　　　使用Cache Tag從mvc頁面或者Razor Page中緩存內容。Cache Tag Helper用內存緩存數據。

　　　　更多信息：Cache Tag Helper in ASP.NET Core MVC

• Distributed Cache Tag Helper

　　　　在分佈式雲或者web集羣場景中使用Distributed Cache Tag Helper 來緩存Mvc view或者Razor Page中的內容。The Distributed Cache Tag Helper 用SQL Server或者Redis來緩存數據。

　　　　更多信息：Distributed Cache Tag Helper in ASP.NET Core.

ResponseCache attribute

爲了在response caching (響應緩存)上設置合適的頭,ResponseCacheAttribute 指出了必須的參數。(即，能夠經過ResponseCacheAttribute,設置response caching上的頭的值)

注意：對於包含驗證信息的客戶端內容，不容許緩存。對於那些不會基於用戶的身份或者用戶是否登陸而改變的內容，才應該容許被緩存。

VaryByQueryKeys 隨着給出的query keys的集合的值，改變存儲的響應。When a single value of * is provided, the middleware varies responses by all request query string parameters. 

Response Caching Middleware 必須被容許設置VaryByQueryKeys屬性。不然，一個運行時異常會被拋出。對於VaryByQueryKeys屬性，並無一個對應的HTTP頭部。這個屬性是一個被Response Caching Middleware 處理的HTTP 功能。對於中間件提供一個緩存的響應，查詢字符串和查詢字符串值必須匹配以前的請求.(即,若是查詢字符串和查詢字符串值和以前的同樣時,中間件會直接返回一個緩存的響應;不然，返回一個新的響應。)例如，考慮下表中的一系列的請求和結果：

第一個請求被服務器返回，而且緩存到中間件中。第二個請求是被中間件返回，由於查詢字符串匹配以前的請求。第三個請求不是在中間件緩存中的，由於查詢字符串值不匹配以前的請求。

ResponseCacheAttribute用於配置和建立一個ResponseCacheFilter.    

ResponseCacheFilter執行的工做，更新合適的HTTP頭和響應的功能(即,ResponseCacheAttribute的功能)。The filter:

• 移除任何存在的Vary, Cache-Control, Pragma頭部

• 根據設置在ResponseCacheAttribute中的屬性輸出合適的頭部

• 更新the response caching HTTP feature若是VaryByQueryKeys被設置了

Vary

這個頭部會被寫，當VaryByHeader屬性被設置了。這個屬性(VaryByHeader)設置Vary屬性的值。下面是使用VaryByHeader屬性的例子：

[ResponseCache(VaryByHeader = "User-Agent", Duration = 30)] public class Cache1Model : PageModel
{

用這個例子，使用瀏覽器工具觀察response headers(響應頭)。 下面的響應頭隨着Cache1 page response 被髮送了。

Cache-Control: public,max-age=30
Vary: User-Agent

NoStore and Location.None

NoStore重寫了大部分的其餘屬性。當這個屬性被設置爲true，Cache-Control頭被設置爲no-store.

若是Location設置爲None:

• Cache-Control 設置爲no-store, no-cache

• Pragma設置爲no-cache.

若是NoStore是false而且Location是None，Cache-Control ,和Pragma被設置爲no-cache.

NoStore是典型的被設置爲true，爲了error pages. 示例中的Cache2 page生成響應頭，指示客戶端不要存儲響應。

[ResponseCache(Duration = 0, Location = ResponseCacheLocation.None, NoStore = true)] public class Cache2Model : PageModel
{

這個示例應用返回Cache2 page 帶有下面的頭：

Cache-Control: no-store,no-cache
Pragma: no-cache

Location and Duration

爲了能夠緩存，Duration必須被設置爲一個積極的值而且Location必須是任意的或者Client. 這種狀況下，Cache-Control頭被設置爲location的值，而且跟着一個響應的max-age.

注意：

Location’s options of Any and Client轉化爲Cache-Control頭的值分別爲public和private. 正如以前提到的，設置Location爲None會設置Cache-Control和Pramga頭爲no-cache:

[ResponseCache(Duration = 10, Location = ResponseCacheLocation.Any, NoStore = false)] public class Cache3Model : PageModel
{

示例應用返回的Cache3 page 帶有下面的頭：

Cache-Control: public,max-age=10

Cache profiles

取代重複的在不少controller action attributes響應緩存設置，cache profiles 能夠被設置爲options，當在Startup.ConfigureService中設置MVC/Razor Pages. 在引用的cache profiles中發現的值被用做默認值,隨着ResponseCacheAttribute而且被這個attribute上指定的任意properties重寫。(即不少重複的響應緩存設置能夠在Startup.ConfigureService中設置,再隨着ResponseCacheAttribute設置在action上)

創建一個cache profile. 下面的例子展現了30秒的cache profile，在示例應用的Startup.ConfigureServices:

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc(options =>
    {
        options.CacheProfiles.Add("Default30", new CacheProfile() { Duration = 30 });
    }).SetCompatibilityVersion(CompatibilityVersion.Version_2_2);
}

這個示例應用的Cache4 page model 引用了Default30 cache profile:

[ResponseCache(CacheProfileName = "Default30")] public class Cache4Model : PageModel
{

這個ResponseCacheAttribute能夠被用在：

• Razor Page handlers(classes) - 屬性能夠被用處處理方法

• MVC controllers(classes)

• MVC actions (methods) - Method-level attributes override the settings specified in class level attributes. 方法級別的會覆蓋類級別的

被Default30 profile致使的應用於Cache4 page response 的頭是：

Cache-Control: public,max-age=30

 

下一篇：Cache in-memory

 參考資料：

https://docs.microsoft.com/en-us/aspnet/core/performance/caching/response?view=aspnetcore-2.2