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
【精選推薦文章】
自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象
網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!
評比前十大台北網頁設計、台北網站設計公司知名案例作品心得分享
台北網頁設計公司這麼多,該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"