Buforowanie odpowiedzi na platformie ASP.NET Core
Autorzy: Rick Anderson i Kirk Larkin
Wyświetl lub pobierz przykładowy kod (jak pobrać)
Buforowanie odpowiedzi zmniejsza liczbę żądań wysyłanych przez klienta lub serwer proxy do serwera internetowego. Buforowanie odpowiedzi zmniejsza również ilość pracy wykonywanej przez serwer internetowy w celu wygenerowania odpowiedzi. Buforowanie odpowiedzi jest ustawiane w nagłówkach.
Atrybut ResponseCache ustawia nagłówki buforowania odpowiedzi. Klienci i pośrednie serwery proxy powinny honorować nagłówki dla odpowiedzi buforowania w obszarze RFC 9111: buforowanie HTTP.
W przypadku buforowania po stronie serwera, która jest zgodna ze specyfikacją buforowania HTTP 1.1, użyj oprogramowania pośredniczącego buforowania odpowiedzi. Oprogramowanie pośredniczące może używać ResponseCacheAttribute właściwości do wywierania wpływu na zachowanie buforowania po stronie serwera.
Oprogramowanie pośredniczące buforowania odpowiedzi:
- Włącza buforowanie odpowiedzi serwera na podstawie nagłówków pamięci podręcznej HTTP. Implementuje standardową semantykę buforowania HTTP. Pamięci podręczne oparte na nagłówkach pamięci podręcznej HTTP, takich jak serwery proxy.
- Zazwyczaj nie jest korzystne dla aplikacji interfejsu użytkownika, takich jak Razor Strony, ponieważ przeglądarki zwykle ustawiają nagłówki żądań, które uniemożliwiają buforowanie. Buforowanie danych wyjściowych, które jest dostępne w programie ASP.NET Core 7.0 lub nowszym, zapewnia korzyści aplikacjom interfejsu użytkownika. W przypadku buforowania danych wyjściowych konfiguracja decyduje, co powinno być buforowane niezależnie od nagłówków HTTP.
- Może być korzystne w przypadku publicznych żądań GET lub HEAD API od klientów, na których spełnione są warunki buforowania .
Aby przetestować buforowanie odpowiedzi, użyj programu Fiddler lub innego narzędzia, które może jawnie ustawić nagłówki żądań. Jawne ustawianie nagłówków jest preferowane do testowania buforowania. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów.
Buforowanie odpowiedzi oparte na protokole HTTP
RFC 9111: Buforowanie HTTP opisuje, jak powinny zachowywać się pamięci podręczne internetowe. Podstawowy nagłówek HTTP używany do buforowania to Cache-Control, który służy do określania dyrektyw pamięci podręcznej. Dyrektywy kontrolują zachowanie buforowania, gdy żądania w drodze od klientów do serwerów i w miarę reagowania wracają z serwerów z powrotem do klientów. Żądania i odpowiedzi przechodzą przez serwery proxy, a serwery proxy muszą być również zgodne ze specyfikacją buforowania HTTP 1.1.
Typowe Cache-Control
dyrektywy przedstawiono w poniższej tabeli.
Dyrektywa | Akcja |
---|---|
public | Pamięć podręczna może przechowywać odpowiedź. |
private | Odpowiedź nie może być przechowywana przez udostępnioną pamięć podręczną. Prywatna pamięć podręczna może przechowywać i ponownie używać odpowiedzi. |
maksymalny wiek | Klient nie akceptuje odpowiedzi, której wiek jest większy niż określona liczba sekund. Przykłady: max-age=60 (60 sekund), max-age=2592000 (1 miesiąc) |
brak pamięci podręcznej | W przypadku żądań: pamięć podręczna nie może używać przechowywanej odpowiedzi w celu spełnienia żądania. Serwer pochodzenia ponownie generuje odpowiedź klienta, a oprogramowanie pośredniczące aktualizuje przechowywaną odpowiedź w pamięci podręcznej. W odpowiedziach: odpowiedź nie może być używana dla kolejnego żądania bez sprawdzania poprawności na serwerze pochodzenia. |
brak sklepu | W przypadku żądań: pamięć podręczna nie może przechowywać żądania. W odpowiedziach: pamięć podręczna nie może przechowywać żadnej części odpowiedzi. |
Inne nagłówki pamięci podręcznej, które odgrywają rolę w buforowaniu, są wyświetlane w poniższej tabeli.
Nagłówek | Function |
---|---|
Wiek | Szacowanie czasu w sekundach od wygenerowania lub pomyślnego zweryfikowania odpowiedzi na serwerze pochodzenia. |
Wygasa | Czas, po którym odpowiedź jest uznawana za nieaktualną. |
Pragma | Istnieje w celu zapewnienia zgodności z poprzednimi wersjami pamięci podręcznych HTTP/1.0 na potrzeby zachowania ustawień no-cache . Cache-Control Jeśli nagłówek jest obecny, Pragma nagłówek jest ignorowany. |
Różnić się | Określa, że buforowana odpowiedź nie może być wysyłana, chyba że wszystkie Vary pola nagłówka są zgodne zarówno z oryginalnym żądaniem odpowiedzi w pamięci podręcznej, jak i nowym żądaniem. |
Buforowanie oparte na protokole HTTP uwzględnia dyrektywy Cache-Control
RFC 9111: buforowanie HTTP (sekcja 5.2. Kontrolka pamięci podręcznej) wymaga pamięci podręcznej do honorowania prawidłowego Cache-Control
nagłówka wysyłanego przez klienta. Klient może wysyłać żądania z wartością nagłówka no-cache
i wymusić na serwerze wygenerowanie nowej odpowiedzi dla każdego żądania.
Zawsze uwzględnianie nagłówków żądań klienta Cache-Control
ma sens, jeśli rozważasz cel buforowania HTTP. Zgodnie ze specyfikacją oficjalną buforowanie ma na celu zmniejszenie opóźnienia i nakładu pracy w sieci satysfakcjonujących żądań w sieci klientów, serwerów proxy i serwerów. Niekoniecznie jest to sposób kontrolowania obciążenia na serwerze pochodzenia.
Nie ma kontroli dewelopera nad tym zachowaniem buforowania podczas korzystania z oprogramowania pośredniczącego buforowania odpowiedzi, ponieważ oprogramowanie pośredniczące jest zgodne z oficjalną specyfikacją buforowania. Dodano obsługę buforowania danych wyjściowych w celu lepszego kontrolowania obciążenia serwera na platformie .NET 7. Aby uzyskać więcej informacji, zobacz Buforowanie danych wyjściowych.
Atrybut ResponseCache
Parametr ResponseCacheAttribute określa parametry niezbędne do ustawienia odpowiednich nagłówków w buforowaniu odpowiedzi.
Ostrzeżenie
Wyłącz buforowanie zawartości zawierającej informacje dla uwierzytelnionych klientów. Buforowanie powinno być włączone tylko dla zawartości, która nie zmienia się na podstawie użytkowników identity lub czy użytkownik jest zalogowany.
VaryByQueryKeys różni przechowywaną odpowiedź według wartości podanej listy kluczy zapytania. Po podaniu pojedynczej *
wartości oprogramowanie pośredniczące zmienia odpowiedzi według wszystkich parametrów ciągu zapytania żądania.
Aby ustawić VaryByQueryKeys właściwość , należy włączyć oprogramowanie pośredniczące buforowania odpowiedzi. W przeciwnym razie zgłaszany jest wyjątek środowiska uruchomieniowego. Dla właściwości nie ma odpowiedniego nagłówka VaryByQueryKeys HTTP. Właściwość jest funkcją HTTP obsługiwaną przez oprogramowanie pośredniczące buforowania odpowiedzi. Aby oprogramowanie pośredniczące obsługiwało buforowane odpowiedzi, wartość ciągu zapytania i ciągu zapytania musi być zgodna z poprzednim żądaniem. Rozważmy na przykład sekwencję żądań i wyników pokazanych w poniższej tabeli:
Żądanie | Zwrócony z |
---|---|
http://example.com?key1=value1 |
Serwer |
http://example.com?key1=value1 |
Oprogramowanie pośredniczące |
http://example.com?key1=NewValue |
Serwer |
Pierwsze żądanie jest zwracane przez serwer i buforowane w programie pośredniczącym. Drugie żądanie jest zwracane przez oprogramowanie pośredniczące, ponieważ ciąg zapytania pasuje do poprzedniego żądania. Trzecie żądanie nie znajduje się w pamięci podręcznej oprogramowania pośredniczącego, ponieważ wartość ciągu zapytania nie jest zgodna z poprzednim żądaniem.
Element ResponseCacheAttribute służy do konfigurowania i tworzenia (za pośrednictwem IFilterFactory) elementu Microsoft.AspNetCore.Mvc.Internal.ResponseCacheFilter
. Wykonuje ResponseCacheFilter
pracę aktualizowania odpowiednich nagłówków HTTP i funkcji odpowiedzi. Filtr:
- Usuwa wszystkie istniejące nagłówki dla elementów
Vary
,Cache-Control
iPragma
. - Zapisuje odpowiednie nagłówki na podstawie właściwości ustawionych w obiekcie ResponseCacheAttribute.
- Aktualizuje funkcję buforowania odpowiedzi HTTP, jeśli VaryByQueryKeys jest ustawiona.
Różnić się
Ten nagłówek jest zapisywany tylko wtedy, gdy właściwość jest ustawiona VaryByHeader . Właściwość ustawiona na Vary
wartość właściwości. W poniższym przykładzie użyto VaryByHeader właściwości :
[ApiController]
public class TimeController : ControllerBase
{
[Route("api/[controller]")]
[HttpGet]
[ResponseCache(VaryByHeader = "User-Agent", Duration = 30)]
public ContentResult GetTime() => Content(
DateTime.Now.Millisecond.ToString());
Wyświetl nagłówki odpowiedzi za pomocą narzędzia Fiddler lub innego narzędzia. Nagłówki odpowiedzi obejmują:
Cache-Control: public,max-age=30
Vary: User-Agent
Powyższy kod wymaga dodania usług AddResponseCaching oprogramowania pośredniczącego buforowania odpowiedzi do kolekcji usług i skonfigurowania aplikacji do używania oprogramowania pośredniczącego UseResponseCaching z metodą rozszerzenia.
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
i Location.None
NoStore zastępuje większość innych właściwości. Gdy ta właściwość jest ustawiona Cache-Control
na true
wartość , nagłówek ma wartość no-store
. Jeśli Location ustawiono wartość None
:
Cache-Control
jest ustawiona nano-store,no-cache
wartość .Pragma
jest ustawiona nano-cache
wartość .
Jeśli NoStore parametr ma false
None
wartość Location , Cache-Control
, i Pragma
ma wartość no-cache
.
NoStore jest zwykle ustawiona na true
wartość dla stron błędów. Poniższe polecenie generuje nagłówki odpowiedzi, które instruują klienta, aby nie przechowywał odpowiedzi.
[Route("api/[controller]/ticks")]
[HttpGet]
[ResponseCache(Location = ResponseCacheLocation.None, NoStore = true)]
public ContentResult GetTimeTicks() => Content(
DateTime.Now.Ticks.ToString());
Powyższy kod zawiera następujące nagłówki w odpowiedzi:
Cache-Control: no-store,no-cache
Pragma: no-cache
Aby zastosować ResponseCacheAttribute element do wszystkich odpowiedzi na strony MVC lub Razor kontrolera MVC aplikacji, dodaj go za pomocą filtru MVC lub Razor filtru stron.
W aplikacji MVC:
builder.Services.AddControllersWithViews().AddMvcOptions(options =>
options.Filters.Add(
new ResponseCacheAttribute
{
NoStore = true,
Location = ResponseCacheLocation.None
}));
Aby uzyskać podejście stosowane do Razor aplikacji Pages, zobacz Dodawanie ResponseCacheAttribute
do globalnej listy filtrów MVC nie dotyczy Razor stron (dotnet/aspnetcore #18890). Przykład podany w komentarzu problemu został napisany dla aplikacji przeznaczonych dla ASP.NET Core przed wydaniem minimalnych interfejsów API o 6.0. W przypadku aplikacji w wersji 6.0 lub nowszej zmień rejestrację usługi w przykładzie na builder.Services.AddSingleton...
.Program.cs
Lokalizacja i czas trwania
Aby włączyć buforowanie, Duration należy ustawić wartość dodatnią i Location musi mieć Any
wartość (wartość domyślną) lub Client
. Platforma ustawia Cache-Control
nagłówek na wartość lokalizacji, po której następuje max-age
odpowiedź.
LocationAny
Opcje i Client
tłumaczą się odpowiednio na Cache-Control
wartości nagłówków public
i private
. Jak wspomniano w sekcji NoStore i Location.None, należy ustawić None
Location wartości i Cache-Control
Pragma
na no-cache
wartość .
Location.Any
(Cache-Control
ustawiona na public
wartość ) wskazuje, że klient lub dowolny pośredni serwer proxy może buforować wartość, w tym oprogramowanie pośredniczące buforowania odpowiedzi.
Location.Client
(Cache-Control
ustawiona na private
wartość ) wskazuje, że tylko klient może buforować wartość. Żadna pośrednia pamięć podręczna nie powinna buforować wartości, w tym oprogramowania pośredniczącego buforowania odpowiedzi.
Nagłówki kontrolek pamięci podręcznej zawierają wskazówki dla klientów i pośredniczących serwerów proxy, kiedy i jak buforować odpowiedzi. Nie ma gwarancji, że klienci i serwery proxy będą honorować RFC 9111: buforowanie HTTP. Oprogramowanie pośredniczące buforowania odpowiedzi zawsze jest zgodne z regułami buforowania określonymi przez specyfikację.
W poniższym przykładzie przedstawiono nagłówki generowane przez ustawienie Duration i pozostawienie wartości domyślnej Location :
[Route("api/[controller]/ms")]
[HttpGet]
[ResponseCache(Duration = 10, Location = ResponseCacheLocation.Any, NoStore = false)]
public ContentResult GetTimeMS() => Content(
DateTime.Now.Millisecond.ToString());
Powyższy kod zawiera następujące nagłówki w odpowiedzi:
Cache-Control: public,max-age=10
Profile pamięci podręcznej
Zamiast duplikować ustawienia pamięci podręcznej odpowiedzi na wiele atrybutów akcji kontrolera, profile pamięci podręcznej można skonfigurować jako opcje podczas konfigurowania MVC/Razor Pages. Wartości znalezione w profilu przywoływanej pamięci podręcznej są używane jako wartości domyślne i ResponseCacheAttribute są zastępowane przez wszystkie właściwości określone w atrybucie.
W poniższym przykładzie przedstawiono 30-sekundowy profil pamięci podręcznej:
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();
Poniższy kod odwołuje się do profilu pamięci podręcznej 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());
}
Wynikowa odpowiedź nagłówka przez profil pamięci podręcznej Default30
obejmuje:
Cache-Control: public,max-age=30
Atrybut [ResponseCache]
można zastosować do:
- Razor Strony: Atrybuty nie mogą być stosowane do metod obsługi. Przeglądarki używane z aplikacjami interfejsu użytkownika uniemożliwiają buforowanie odpowiedzi.
- Kontrolery MVC.
- Metody akcji MVC: atrybuty na poziomie metody zastępują ustawienia określone w atrybutach na poziomie klasy.
Poniższy kod stosuje atrybut na [ResponseCache]
poziomie kontrolera i metody:
[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());
}
Dodatkowe zasoby
- Przechowywanie odpowiedzi w pamięciach podręcznych
- Kontrolka pamięci podręcznej
- Buforowanie w pamięci w ASP.NET Core
- Buforowanie rozproszone w ASP.NET Core
- Wykrywanie zmian za pomocą tokenów zmian w programie ASP.NET Core
- Oprogramowanie pośredniczące buforowania odpowiedzi w programie ASP.NET Core
- Pomocnik tagów pamięci podręcznej w ASP.NET Core MVC
- Pomocnik tagów rozproszonej pamięci podręcznej w ASP.NET Core
Wyświetl lub pobierz przykładowy kod (jak pobrać)
Buforowanie odpowiedzi zmniejsza liczbę żądań wysyłanych przez klienta lub serwer proxy do serwera internetowego. Buforowanie odpowiedzi zmniejsza również ilość pracy wykonywanej przez serwer internetowy w celu wygenerowania odpowiedzi. Buforowanie odpowiedzi jest kontrolowane przez nagłówki, które określają sposób, w jaki klient, serwer proxy i oprogramowanie pośredniczące mają buforować odpowiedzi.
Element [ResponseCache]
uczestniczy w ustawianiu nagłówków buforowania odpowiedzi. Klienci i pośrednie serwery proxy powinny honorować nagłówki dla odpowiedzi buforowania w obszarze RFC 9111: buforowanie HTTP.
W przypadku buforowania po stronie serwera, która jest zgodna ze specyfikacją buforowania HTTP 1.1, użyj oprogramowania pośredniczącego buforowania odpowiedzi. Oprogramowanie pośredniczące może używać [ResponseCache]
właściwości do ustawiania nagłówków buforowania po stronie serwera.
Buforowanie odpowiedzi oparte na protokole HTTP
RFC 9111: Buforowanie HTTP opisuje, jak powinny zachowywać się pamięci podręczne internetowe. Podstawowy nagłówek HTTP używany do buforowania to Cache-Control, który służy do określania dyrektyw pamięci podręcznej. Dyrektywy kontrolują zachowanie buforowania, gdy żądania w drodze od klientów do serwerów i w miarę reagowania wracają z serwerów z powrotem do klientów. Żądania i odpowiedzi przechodzą przez serwery proxy, a serwery proxy muszą być również zgodne ze specyfikacją buforowania HTTP 1.1.
Typowe Cache-Control
dyrektywy przedstawiono w poniższej tabeli.
Dyrektywa | Akcja |
---|---|
public | Pamięć podręczna może przechowywać odpowiedź. |
private | Odpowiedź nie może być przechowywana przez udostępnioną pamięć podręczną. Prywatna pamięć podręczna może przechowywać i ponownie używać odpowiedzi. |
maksymalny wiek | Klient nie akceptuje odpowiedzi, której wiek jest większy niż określona liczba sekund. Przykłady: max-age=60 (60 sekund), max-age=2592000 (1 miesiąc) |
brak pamięci podręcznej | W przypadku żądań: pamięć podręczna nie może używać przechowywanej odpowiedzi w celu spełnienia żądania. Serwer pochodzenia ponownie generuje odpowiedź klienta, a oprogramowanie pośredniczące aktualizuje przechowywaną odpowiedź w pamięci podręcznej. W odpowiedziach: odpowiedź nie może być używana dla kolejnego żądania bez sprawdzania poprawności na serwerze pochodzenia. |
brak sklepu | W przypadku żądań: pamięć podręczna nie może przechowywać żądania. W odpowiedziach: pamięć podręczna nie może przechowywać żadnej części odpowiedzi. |
Inne nagłówki pamięci podręcznej, które odgrywają rolę w buforowaniu, są wyświetlane w poniższej tabeli.
Nagłówek | Function |
---|---|
Wiek | Szacowanie czasu w sekundach od wygenerowania lub pomyślnego zweryfikowania odpowiedzi na serwerze pochodzenia. |
Wygasa | Czas, po którym odpowiedź jest uznawana za nieaktualną. |
Pragma | Istnieje w celu zapewnienia zgodności z poprzednimi wersjami pamięci podręcznych HTTP/1.0 na potrzeby zachowania ustawień no-cache . Cache-Control Jeśli nagłówek jest obecny, Pragma nagłówek jest ignorowany. |
Różnić się | Określa, że buforowana odpowiedź nie może być wysyłana, chyba że wszystkie Vary pola nagłówka są zgodne zarówno z oryginalnym żądaniem odpowiedzi w pamięci podręcznej, jak i nowym żądaniem. |
Buforowanie oparte na protokole HTTP uwzględnia dyrektywy Cache-Control
RFC 9111: buforowanie HTTP (sekcja 5.2. Kontrolka pamięci podręcznej) wymaga pamięci podręcznej do honorowania prawidłowego Cache-Control
nagłówka wysyłanego przez klienta. Klient może wysyłać żądania z wartością nagłówka no-cache
i wymusić na serwerze wygenerowanie nowej odpowiedzi dla każdego żądania.
Zawsze uwzględnianie nagłówków żądań klienta Cache-Control
ma sens, jeśli rozważasz cel buforowania HTTP. Zgodnie ze specyfikacją oficjalną buforowanie ma na celu zmniejszenie opóźnienia i nakładu pracy w sieci satysfakcjonujących żądań w sieci klientów, serwerów proxy i serwerów. Niekoniecznie jest to sposób kontrolowania obciążenia na serwerze pochodzenia.
Nie ma kontroli dewelopera nad tym zachowaniem buforowania podczas korzystania z oprogramowania pośredniczącego buforowania odpowiedzi, ponieważ oprogramowanie pośredniczące jest zgodne z oficjalną specyfikacją buforowania. Obsługa buforowania danych wyjściowych w celu lepszego kontrolowania obciążenia serwera to propozycja projektowa przyszłej wersji ASP.NET Core. Aby uzyskać więcej informacji, zobacz Dodawanie obsługi buforowania danych wyjściowych (dotnet/aspnetcore #27387).
Inne technologie buforowania w technologii ASP.NET Core
Buforowanie w pamięci
Buforowanie w pamięci używa pamięci serwera do przechowywania buforowanych danych. Ten typ buforowania jest odpowiedni dla jednego serwera lub wielu serwerów przy użyciu koligacji sesji. Koligacja sesji jest również znana jako sesje sticky. Koligacja sesji oznacza, że żądania od klienta są zawsze kierowane do tego samego serwera do przetwarzania.
Aby uzyskać więcej informacji, zobacz Buforowanie w pamięci w programie ASP.NET Core i Rozwiązywanie problemów z koligacją sesji bramy aplikacja systemu Azure.
Rozproszona pamięć podręczna
Użyj rozproszonej pamięci podręcznej do przechowywania danych w pamięci, gdy aplikacja jest hostowana w farmie serwerów lub w chmurze. Pamięć podręczna jest współdzielona na serwerach, które przetwarzają żądania. Klient może przesłać żądanie obsługiwane przez dowolny serwer w grupie, jeśli dane buforowane dla klienta są dostępne. ASP.NET Core współpracuje z rozproszonymi pamięciami podręcznymi sql Server, Redis i NCache .
Aby uzyskać więcej informacji, zobacz Buforowanie rozproszone w usłudze ASP.NET Core.
Pomocnik tagów pamięci podręcznej
Buforuj zawartość z widoku MVC lub Razor strony za pomocą pomocnika tagów pamięci podręcznej. Pomocnik tagów pamięci podręcznej używa buforowania w pamięci do przechowywania danych.
Aby uzyskać więcej informacji, zobacz Cache Tag Helper in ASP.NET Core MVC (Pomocnik tagów pamięci podręcznej w usłudze ASP.NET Core MVC).
Pomocnik tagów rozproszonej pamięci podręcznej
Buforuj zawartość z widoku MVC lub Razor strony w scenariuszach rozproszonych w chmurze lub farmie internetowej za pomocą pomocnika tagów rozproszonej pamięci podręcznej. Pomocnik tagów rozproszonej pamięci podręcznej używa programu SQL Server, Redis lub NCache do przechowywania danych.
Aby uzyskać więcej informacji, zobacz Distributed Cache Tag Helper in ASP.NET Core (Pomocnik tagów rozproszonej pamięci podręcznej w ASP.NET Core).
Atrybut ResponseCache
Parametr ResponseCacheAttribute określa parametry niezbędne do ustawienia odpowiednich nagłówków w buforowaniu odpowiedzi.
Ostrzeżenie
Wyłącz buforowanie zawartości zawierającej informacje dla uwierzytelnionych klientów. Buforowanie powinno być włączone tylko dla zawartości, która nie zmienia się na podstawie użytkowników identity lub czy użytkownik jest zalogowany.
VaryByQueryKeys różni przechowywaną odpowiedź według wartości podanej listy kluczy zapytania. Po podaniu pojedynczej *
wartości oprogramowanie pośredniczące zmienia odpowiedzi według wszystkich parametrów ciągu zapytania żądania.
Aby ustawić VaryByQueryKeys właściwość , należy włączyć oprogramowanie pośredniczące buforowania odpowiedzi. W przeciwnym razie zgłaszany jest wyjątek środowiska uruchomieniowego. Dla właściwości nie ma odpowiedniego nagłówka VaryByQueryKeys HTTP. Właściwość jest funkcją HTTP obsługiwaną przez oprogramowanie pośredniczące buforowania odpowiedzi. Aby oprogramowanie pośredniczące obsługiwało buforowane odpowiedzi, wartość ciągu zapytania i ciągu zapytania musi być zgodna z poprzednim żądaniem. Rozważmy na przykład sekwencję żądań i wyników przedstawionych w poniższej tabeli.
Żądanie | Result |
---|---|
http://example.com?key1=value1 |
Zwrócony z serwera. |
http://example.com?key1=value1 |
Zwrócony z oprogramowania pośredniczącego. |
http://example.com?key1=value2 |
Zwrócony z serwera. |
Pierwsze żądanie jest zwracane przez serwer i buforowane w programie pośredniczącym. Drugie żądanie jest zwracane przez oprogramowanie pośredniczące, ponieważ ciąg zapytania pasuje do poprzedniego żądania. Trzecie żądanie nie znajduje się w pamięci podręcznej oprogramowania pośredniczącego, ponieważ wartość ciągu zapytania nie jest zgodna z poprzednim żądaniem.
Element ResponseCacheAttribute służy do konfigurowania i tworzenia (za pośrednictwem IFilterFactory) elementu Microsoft.AspNetCore.Mvc.Internal.ResponseCacheFilter
. Wykonuje ResponseCacheFilter
pracę aktualizowania odpowiednich nagłówków HTTP i funkcji odpowiedzi. Filtr:
- Usuwa wszystkie istniejące nagłówki dla elementów
Vary
,Cache-Control
iPragma
. - Zapisuje odpowiednie nagłówki na podstawie właściwości ustawionych w obiekcie ResponseCacheAttribute.
- Aktualizuje funkcję buforowania odpowiedzi HTTP, jeśli VaryByQueryKeys jest ustawiona.
Różnić się
Ten nagłówek jest zapisywany tylko wtedy, gdy właściwość jest ustawiona VaryByHeader . Właściwość ustawiona na Vary
wartość właściwości. W poniższym przykładzie użyto VaryByHeader właściwości :
[ResponseCache(VaryByHeader = "User-Agent", Duration = 30)]
public class Cache1Model : PageModel
{
Korzystając z przykładowej aplikacji, wyświetl nagłówki odpowiedzi za pomocą narzędzi sieciowych przeglądarki. Następujące nagłówki odpowiedzi są wysyłane z odpowiedzią strony Cache1:
Cache-Control: public,max-age=30
Vary: User-Agent
NoStore
i Location.None
NoStore zastępuje większość innych właściwości. Gdy ta właściwość jest ustawiona Cache-Control
na true
wartość , nagłówek ma wartość no-store
. Jeśli Location ustawiono wartość None
:
Cache-Control
jest ustawiona nano-store,no-cache
wartość .Pragma
jest ustawiona nano-cache
wartość .
Jeśli NoStore parametr ma false
None
wartość Location , Cache-Control
, i Pragma
ma wartość no-cache
.
NoStore jest zwykle ustawiona na true
wartość dla stron błędów. Strona Cache2 w przykładowej aplikacji generuje nagłówki odpowiedzi, które instruują klienta, aby nie przechowywał odpowiedzi.
[ResponseCache(Duration = 0, Location = ResponseCacheLocation.None, NoStore = true)]
public class Cache2Model : PageModel
{
Przykładowa aplikacja zwraca stronę Cache2 z następującymi nagłówkami:
Cache-Control: no-store,no-cache
Pragma: no-cache
Aby zastosować ResponseCacheAttribute element do wszystkich odpowiedzi na strony MVC lub Razor kontrolera MVC aplikacji, dodaj go za pomocą filtru MVC lub Razor filtru stron.
W aplikacji MVC:
services.AddMvc().AddMvcOptions(options =>
options.Filters.Add(
new ResponseCacheAttribute
{
NoStore = true,
Location = ResponseCacheLocation.None
}));
Aby uzyskać podejście stosowane do Razor aplikacji Pages, zobacz Dodawanie ResponseCacheAttribute
do globalnej listy filtrów MVC nie dotyczy Razor stron (dotnet/aspnetcore #18890).
Lokalizacja i czas trwania
Aby włączyć buforowanie, Duration należy ustawić wartość dodatnią i Location musi mieć Any
wartość (wartość domyślną) lub Client
. Platforma ustawia Cache-Control
nagłówek na wartość lokalizacji, po której następuje max-age
odpowiedź.
LocationAny
Opcje i Client
tłumaczą się odpowiednio na Cache-Control
wartości nagłówków public
i private
. Jak wspomniano w sekcji NoStore i Location.None, należy ustawić None
Location wartości i Cache-Control
Pragma
na no-cache
wartość .
Location.Any
(Cache-Control
ustawiona na public
wartość ) wskazuje, że klient lub dowolny pośredni serwer proxy może buforować wartość, w tym oprogramowanie pośredniczące buforowania odpowiedzi.
Location.Client
(Cache-Control
ustawiona na private
wartość ) wskazuje, że tylko klient może buforować wartość. Żadna pośrednia pamięć podręczna nie powinna buforować wartości, w tym oprogramowania pośredniczącego buforowania odpowiedzi.
Nagłówki kontrolek pamięci podręcznej zawierają jedynie wskazówki dla klientów i pośredniczących serwerów proxy, kiedy i jak buforować odpowiedzi. Nie ma gwarancji, że klienci i serwery proxy będą honorować RFC 9111: buforowanie HTTP. Oprogramowanie pośredniczące buforowania odpowiedzi zawsze jest zgodne z regułami buforowania określonymi przez specyfikację.
W poniższym przykładzie pokazano model strony Cache3 z przykładowej aplikacji oraz nagłówki utworzone przez ustawienie Duration i pozostawienie wartości domyślnej Location :
[ResponseCache(Duration = 10, Location = ResponseCacheLocation.Any, NoStore = false)]
public class Cache3Model : PageModel
{
Przykładowa aplikacja zwraca stronę Cache3 z następującym nagłówkiem:
Cache-Control: public,max-age=10
Profile pamięci podręcznej
Zamiast duplikować ustawienia pamięci podręcznej odpowiedzi na wiele atrybutów akcji kontrolera, profile pamięci podręcznej można skonfigurować jako opcje podczas konfigurowania mvC/Razor stron w programie Startup.ConfigureServices
. Wartości znalezione w profilu przywoływanej pamięci podręcznej są używane jako wartości domyślne i ResponseCacheAttribute są zastępowane przez wszystkie właściwości określone w atrybucie.
Konfigurowanie profilu pamięci podręcznej. W poniższym przykładzie pokazano 30-sekundowy profil pamięci podręcznej w przykładowej Startup.ConfigureServices
aplikacji :
public void ConfigureServices(IServiceCollection services)
{
services.AddRazorPages();
services.AddMvc(options =>
{
options.CacheProfiles.Add("Default30",
new CacheProfile()
{
Duration = 30
});
});
}
Przykładowy model strony Cache4 aplikacji odwołuje się do profilu pamięci podręcznej Default30
:
[ResponseCache(CacheProfileName = "Default30")]
public class Cache4Model : PageModel
{
Element ResponseCacheAttribute można zastosować do:
- Razor Strony: Atrybuty nie mogą być stosowane do metod obsługi.
- Kontrolery MVC.
- Metody akcji MVC: atrybuty na poziomie metody zastępują ustawienia określone w atrybutach na poziomie klasy.
Wynikowy nagłówek zastosowany do odpowiedzi strony Cache4 przez profil pamięci podręcznej Default30
:
Cache-Control: public,max-age=30
Dodatkowe zasoby
- Przechowywanie odpowiedzi w pamięciach podręcznych
- RFC 9111: buforowanie HTTP (sekcja 5.2. Kontrolka pamięci podręcznej)
- Buforowanie w pamięci w ASP.NET Core
- Buforowanie rozproszone w ASP.NET Core
- Wykrywanie zmian za pomocą tokenów zmian w programie ASP.NET Core
- Oprogramowanie pośredniczące buforowania odpowiedzi w programie ASP.NET Core
- Pomocnik tagów pamięci podręcznej w ASP.NET Core MVC
- Pomocnik tagów rozproszonej pamięci podręcznej w ASP.NET Core