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

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

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

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

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

По промежуточному слоям кэширования ответа:

• Включает кэширование ответов сервера на основе заголовков кэша HTTP. Реализует стандартную семантику кэширования HTTP. Кэши на основе заголовков кэша HTTP, таких как прокси-серверы.
• Обычно не подходит для приложений пользовательского интерфейса, таких как Pages, так как Razor браузеры обычно задают заголовки запросов, которые предотвращают кэширование. Кэширование выходных данных, доступное в ASP.NET Core 7.0 и более поздних версий, обеспечивает преимущества приложений пользовательского интерфейса. При кэшировании выходных данных конфигурация решает, что следует кэшировать независимо от заголовков HTTP.
• Может оказаться полезным для общедоступных запросов GET или HEAD API от клиентов, где выполняются условия кэширования .

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

Кэширование ответа на основе 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. В рамках официальной спецификации кэширование предназначено для уменьшения задержки и сетевой нагрузки на выполнение запросов в сети клиентов, прокси-серверов и серверов. Это не обязательно способ управления нагрузкой на исходном сервере.

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

Атрибут ResponseCache

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

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

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

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

Используется ResponseCacheAttribute для настройки и создания (с помощью IFilterFactory) Microsoft.AspNetCore.Mvc.Internal.ResponseCacheFilter. Выполняет 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 имеет значение и NoneLocation имеет false значение , 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, см. в статье "Добавление ResponseCacheAttribute в глобальный список фильтров MVC" не применяется к Razor Страницам (dotnet/aspnetcore #18890). Пример, приведенный в примечании проблемы, был написан для приложений, предназначенных для ASP.NET Core до выпуска минимальных API в версии 6.0. Для приложений версии 6.0 или более поздних версий измените регистрацию службы в примере builder.Services.AddSingleton... на Program.cs.

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

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

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

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

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

Заголовки элементов управления кэшем предоставляют рекомендации клиентам и промежуточным прокси-серверам, когда и как кэшировать ответы. Нет никаких гарантий, что клиенты и прокси-серверы будут учитывать 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 Pages. Значения, найденные в профиле кэша со 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] можно применить к:

• Razor Pages: атрибуты нельзя применять к методам обработчика. Браузеры, используемые с приложениями пользовательского интерфейса, предотвращают кэширование ответов.
• Контроллеры MVC.
• Методы действий 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());
}

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

• Хранение ответов в кэшах
• Элемент управления cache-control
• Кэширование в памяти в ASP.NET Core
• Распределенное кэширование в ASP.NET Core
• Обнаружение изменений с помощью маркеров изменений в ASP.NET Core
• ПО промежуточного слоя для кэширования ответов в ASP.NET Core
• Вспомогательный компонент тега кэша в ASP.NET Core MVC
• Вспомогательный компонент тега распределенного кэша в 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 и NCache .

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

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

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

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

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

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

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

Атрибут ResponseCache

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

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

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

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

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

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

Изменчивость

Этот заголовок записывается только при 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 имеет значение и NoneLocation имеет false значение , 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 приложения, Razor добавьте его с фильтром MVC или Razor фильтром Pages.

В приложении 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Параметры и переводятся в Cache-Control значения заголовков public Any и privateсоответственно.Client Как отмечалось в разделе NoStore и Location.None, для параметра None Location заданы оба 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