Udostępnij za pośrednictwem

Buforowanie za pomocą usługi Azure Front Door

  • Artykuł

Ważne

Usługa Azure Front Door (klasyczna) zostanie wycofana 31 marca 2027 r. Aby uniknąć zakłóceń w działaniu usługi, należy przeprowadzić migrację profilów usługi Azure Front Door (wersja klasyczna) do warstwy Azure Front Door Standard lub Premium do marca 2027 r. Aby uzyskać więcej informacji, zobacz Wycofywanie usługi Azure Front Door (wersja klasyczna).

Usługa Azure Front Door to nowoczesna sieć dostarczania zawartości (CDN) z dynamicznymi funkcjami przyspieszania lokacji i równoważenia obciążenia. Gdy buforowanie jest skonfigurowane na trasie, lokacja brzegowa, która odbiera każde żądanie, sprawdza jego pamięć podręczną pod kątem prawidłowej odpowiedzi. Buforowanie pomaga zmniejszyć ilość ruchu wysyłanego do serwera pochodzenia. Jeśli nie jest dostępna żadna buforowana odpowiedź, żądanie jest przekazywane do źródła.

Każda lokacja brzegowa usługi Front Door zarządza własną pamięcią podręczną, a żądania mogą być obsługiwane przez różne witryny brzegowe. W związku z tym nadal może być widoczny pewien ruch dociera do źródła, nawet jeśli obsłużyliśmy buforowane odpowiedzi.

Buforowanie może znacznie zmniejszyć opóźnienie i zmniejszyć obciążenie serwerów pochodzenia. Jednak nie wszystkie typy ruchu mogą korzystać z buforowania. Zasoby statyczne, takie jak obrazy, pliki CSS i JavaScript, idealnie nadają się do buforowania. Zasoby dynamiczne, takie jak uwierzytelnione punkty końcowe interfejsu API, nie powinny być buforowane, aby zapobiec wyciekowi danych osobowych. Zaleca się posiadanie oddzielnych tras dla zasobów statycznych i dynamicznych z wyłączoną pamięcią podręczną dla tego ostatniego.

Ostrzeżenie

Przed włączeniem buforowania dokładnie przejrzyj publiczną dokumentację i przetestuj wszystkie możliwe scenariusze przed włączeniem buforowania. Jak wspomniano wcześniej, z błędną konfiguracją można przypadkowo buforować dane specyficzne dla użytkownika, które mogą być udostępniane przez wielu użytkowników w wyniku zdarzeń prywatności.

Metody żądania

Tylko żądania korzystające z GET metody żądania są możliwe do buforowania. Wszystkie inne metody żądań są zawsze proxied za pośrednictwem sieci.

Dostarczanie dużych plików

Usługa Azure Front Door dostarcza duże pliki bez limitu rozmiaru pliku. Jeśli buforowanie jest włączone, usługa Front Door używa techniki nazywanej fragmentowaniem obiektów. Po zażądaniu dużego pliku usługa Front Door pobiera mniejsze fragmenty pliku ze źródła. Gdy usługa Front Door otrzyma pełne żądanie pliku lub żądanie pliku zakresu bajtów, środowisko usługi Front Door żąda pliku ze źródła we fragmentach o rozmiarze 8 MB.

Po nadejściu fragmentu do środowiska usługi Azure Front Door jest on buforowany i natychmiast obsługiwany dla użytkownika. Usługa Front Door następnie pobiera następny fragment równolegle. To wstępne pobieranie gwarantuje, że zawartość pozostaje jedną częścią przed użytkownikiem, co zmniejsza opóźnienie. Ten proces będzie kontynuowany do momentu pobrania całego pliku (jeśli jest to wymagane) lub klient zamknie połączenie. Aby uzyskać więcej informacji na temat żądania zakresu bajtów, przeczytaj RFC 7233.

Usługa Front Door buforuje wszystkie fragmenty w miarę ich odbierania, więc cały plik nie musi być buforowany w pamięci podręcznej usługi Front Door. Kolejne żądania dla plików lub zakresów bajtów są obsługiwane z pamięci podręcznej. Jeśli fragmenty nie są buforowane, pobieranie wstępne jest używane do żądania fragmentów ze źródła.

Ta optymalizacja opiera się na zdolności źródła do obsługi żądań zakresu bajtów. Jeśli źródło nie obsługuje żądań zakresu bajtów lub jeśli nie obsługuje poprawnie żądań zakresu, ta optymalizacja nie jest skuteczna.

Gdy źródło odpowiada na żądanie z nagłówkiem Range , musi odpowiadać na jeden z następujących sposobów:

  • Zwróć odpowiedź z zakresem. Odpowiedź musi używać kodu stanu HTTP 206. Content-Range Ponadto nagłówek odpowiedzi musi być obecny i musi być zgodny z rzeczywistą długością zawartości zwracanej przez źródło. Jeśli źródło nie wysyła prawidłowych nagłówków odpowiedzi z prawidłowymi wartościami, usługa Azure Front Door nie buforuje odpowiedzi i może być widoczne niespójne zachowanie.

    Napiwek

    Jeśli źródło kompresuje odpowiedź, upewnij się, że Content-Range wartość nagłówka jest zgodna z rzeczywistą długością skompresowanej odpowiedzi.

  • Zwróć nieozakresową odpowiedź. Jeśli źródło nie może obsłużyć żądań zakresu, może zignorować Range nagłówek i zwrócić niearanżowaną odpowiedź. Upewnij się, że źródło zwraca kod stanu odpowiedzi inny niż 206. Na przykład źródło może zwrócić odpowiedź 200 OK.

Jeśli źródło używa kodowania fragmentowanego transferu (CTE) do wysyłania danych do usługi Azure Front Door POP, rozmiary odpowiedzi większe niż 8 MB nie są obsługiwane.

Kompresja plików

Zapoznaj się z artykułem Zwiększanie wydajności przez kompresowanie plików w usłudze Azure Front Door.

Usługa Azure Front Door (wersja klasyczna) może dynamicznie kompresować zawartość na brzegu, co skutkuje krótszym i szybszym czasem odpowiedzi do klientów. Aby plik kwalifikował się do kompresji, buforowanie musi być włączone, a plik musi być typu MIME, aby kwalifikować się do kompresji. Obecnie usługa Front Door (klasyczna) nie zezwala na zmianę tej listy. Bieżąca lista to:

  • "application/eot"
  • "aplikacja/czcionka"
  • "application/font-sfnt"
  • "application/javascript"
  • "application/json"
  • "application/opentype"
  • "application/otf"
  • "application/pkcs7-mime"
  • "application/truetype"
  • "application/ttf",
  • "application/vnd.ms-fontobject"
  • "application/xhtml+xml"
  • "application/xml"
  • "application/xml+rss"
  • "application/x-font-opentype"
  • "application/x-font-truetype"
  • "application/x-font-ttf"
  • "application/x-httpd-cgi"
  • "application/x-mpegurl"
  • "application/x-opentype"
  • "application/x-otf"
  • "application/x-perl"
  • "application/x-ttf"
  • "application/x-javascript"
  • "font/eot"
  • "font/ttf"
  • "font/otf"
  • "font/opentype"
  • "image/svg+xml"
  • "text/css"
  • "tekst/csv"
  • "text/html"
  • "text/javascript"
  • "text/js", "text/plain"
  • "text/richtext"
  • "text/tab-separated-values"
  • "tekst/xml"
  • "text/x-script"
  • "text/x-component"
  • "text/x-java-source"

Ponadto plik musi mieć rozmiar od 1 KB do 8 MB włącznie.

Te profile obsługują następujące kodowania kompresji:

Jeśli żądanie obsługuje kompresję gzip i Brotli, kompresja Brotli ma pierwszeństwo.

Gdy żądanie zasobu określa kompresję, a żądanie powoduje pominięcie pamięci podręcznej, usługa Azure Front Door (wersja klasyczna) wykonuje kompresję zasobu bezpośrednio na serwerze POP. Następnie skompresowany plik jest obsługiwany z pamięci podręcznej. Wynikowy element jest zwracany z nagłówkiem Transfer-Encoding: chunked odpowiedzi.

Jeśli źródło używa kodowania fragmentowanego transferu (CTE) do wysyłania danych do usługi Azure Front Door POP, kompresja nie jest obsługiwana.

Uwaga

Żądania zakresu mogą być kompresowane do różnych rozmiarów. Usługa Azure Front Door wymaga, aby wartości długości zawartości są takie same dla każdego żądania HTTP GET. Jeśli klienci wysyłają żądania zakresu bajtów z Accept-Encoding nagłówkiem, który prowadzi do odpowiedzi źródła o różnych długościach zawartości, usługa Azure Front Door zwróci błąd 503. Możesz wyłączyć kompresję źródła lub utworzyć regułę aparatu reguł, aby usunąć Accept-Encoding nagłówek z żądania żądań zakresu bajtów.

Zachowanie ciągu zapytania

Za pomocą usługi Azure Front Door możesz kontrolować sposób buforowania plików dla żądania internetowego zawierającego ciąg zapytania.

W żądaniu internetowym z ciągiem zapytania ciąg zapytania jest częścią żądania, która występuje po znaku zapytania (?). Ciąg zapytania może zawierać jedną lub więcej par klucz-wartość, w których nazwa pola i jego wartość są oddzielone znakiem równości (=). Każda para klucz-wartość jest oddzielona ampersand (&).

Na przykład adres URL http://www.contoso.com/content.mov?field1=value1&field2=value2 zawiera dwa ciągi zapytania:

  • field1, z wartością value1.
  • field2, z wartością value2.

Jeśli istnieje więcej niż jedna para klucz-wartość w ciągu zapytania żądania, ich kolejność nie ma znaczenia.

Podczas konfigurowania buforowania należy określić sposób obsługi ciągów zapytań w pamięci podręcznej. Obsługiwane są następujące zachowania:

  • Ignoruj ciąg zapytania: w tym trybie usługa Azure Front Door przekazuje ciągi zapytania od klienta do źródła pierwszego żądania i buforuje zasób. Przyszłe żądania zasobu, które są obsługiwane w środowisku usługi Front Door, ignorują ciągi zapytania do momentu wygaśnięcia buforowanego zasobu.

  • Użyj ciągu zapytania: w tym trybie każde żądanie z unikatowym adresem URL, w tym ciągiem zapytania, jest traktowane jako unikatowy zasób z własną pamięcią podręczną. Na przykład odpowiedź z punktu początkowego żądania dla żądania www.example.ashx?q=test1 jest buforowana w środowisku usługi Front Door i zwracana dla pamięci podręcznych z tym samym ciągiem zapytania. Żądanie dla www.example.ashx?q=test2 elementu jest buforowane jako oddzielny zasób z własnym ustawieniem czasu na żywo.

    Kolejność parametrów ciągu zapytania nie ma znaczenia. Jeśli na przykład środowisko usługi Azure Front Door zawiera w pamięci podręcznej odpowiedź dla adresu URL www.example.ashx?q=test1&r=test2, żądanie dotyczy www.example.ashx?r=test2&q=test1 również obsługi z pamięci podręcznej.

  • Ignoruj określone ciągi zapytania i uwzględnij określone ciągi zapytania: w tym trybie można skonfigurować usługę Azure Front Door tak, aby uwzględniała lub wykluczała określone parametry po wygenerowaniu klucza pamięci podręcznej.

    Załóżmy na przykład, że domyślny klucz pamięci podręcznej to /foo/image/asset.html, a żądanie jest wykonywane pod adresem URL https://contoso.com/foo/image/asset.html?language=EN&userid=100&sessionid=200. Jeśli istnieje reguła aparatu reguł wykluczania parametru userid ciągu zapytania, klucz pamięci podręcznej ciągu zapytania to /foo/image/asset.html?language=EN&sessionid=200.

Skonfiguruj zachowanie ciągu zapytania na trasie usługi Front Door.

Przeczyszczanie pamięci podręcznej

Zobacz Przeczyszczanie pamięci podręcznej w usłudze Azure Front Door , aby dowiedzieć się, jak skonfigurować przeczyszczanie pamięci podręcznej.

Usługa Azure Front Door buforuje zasoby do momentu wygaśnięcia zasobu (TTL). Za każdym razem, gdy klient żąda zasobu z wygasłym czasem wygaśnięcia, środowisko usługi Front Door pobiera nową zaktualizowaną kopię zasobu do obsługi żądania, a następnie przechowuje odświeżoną pamięć podręczną.

Najlepszym rozwiązaniem, aby upewnić się, że użytkownicy zawsze uzyskują najnowszą kopię zasobów, jest przechowywanie wersji zasobów dla każdej aktualizacji i publikowanie ich jako nowych adresów URL. Usługa Front Door natychmiast pobierze nowe zasoby dla następnych żądań klientów. Czasami może być konieczne przeczyszczenie buforowanej zawartości ze wszystkich węzłów brzegowych i wymusić ich pobranie nowych zaktualizowanych zasobów. Przyczyną może być aktualizacja aplikacji internetowej lub szybkie aktualizowanie zasobów zawierających nieprawidłowe informacje.

Zrzut ekranu przedstawiający przycisk i stronę przeczyszczania pamięci podręcznej.

Wybierz zasoby, które chcesz przeczyścić z węzłów brzegowych. Aby wyczyścić wszystkie zasoby, wybierz pozycję Przeczyść wszystko. W przeciwnym razie w polu Ścieżka wprowadź ścieżkę każdego zasobu, który chcesz przeczyścić.

Te formaty są obsługiwane na listach ścieżek do przeczyszczania:

  • Przeczyszczanie pojedynczej ścieżki: Przeczyść poszczególne zasoby, określając pełną ścieżkę zasobu (bez protokołu i domeny) z rozszerzeniem pliku, na przykład /pictures/strasbourg.png;
  • Przeczyszczanie symboli wieloznacznych: Gwiazdka (*) może być używana jako symbol wieloznaczny. Przeczyść wszystkie foldery, podfoldery i pliki w punkcie końcowym z /* w ścieżce lub przeczyść wszystkie podfoldery i pliki w określonym folderze, określając folder, po którym następuje /*, na przykład /pictures/*.
  • Przeczyszczanie domeny głównej: przeczyść katalog główny punktu końcowego za pomocą ciągu "/" w ścieżce.

Uwaga

Przeczyszczanie domen wieloznacznych: określanie buforowanych ścieżek do przeczyszczania zgodnie z opisem w tej sekcji nie dotyczy żadnych domen wieloznacznych skojarzonych z usługą Front Door. Obecnie nie obsługujemy bezpośredniego przeczyszczania domen wieloznacznych. Ścieżki można przeczyścić z określonych poddomen, określając określoną poddomenę i ścieżkę przeczyszczania. Jeśli na przykład moja usługa Front Door ma *.contoso.comwartość , mogę przeczyścić zasoby mojego poddomenyfoo.contoso.com, wpisując .foo.contoso.com/path/* Obecnie określanie nazw hostów w ścieżce zawartości przeczyszczania jest ograniczone do domen podrzędnych domen wieloznacznych, jeśli ma to zastosowanie.

Czyszczenie pamięci podręcznej w usłudze Front Door nie uwzględnia wielkości liter. Ponadto są one niezależne od ciągu zapytania, co oznacza, że przeczyszczanie adresu URL powoduje przeczyszczenie wszystkich odmian ciągu zapytania.

Wygaśnięcie pamięci podręcznej

Następująca kolejność nagłówków służy do określania, jak długo element jest przechowywany w pamięci podręcznej:

  1. Cache-Control: s-maxage=<seconds>
  2. Cache-Control: max-age=<seconds>
  3. Expires: <http-date>

Niektóre Cache-Control wartości nagłówka odpowiedzi wskazują, że odpowiedź nie może być buforowalna. Te wartości obejmują private, no-cachei no-store. Usługa Front Door honoruje te wartości nagłówka i nie buforuje odpowiedzi, nawet jeśli zastąpisz zachowanie buforowania przy użyciu aparatu reguł.

Cache-Control Jeśli nagłówek nie jest obecny w odpowiedzi ze źródła, domyślnie usługa Front Door losowo określa czas trwania pamięci podręcznej od jednego do trzech dni.

Uwaga

Wygaśnięcie pamięci podręcznej nie może być większe niż 366 dni.

Może zostać wyświetlony REVALIDATED_HIT w nagłówku Cache-Control odpowiedzi. Oznacza to, że buforowana zawartość w usłudze Azure Front Door została ponownie zaktualizowana z serwerem pochodzenia przed udostępnieniem klientowi. Może się to zdarzyć, gdy buforowana zawartość wygasła, ale serwer pochodzenia wskazuje, że zawartość nie została zmieniona. W takim przypadku buforowana zawartość jest obsługiwana klientowi, a wygaśnięcie pamięci podręcznej zostanie zresetowane.

Nagłówki żądań

Następujące nagłówki żądań nie są przekazywane do źródła po włączeniu buforowania:

  • Content-Length
  • Transfer-Encoding
  • Accept
  • Accept-Charset
  • Accept-Language
  • Vary

Uwaga

Żądania zawierające nagłówek autoryzacji nie będą buforowane, chyba że odpowiedź zawiera dyrektywę Cache-Control, która umożliwia buforowanie. Następujące dyrektywy Cache-Control mają taki efekt: must-revalidate, public i s-maxage.

Nagłówki odpowiedzi

Jeśli odpowiedź źródła jest zapisywana w pamięci podręcznej, Set-Cookie nagłówek zostanie usunięty przed wysłaniem odpowiedzi do klienta. Jeśli odpowiedź źródła nie jest buforowalna, usługa Front Door nie usuwa nagłówka. Jeśli na przykład odpowiedź źródła zawiera Cache-Control nagłówek z wartością wskazującą usługę max-age Front Door, że odpowiedź jest zapisywana w pamięci podręcznej, a Set-Cookie nagłówek jest usuwany.

Ponadto usługa Front Door dołącza X-Cache nagłówek do wszystkich odpowiedzi. Nagłówek X-Cache odpowiedzi zawiera jedną z następujących wartości:

  • TCP_HIT lub TCP_REMOTE_HIT: Pierwszy fragment odpowiedzi o rozmiarze 8 MB jest trafieniem pamięci podręcznej, a zawartość jest obsługiwana z pamięci podręcznej usługi Front Door.
  • TCP_MISS: Pierwszy fragment odpowiedzi o rozmiarze 8 MB jest błędną pamięcią podręczną, a zawartość jest pobierana ze źródła.
  • PRIVATE_NOSTORE: Nie można buforować żądania, ponieważ nagłówek odpowiedzi Cache-Control jest ustawiony na prywatny lub bez magazynu.
  • CONFIG_NOCACHE: Żądanie jest skonfigurowane tak, aby nie buforować w profilu usługi Front Door.

Dzienniki i raporty

Dziennik dostępu zawiera stan pamięci podręcznej dla każdego żądania. Ponadto raporty zawierają informacje o sposobie użycia pamięci podręcznej usługi Azure Front Door w aplikacji.

Dziennik dostępu zawiera stan pamięci podręcznej dla każdego żądania.

Zachowanie i czas trwania pamięci podręcznej

Zachowanie i czas trwania pamięci podręcznej można skonfigurować w a aparatu reguł. Konfiguracja buforowania aparatu reguł zawsze zastępuje konfigurację trasy.

  • Gdy buforowanie jest wyłączone, usługa Azure Front Door nie buforuje zawartości odpowiedzi niezależnie od dyrektyw odpowiedzi źródła.

  • Gdy buforowanie jest włączone, zachowanie pamięci podręcznej różni się w zależności od wartości zachowania pamięci podręcznej zastosowanej przez aparat reguł:

    • Pochodzenie honoru: usługa Azure Front Door zawsze honoruje dyrektywę nagłówka odpowiedzi pochodzenia. Jeśli brakuje dyrektywy pochodzenia, usługa Azure Front Door buforuje zawartość w dowolnym miejscu od jednego do trzech dni.
    • Przesłonięcia zawsze: usługa Azure Front Door zawsze zastępuje czas trwania pamięci podręcznej, co oznacza, że buforuje zawartość przez czas trwania pamięci podręcznej ignorując wartości z dyrektyw odpowiedzi źródła. To zachowanie ma zastosowanie tylko wtedy, gdy odpowiedź jest zapisywana w pamięci podręcznej.
    • Zastąpij, jeśli brakuje źródła: jeśli źródło nie zwraca wartości czasu wygaśnięcia buforowania, usługa Azure Front Door używa określonego czasu trwania pamięci podręcznej. To zachowanie ma zastosowanie tylko wtedy, gdy odpowiedź jest zapisywana w pamięci podręcznej.

Uwaga

  • Usługa Azure Front Door nie gwarantuje ilości czasu, przez jaki zawartość jest przechowywana w pamięci podręcznej. Buforowana zawartość może zostać usunięta z pamięci podręcznej krawędzi przed wygaśnięciem zawartości, jeśli zawartość nie jest często używana. Usługa Front Door może obsługiwać dane z pamięci podręcznej, nawet jeśli dane z pamięci podręcznej wygasły. To zachowanie może pomóc witrynie pozostać częściowo dostępne, gdy źródła są w trybie offline.
  • Źródła mogą określać, że nie mają buforować określonych odpowiedzi przy użyciu nagłówka Cache-Control z wartością no-cache, private lub no-store. W przypadku użycia w odpowiedzi HTTP z serwera pochodzenia do adresów POPs usługi Azure Front Door usługa Azure Front Door obsługuje dyrektywy kontroli pamięci podręcznej i honoruje zachowania buforowania dla dyrektyw kontroli pamięci podręcznej w RFC 7234 — Protokół transferu hipertekstowego (HTTP/1.1): buforowanie (ietf.org).

Zachowanie i czas trwania pamięci podręcznej można skonfigurować zarówno w regule routingu projektanta usługi Front Door, jak i w aucie reguł. Konfiguracja buforowania aparatu reguł zawsze zastępuje konfigurację reguły routingu projektanta usługi Front Door.

  • Gdy buforowanie jest wyłączone, usługa Azure Front Door (wersja klasyczna) nie buforuje zawartości odpowiedzi niezależnie od dyrektyw odpowiedzi źródła.

  • W przypadku włączenia buforowania zachowanie pamięci podręcznej różni się w przypadku różnych wartości domyślnego czasu trwania pamięci podręcznej.

    • Jeśli domyślny czas trwania użyj pamięci podręcznej ma wartość Tak, usługa Azure Front Door (wersja klasyczna) zawsze honoruje dyrektywę nagłówka odpowiedzi źródła. Jeśli brakuje dyrektywy pochodzenia, usługa Front Door buforuje zawartość w dowolnym miejscu od jednego do trzech dni.
    • Gdy domyślny czas trwania pamięci podręcznej ma wartość Nie, usługa Azure Front Door (wersja klasyczna) zawsze zastępuje czas trwania pamięci podręcznej (wymagane pola), co oznacza, że buforuje zawartość dla czasu trwania pamięci podręcznej, ignorując wartości dyrektyw odpowiedzi źródła.

Uwaga

  • Usługa Azure Front Door (wersja klasyczna) nie gwarantuje ilości czasu, przez jaki zawartość jest przechowywana w pamięci podręcznej. Buforowana zawartość może zostać usunięta z pamięci podręcznej krawędzi przed wygaśnięciem zawartości, jeśli zawartość nie jest często używana. Usługa Azure Front Door (klasyczna) może obsługiwać dane z pamięci podręcznej, nawet jeśli dane z pamięci podręcznej wygasły. To zachowanie może pomóc witrynie pozostać częściowo dostępne, gdy źródła są w trybie offline.
  • Czas trwania pamięci podręcznej ustawiony w regule routingu projektanta usługi Front Door to minimalny czas trwania pamięci podręcznej. To zastąpienie nie będzie działać, jeśli nagłówek kontrolki pamięci podręcznej ze źródła ma większy czas wygaśnięcia niż wartość zastąpienia.

Następne kroki