Кэширование ответов в ASP.NET Core

Кэширование ответов уменьшает количество запросов, выполняемых клиентом или прокси-сервером. Кэширование ответов также уменьшает объем работы веб-сервера для создания ответа. Кэширование ответов задается в заголовках.

Атрибут ResponseCache задает заголовки кэширования ответов. Клиенты и промежуточные прокси-серверы должны учитывать заголовки для кэширования ответов в соответствии со спецификацией кэширования HTTP 9111.

Для кэширования на стороне сервера, соответствующего спецификации кэширования HTTP 1.1, используйте посредник кэширования ответа. Промежуточное программное обеспечение может использовать ResponseCacheAttribute свойства для влияния на поведение серверного кэширования.

Промежуточное программное обеспечение для кэширования ответов включает кэширование ответов сервера на основе заголовков HTTP Cache-Control.

• Поведение кэширования реализует стандартную семантику кэширования HTTP.

• Кэширование основано на заголовках кэша HTTP, аналогичных методу, используемому прокси-серверами.

• Эта форма кэширования полезна для общедоступных запросов GET или HEAD API от клиентов, в которых выполнены условия кэширования .

• Для приложений пользовательского интерфейса, таких как Razor Pages, кэширование ответов обычно не является полезным. Браузеры обычно задают заголовки запросов, которые предотвращают кэширование.

  Кэширование вывода (доступно в .NET 7 и более поздних версиях) является лучшим подходом для приложений пользовательского интерфейса. В этом сценарии конфигурация определяет, что кэшировать независимо от заголовков HTTP.

Чтобы проверить кэширование ответов, используйте Fiddler или другое средство, которое может явно задать заголовки запросов. Для тестирования кэширования предпочтительнее явно задать заголовки. Дополнительные сведения см. в разделе "Устранение неполадок промежуточного слоя кэширования ответов>".

Просмотреть или скачать образец кода (описание загрузки)

Кэширование ответа на основе HTTP

Спецификация RFC 9111: HTTP Caching описывает, как должны вести себя интернет-кэши. Основной заголовок HTTP, используемый для кэширования, — cache-Control, который используется для указания директив кэша. Директивы управляют поведением кэширования, так как запросы делают свой путь от клиентов к серверам и ответам делают свой путь от серверов обратно к клиентам. Запросы и ответы перемещаются через прокси-серверы, а прокси-серверы также должны соответствовать спецификации кэширования HTTP 1.1.

Общие Cache-Control директивы показаны в следующей таблице.

Другие заголовки кэша, которые играют роль в кэшировании, показаны в следующей таблице.

Кэширование на основе HTTP учитывает директивы cache-Control для запросов

Спецификация RFC 9111: кэширование HTTP (раздел 5.2. Cache-Control) требует кэша для учета допустимого Cache-Control заголовка, отправленного клиентом. Клиент может выполнять запросы с заголовком no-cache, что заставляет сервер генерировать новый ответ на каждый запрос.

Всегда учитывать заголовки запросов клиентов Cache-Control имеет смысл, если учесть цель кэширования HTTP. В рамках официальной спецификации кэширование предназначено для уменьшения задержки и сетевой нагрузки на выполнение запросов в сети клиентов, прокси-серверов и серверов. Это не обязательно способ управления нагрузкой на исходном сервере.

При использовании посреднического слоя кэширования ответа разработчики не имеют никакого контроля над поведением кэширования, потому что слой следует официальной спецификации кэширования. .NET 7 и более поздних версий включают поддержку кэширования вывода для лучшего контроля нагрузки на сервер. Дополнительные сведения см. в разделе "Кэширование выходных данных".

Атрибут ResponseCache

Класс ResponseCacheAttribute задает параметры, необходимые для задания соответствующих заголовков в кэшировании ответа.

Свойство VaryByQueryKeys изменяет хранимый ответ в зависимости от значений заданного списка ключей запроса. Если предоставляется одно значение подстановочного знака звёздочка (*), промежуточное программное обеспечение варьирует ответы по всем параметрам строки запроса.

Промежуточное ПО кэширования ответов должно быть включено, чтобы задать свойство VaryByQueryKeys. В противном случае выбрасывается исключение среды выполнения. Для свойства VaryByQueryKeys отсутствует соответствующий заголовок HTTP. Это свойство является функцией HTTP, обрабатываемой промежуточным программным обеспечением для кэширования ответов. Чтобы ПО промежуточного слоя служило кэшированному ответу, строка запроса и значение строки запроса должны соответствовать предыдущему запросу. Например, рассмотрим последовательность запросов и результатов, показанных в следующей таблице:

Сервер возвращает первый запрос, а ПО промежуточного слоя кэширует запрос. ПО промежуточного слоя возвращает второй запрос, так как строка запроса соответствует предыдущему (первому) запросу. Третий запрос не в кэше ПО промежуточного слоя, так как значение строки запроса не соответствует предыдущему запросу.

Класс ResponseCacheAttribute используется, чтобы настраивать и создавать Microsoft.AspNetCore.Mvc.Internal.ResponseCacheFilter через интерфейс IFilterFactory. Компонент ResponseCacheFilter выполняет работу по обновлению соответствующих заголовков HTTP и характеристик ответа. Фильтр:

• Удаляет все существующие заголовки для Vary, Cache-Controlи Pragma.
• Записывает соответствующие заголовки на основе свойств, заданных в файле ResponseCacheAttribute.
• Обновляет функцию кэширования ответа HTTP, если свойство VaryByQueryKeys задано.

Различаемый заголовок

Этот заголовок записывается только при установке свойства VaryByHeader. Для свойства задано Vary значение свойства. В следующем примере используется VaryByHeader свойство:

[ApiController]
public class TimeController : ControllerBase
{
    [Route("api/[controller]")]
    [HttpGet]
    [ResponseCache(VaryByHeader = "User-Agent", Duration = 30)]
    public ContentResult GetTime() => Content(
                      DateTime.Now.Millisecond.ToString());

Используйте Fiddler или другое средство для просмотра заголовков ответа. К заголовкам ответа относятся:

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

Предыдущий код требует добавления метода служб AddResponseCaching промежуточного слоя кэширования ответа в коллекцию служб. Код настраивает приложение для использования промежуточного программного обеспечения с методом расширения UseResponseCaching.

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();
builder.Services.AddResponseCaching();

var app = builder.Build();

app.UseHttpsRedirection();

// UseCors must be called before UseResponseCaching
//app.UseCors();

app.UseResponseCaching();

app.UseAuthorization();

app.MapControllers();

app.Run();

Свойства NoStore и 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 для страниц ошибок. Следующий код создает заголовки ответов, которые указывают клиенту не хранить ответ.

[Route("api/[controller]/ticks")]
[HttpGet]
[ResponseCache(Location = ResponseCacheLocation.None, NoStore = true)]
public ContentResult GetTimeTicks() => Content(
                  DateTime.Now.Ticks.ToString());

Приведенный выше код содержит следующие заголовки в ответе:

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

Чтобы применить ResponseCacheAttribute ко всем контроллерам MVC приложения или страницам Razor, добавьте атрибут с фильтром MVC или Razor фильтром Pages.

В приложении MVC добавьте следующий код:

builder.Services.AddControllersWithViews().AddMvcOptions(options => 
    options.Filters.Add(
        new ResponseCacheAttribute
        {
            NoStore = true, 
            Location = ResponseCacheLocation.None
        }));

Для подхода, применимого к приложениям Razor Pages, см. вопрос на GitHub dotnet/aspnetcore #18890 - . Добавление ResponseCacheAttribute в глобальный список фильтров MVC не применяется к Razor Pages. Пример комментария в этой проблеме относится к приложениям ASP.NET Core, которые существовали до выхода Minimal APIs (ASP.NET Core версии 6.0). Для приложений, предназначенных для версии 6.0 и более поздних версий, измените регистрацию службы, используемую в примере builder.Services.AddSingleton... в файле Program.cs .

Свойства расположения и длительности

Чтобы включить кэширование, Duration свойство должно иметь положительное значение и Location должно иметь значение Any (по умолчанию) или Client. Фреймворк устанавливает заголовок Cache-Control до значения местоположения, после чего идет max-age ответа.

Параметры свойства Location и Any переводятся в значения заголовков Client для Cache-Control и public, и private, соответственно. Как отмечалось в разделе NoStore и Location.None, установка свойства Location в значение None также устанавливает заголовки Cache-Control и Pragma в значение no-cache.

Параметр Location.Any свойства (Cache-Control установлен на public) указывает, что клиент или любой промежуточный прокси-сервер могут кэшировать значение, включая промежуточное программное обеспечение кэширования ответов.

Параметр свойства Location.Client (установленный на Cache-Controlprivate) указывает, что только клиент может кэшировать значение. Никакой промежуточный кэш не должен кэшировать значение, включая посредник кэширования ответов.

Заголовки элементов управления кэшем предоставляют рекомендации клиентам и промежуточным прокси-серверам о том, когда и как кэшировать ответы. Нет никаких гарантий, что клиенты и прокси-серверы соблюдают спецификацию RFC 9111: кэширование HTTP . Промежуточное программное обеспечение кэширования ответа всегда следует правилам кэширования, изложенным в спецификации.

В следующем примере показаны заголовки, созданные путем задания свойства Duration и оставления значения свойства Location по умолчанию:

[Route("api/[controller]/ms")]
[HttpGet]
[ResponseCache(Duration = 10, Location = ResponseCacheLocation.Any, NoStore = false)]
public ContentResult GetTimeMS() => Content(
                  DateTime.Now.Millisecond.ToString());

Приведенный выше код содержит следующие заголовки в ответе:

Cache-Control: public,max-age=10

Профили кэша

Вместо дублирования настроек кэша ответов во многих атрибутах действия контроллера профили кэша можно настроить как параметры при настройке страниц MVC или Razor страниц. Значения, найденные в профиле кэша со ссылкой, используются в качестве значений по умолчанию ResponseCacheAttribute. Все свойства, указанные в атрибуте, переопределяют указанные значения профиля кэша.

В следующем примере показан 30-секундный профиль кэша:

using Microsoft.AspNetCore.Mvc;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCaching();
builder.Services.AddControllers(options =>
{
    options.CacheProfiles.Add("Default30",
        new CacheProfile()
        {
            Duration = 30
        });
});

var app = builder.Build();

app.UseHttpsRedirection();

// UseCors must be called before UseResponseCaching
//app.UseCors();

app.UseResponseCaching();

app.UseAuthorization();

app.MapControllers();

app.Run();

Следующий код ссылается на профиль кэша Default30 :

[ApiController]
[ResponseCache(CacheProfileName = "Default30")]
public class Time2Controller : ControllerBase
{
    [Route("api/[controller]")]
    [HttpGet]
    public ContentResult GetTime() => Content(
                      DateTime.Now.Millisecond.ToString());

    [Route("api/[controller]/ticks")]
    [HttpGet]
    public ContentResult GetTimeTicks() => Content(
                      DateTime.Now.Ticks.ToString());
}

Результирующий ответ заголовка профиля кэша Default30 включает:

Cache-Control: public,max-age=30

Атрибут [ResponseCache] можно применить к Pages, контроллерам MVC и методам действий MVC.

В Razor Pages нельзя применять атрибуты к методам обработчика, так как браузеры, используемые с приложениями пользовательского интерфейса, предотвращают кэширование ответов. В методе действия MVC атрибуты уровня метода переопределяют параметры, указанные в атрибутах уровня класса.

Следующий код применяет [ResponseCache] атрибут на уровне контроллера и уровне метода:

[ApiController]
[ResponseCache(VaryByHeader = "User-Agent", Duration = 30)]
public class Time4Controller : ControllerBase
{
    [Route("api/[controller]")]
    [HttpGet]
    public ContentResult GetTime() => Content(
                      DateTime.Now.Millisecond.ToString());

    [Route("api/[controller]/ticks")]
    [HttpGet]
    public ContentResult GetTimeTicks() => Content(
                  DateTime.Now.Ticks.ToString());

    [Route("api/[controller]/ms")]
    [HttpGet]
    [ResponseCache(Duration = 10, Location = ResponseCacheLocation.Any, NoStore = false)]
    public ContentResult GetTimeMS() => Content(
                      DateTime.Now.Millisecond.ToString());
}

Связанный контент

• Хранение ответов в кэшах — RFC 9111: кэширование HTTP (раздел 3)
• Cache-Control — RFC 9111: кэширование HTTP (раздел 5.2)
• Кэширование в памяти в ASP.NET Core
• Распределенное кэширование в ASP.NET Core
• Промежуточное ПО кэширования ответов в ASP.NET Core

Просмотреть или скачать образец кода (описание загрузки)

Кэширование ответов уменьшает количество запросов, выполняемых клиентом или прокси-сервером. Кэширование ответов также уменьшает объем работы веб-сервера для создания ответа. Кэширование ответов управляется заголовками, которые указывают, как клиент, прокси-сервер и промежуточное программное обеспечение должны кэшировать ответы.

Он [ResponseCache] участвует в настройке заголовков кэширования ответов. Клиенты и промежуточные прокси-серверы должны учитывать заголовки для кэширования ответов согласно RFC 9111: кэширование HTTP.

Для кэширования на стороне сервера, следующего за спецификацией кэширования HTTP 1.1, используйте ПО промежуточного слоя кэширования ответа. Промежуточное ПО использует [ResponseCache] свойства для задания заголовков кэширования на стороне сервера.

Кэширование ответа на основе HTTP

RFC 9111: кэширование HTTP описывает поведение кэшей Интернета. Основной заголовок HTTP, используемый для кэширования, — cache-Control, который используется для указания директив кэша. Директивы управляют поведением кэширования, так как запросы делают свой путь от клиентов к серверам и как ответы делают свой путь от серверов обратно к клиентам. Запросы и ответы перемещаются через прокси-серверы, а прокси-серверы также должны соответствовать спецификации кэширования HTTP 1.1.

Общие Cache-Control директивы показаны в следующей таблице.

Другие заголовки кэша, которые играют роль в кэшировании, показаны в следующей таблице.

Кэширование на основе HTTP учитывает директивы cache-Control для запросов

RFC 9111: кэширование HTTP (раздел 5.2. Cache-Control) требует кэша для учета допустимого Cache-Control заголовка, отправленного клиентом. Клиент может выполнять запросы с заголовком no-cache, что заставляет сервер генерировать новый ответ на каждый запрос.

Всегда учитывать заголовки запросов клиентов Cache-Control имеет смысл, если учесть цель кэширования HTTP. В рамках официальной спецификации кэширование предназначено для уменьшения задержки и сетевой нагрузки на выполнение запросов в сети клиентов, прокси-серверов и серверов. Это не обязательно способ управления нагрузкой на исходном сервере.

При использовании промежуточного слоя кэширования ответов разработчик не имеет контроля над этим поведением кэширования, так как программное обеспечение соответствует официальной спецификации кэширования. Поддержка кэширования выходных данных для лучшего управления нагрузкой на сервер является проектным предложением для будущего выпуска ASP.NET Core. Дополнительные сведения см. в разделе "Добавление поддержки кэширования выходных данных" (dotnet/aspnetcore #27387).

Другие технологии кэширования в ASP.NET Core

Кэширование в памяти

Кэширование в памяти использует память сервера для хранения кэшированных данных. Этот тип кэширования подходит для одного сервера или нескольких серверов, использующих сходство сеансов. Сходство сеансов также называется липкими сеансами. Сходство сеансов означает, что запросы от клиента всегда направляются на тот же сервер для обработки.

Дополнительные сведения см. в разделе "Кэш в памяти" в ASP.NET Core и Устранение проблем с привязкой сеансов в Шлюзе приложений Azure.

Распределенный кэш

Используйте распределенный кэш для хранения данных в памяти, когда приложение размещается в облачной или серверной ферме. Кэш используется на серверах, обрабатывающих запросы. Клиент может отправить запрос, который обрабатывается любым сервером в группе, если кэшированные данные для клиента доступны. ASP.NET Core работает с распределенными кэшами SQL Server, Redis, Postgres и NCache .

Дополнительные сведения см. в статье Распределенное кэширование в ASP.NET Core.

Помощник тегов кэша

Кэшируйте содержимое из представления или Razor страницы MVC с помощью вспомогательного средства тега кэша. Вспомогательный элемент тега кэша использует кэширование в памяти для хранения данных.

Дополнительные сведения см. в Помощнике тегов кеша в ASP.NET Core MVC.

Вспомогательная функция тега распределенного кэша

Кэшируйте содержимое из представления MVC или страницы Razor в сценариях распределенной облачной среды или веб-фермы с помощью помощника тега для распределенного кэша. Помощник по тегу распределенного кэша использует SQL Server, Redis или NCache для хранения данных.

Дополнительные сведения см. в разделе Тег вспомогательной программы распределенного кэша в ASP.NET Core.

Атрибут ResponseCache

Параметры, которые указывает ResponseCacheAttribute, необходимы для установки соответствующих заголовков в кэшировании ответа.

VaryByQueryKeys изменяет сохраненный ответ на основе значений заданного списка ключевых запросов. Если указано одно значение *, промежуточное ПО варьирует ответы в зависимости от всех параметров строки запроса.

Чтобы задать свойство, необходимо включить промежуточное программное обеспечение кэширования ответовVaryByQueryKeys. В противном случае выбрасывается исключение среды выполнения. Соответствующий заголовок HTTP для свойства VaryByQueryKeys отсутствует. Это свойство HTTP обрабатывается промежуточным программным обеспечением кэширования ответа. Чтобы ПО промежуточного слоя служило кэшированному ответу, строка запроса и значение строки запроса должны соответствовать предыдущему запросу. Например, рассмотрим последовательность запросов и результатов, показанных в следующей таблице.

Первый запрос возвращается сервером и кэшируется в ПО промежуточного слоя. Второй запрос возвращается ПО промежуточного слоя, так как строка запроса соответствует предыдущему запросу. Третий запрос не в кэше ПО промежуточного слоя, так как значение строки запроса не соответствует предыдущему запросу.

Для настройки и создания Microsoft.AspNetCore.Mvc.Internal.ResponseCacheFilter (с помощью IFilterFactory) используется ResponseCacheAttribute. ResponseCacheFilter обновляет соответствующие заголовки HTTP и характеристики ответа. Фильтр:

• Удаляет все существующие заголовки для Vary, Cache-Controlи Pragma.
• Записывает соответствующие заголовки на основе свойств, заданных в файле ResponseCacheAttribute.
• Обновляет функцию кэширования ответа HTTP, если VaryByQueryKeys задана.

Vary

Этот заголовок записывается только когда свойство установлено VaryByHeader. Свойство, установленное значением свойства Vary. В следующем примере используется VaryByHeader свойство:

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

Используя пример приложения, просмотрите заголовки ответа с помощью сетевых средств браузера. Следующие заголовки ответов отправляются с ответом на страницу "Cache1":

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

NoStore и 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 для страниц с ошибками. Страница Cache2 в примере приложения создает заголовки ответов, которые указывают клиенту не хранить ответ.

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

Пример приложения возвращает страницу Cache2 со следующими заголовками:

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

Чтобы применить ResponseCacheAttribute для всех контроллеров MVC или страниц приложения, добавьте его с фильтром MVC или фильтром страниц Razor.

В приложении MVC:

services.AddMvc().AddMvcOptions(options => 
    options.Filters.Add(
        new ResponseCacheAttribute
        {
            NoStore = true, 
            Location = ResponseCacheLocation.None
        }));

Подход, который применим к приложениям Razor Pages, см. в статье «Добавление ResponseCacheAttribute в глобальный список фильтров MVC» не применяется к Razor Страницам (dotnet/aspnetcore #18890).

Расположение и длительность

Чтобы включить кэширование, Duration необходимо задать положительное значение и Location иметь значение Any (по умолчанию) или Client. Фреймворк задает Cache-Control заголовок значению расположения, после которого следует max-age ответа.

Location параметры Any и Client переводятся в значения заголовков Cache-Controlpublic и private соответственно. Как отмечалось в разделе NoStore и Location.None, установка Location на None приводит к тому, что как Cache-Control, так и Pragma заголовки устанавливаются на no-cache.

Location.Any(Cache-Control задано public) указывает, что клиент или любой промежуточный прокси-сервер могут кэшировать значение, включая ПО промежуточного слоя кэширования ответа.

Location.Client (Cache-Control задано значение private) указывает, что только клиент может кэшировать значение. Никакой промежуточный кэш не должен кэшировать значение, включая посредник кэширования ответов.

Заголовки элементов управления кэшем просто предоставляют рекомендации клиентам и промежуточным прокси-серверам, когда и как кэшировать ответы. Нет никаких гарантий, что клиенты и прокси-серверы будут учитывать RFC 9111: кэширование HTTP. Промежуточное программное обеспечение кэширования ответа всегда следует правилам кэширования, изложенным в спецификации.

В следующем примере показана модель страницы Cache3 из примера приложения и заголовки, созданные установкой параметра Duration и сохранением значения по умолчанию Location.

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

Пример приложения возвращает страницу Cache3 со следующим заголовком:

Cache-Control: public,max-age=10

Профили кэша

Вместо дублирования настроек кэша ответов в атрибутах действий многих контроллеров, профили кэша можно настроить как опции при конфигурации MVC/Razor Pages в Startup.ConfigureServices. Значения, найденные в профиле кэша со ссылкой ResponseCacheAttribute, используются по умолчанию, но могут быть переопределены любыми свойствами, указанными в атрибуте.

Настройка профиля кэша. В следующем примере показан 30-секундный профиль кэша в примере приложения Startup.ConfigureServices:

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

Модель страницы "Кэш4" в примере приложения ссылается на профиль кэша Default30.

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

К ResponseCacheAttribute можно применить:

• Razor Pages: атрибуты нельзя применять к методам обработчика.
• Контроллеры MVC.
• Методы действий MVC: атрибуты уровня метода переопределяют параметры, указанные в атрибутах уровня класса.

Результирующий заголовок, который применен к ответу страницы Cache4 профилем кэша Default30:

Cache-Control: public,max-age=30

Дополнительные ресурсы

• Хранение ответов в кэшах
• RFC 9111: кэширование HTTP (раздел 5.2. Cache-Control)
• Кэширование в памяти в ASP.NET Core
• Распределенное кэширование в ASP.NET Core
• Обнаружение изменений с помощью маркеров изменений в ASP.NET Core
• Промежуточное программное обеспечение для кэширования ответов в ASP.NET Core
• Вспомогательный компонент тега кэша в ASP.NET Core MVC
• Вспомогательный компонент тега распределенного кэша в ASP.NET Core