Udostępnij przez

Buforowanie za pomocą usługi Azure Front Door

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).

Azure Front Door to nowoczesna sieć dostarczania zawartości (CDN) z dynamicznym przyspieszaniem witryn i możliwościami równoważenia obciążenia. Po skonfigurowaniu buforowania na trasie lokacja brzegowa, która odbiera każde żądanie, sprawdza swoją pamięć podręczną pod kątem prawidłowej odpowiedzi. Buforowanie pomaga zmniejszyć ilość ruchu wysyłanego do serwera pochodzenia. Jeśli żadna odpowiedź w pamięci podręcznej nie jest dostępna, żą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 lokacje brzegowe. W związku z tym nadal możesz zauważyć, że część ruchu dociera do Twojego serwera źródłowego, nawet jeśli serwujesz odpowiedzi z pamięci podręcznej.

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ę wykorzystanie oddzielnych tras dla plików statycznych i dynamicznych, z wyłączonym buforowaniem dla tych ostatnich.

Ostrzeżenie

Przed włączeniem buforowania należy dokładnie zapoznać się z dokumentacją publiczną i przetestować 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, które używają metody GET, mogą być buforowane. Wszystkie inne metody żądań są zawsze przesyłane przez sieć proxy.

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. Gdy żądany jest duży plik, usługa Front Door pobiera mniejsze fragmenty pliku ze źródła. Gdy usługa Front Door otrzyma żądanie pełnego pliku lub żądanie pliku z zakresu bajtów, środowisko usługi Front Door żąda pliku ze źródła we fragmentach o rozmiarze 8 MB.

Gdy fragment dotrze do środowiska usługi Azure Front Door, jest buforowany i natychmiast dostarczany użytkownikowi. Następnie Front Door wstępnie pobiera następny fragment równolegle. To wstępne pobieranie gwarantuje, że zawartość pozostaje o jeden fragment przed użytkownikiem, co zmniejsza opóźnienie. Ten proces jest kontynuowany do momentu pobrania całego pliku (jeśli jest to wymagane) lub zamknięcia połączenia przez klienta. Aby uzyskać więcej informacji na temat żądania zakresu bajtów, zobacz 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 dotyczące pliku lub zakresów bajtów są obsługiwane z pamięci podręcznej. Jeśli nie wszystkie fragmenty są buforowane, pobieranie z wyprzedzeniem służy 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 odpowiedzieć w jeden z następujących sposobów:

  • Zwraca odpowiedź dystansową. 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 poprawnych nagłówków odpowiedzi z prawidłowymi wartościami, usługa Azure Front Door nie buforuje odpowiedzi i może wystąpić niespójne zachowanie.

    Wskazówka

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

  • Zwraca odpowiedź nieobjętą zakresem. Jeśli serwer źródłowy nie może obsłużyć żądań zakresu, może zignorować nagłówek Range i zwrócić odpowiedź bez zakresu. 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 transferu fragmentarycznego (CTE) do wysyłania danych do punktu POP usługi Azure Front Door, rozmiary odpowiedzi większe niż 8 MB nie są obsługiwane.

Kompresja pliku

Zobacz poprawianie wydajności przez kompresowanie plików w usłudze Azure Front Door.

Usługa Azure Front Door (klasyczna) może dynamicznie kompresować zawartość na brzegu sieci, co skutkuje krótszym czasem odpowiedzi dla 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. Aktualna lista to:

  • "application/EOT"
  • "aplikacja/czcionka"
  • "aplikacja/czcionka-sfnt"
  • "aplikacja/javascript"
  • "aplikacja/json"
  • "aplikacja/opentype"
  • "Aplikacja/OTF"
  • "Aplikacja/PKCS7-MIME"
  • "application/truetype" (aplikacja/truetype)
  • "Aplikacja/TTF",
  • "application/vnd.ms-fontobject" (aplikacja/vnd.ms-fontobject)
  • "aplikacja/xhtml+xml"
  • "aplikacja/xml"
  • "aplikacja/xml+rss"
  • "application/x-font-opentype"
  • "application/x-font-truetype" (aplikacja/czcionka-x-truetype)
  • "aplikacja/czcionka-x-ttf"
  • aplikacja/x-httpd-cgi
  • "aplikacja/x-mpegurl"
  • "aplikacja/x-opentype"
  • "aplikacja/x-otf"
  • "aplikacja/x-perl"
  • "Aplikacja/x-ttf"
  • "aplikacja/x-javascript"
  • czcionka/eot
  • "czcionka/ttf"
  • czcionka OTF
  • "czcionka/otwarta czcionka"
  • image/svg+xml
  • text/css
  • "tekst/csv"
  • "tekst/html"
  • text/javascript
  • "tekst/js", "tekst/zwykły"
  • Tekst/tekst wzbogacony
  • "Wartości oddzielone tabulatorami tekstowymi"
  • tekst/xml
  • "tekst/x-skrypt"
  • "Komponent tekstowy/X"
  • "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 (klasyczna) wykonuje kompresję zasobu bezpośrednio na serwerze POP. Następnie skompresowany plik jest udostępniany 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 / Notatka

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

Zachowanie ciągu zapytania

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

W żądaniu internetowym z ciągiem zapytania ciąg zapytania to ta część żą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 znakiem ampersand (&).

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

  • field1, o wartości value1.
  • field2, o wartości value2.

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

Podczas konfigurowania buforowania należy określić, w jaki sposób pamięć podręczna powinna obsługiwać ciągi zapytań. 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 w pierwszym żądaniu i buforuje zasób. Przyszłe żądania dotyczące zasobu, które są obsługiwane ze środowiska usługi Front Door, ignorują ciągi zapytania, dopóki zasób w pamięci podręcznej nie wygaśnie.

  • 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ź ze źródła dla żądania for www.example.ashx?q=test1 jest buforowana w środowisku usługi Front Door i zwracana dla kolejnych pamięci podręcznych z tym samym ciągiem zapytania. Żądanie dotyczące www.example.ashx?q=test2 jest buforowane jako oddzielny zasób ze swoim własnym czasem obowiązywania.

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

  • Ignoruj określone ciągi zapytania i dołączaj 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 podczas generowania klucza pamięci podręcznej.

    Załóżmy na przykład, że domyślnym kluczem pamięci podręcznej jest /foo/image/asset.html, a do adresu URL https://contoso.com/foo/image/asset.html?language=EN&userid=100&sessionid=200jest wysyłane żądanie . Jeśli istnieje reguła aparatu reguł, która wyklucza userid parametr ciągu zapytania, klucz pamięci podręcznej ciągu zapytania będzie miał wartość /foo/image/asset.html?language=EN&sessionid=200.

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

Czyszczenie 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 (TTL) zasobu. Za każdym razem, gdy klient żąda zasobu z wygasłym czasem życia (TTL), środowisko usługi Front Door pobiera nową zaktualizowaną kopię zasobu w celu 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ń klienta. Czasami możesz chcieć usunąć buforowaną zawartość ze wszystkich węzłów brzegowych i zmusić je do pobrania nowych, zaktualizowanych zasobów. Przyczyną mogą być aktualizacje aplikacji internetowej lub szybkie aktualizowanie zasobów zawierających nieprawidłowe informacje.

Zrzut ekranu przycisku i strony czyszczenia pamięci podręcznej.

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

Formaty te są obsługiwane na listach ścieżek do wyczyszczenia.

  • Przeczyszczanie pojedynczej ścieżki: wyczyść 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;
  • Usuwanie symboli wieloznacznych: Gwiazdka (*) może być używana jako symbol wieloznaczny. Wyczyść wszystkie foldery, podfoldery i pliki w punkcie końcowym z /* w ścieżce lub wyczyść 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ść domenę główną punktu końcowego, używając "/" w ścieżce.

Uwaga / Notatka

Czyszczenie domen z symbolami wieloznacznymi: Jak opisano w tej sekcji, określanie ścieżek pamięci podręcznej do czyszczenia nie ma zastosowania do żadnych domen z symbolami wieloznacznymi skojarzonych z usługą Front Door. Obecnie nie obsługujemy bezpośredniego czyszczenia domen z symbolami wieloznacznymi. Możesz usunąć ścieżki z określonych poddomen, określając tę konkretną subdomenę i ścieżkę czyszczenia. Na przykład, jeśli moja usługa Front Door ma *.contoso.com, mogę wyczyścić zasoby mojej subdomeny foo.contoso.com poprzez wpisanie komendy foo.contoso.com/path/*. Obecnie określanie nazw hostów w ścieżce przeczyszczania zawartości jest ograniczone do domen podrzędnych domen z symbolami wieloznacznymi, jeśli ma to zastosowanie.

W przeczyszczeniach pamięci podręcznej w usłudze Front Door nie jest rozróżniana wielkość liter. Ponadto są one niezależne od ciągów zapytań, co oznacza, że wyczyszczenie adresu URL czyści wszystkie jego odmiany ciągu zapytania.

Wygasanie pamięci podręcznej

Poniższa kolejność nagłówków służy do określenia, jak długo element jest przechowywany w naszej 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 jest buforowana. 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 silnika reguł.

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

Uwaga / Notatka

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

Możesz zobaczyć REVALIDATED_HIT w nagłówku Cache-Control odpowiedzi. Oznacza to, że zawartość pamięci podręcznej w usłudze Azure Front Door została ponownie zweryfikowana na serwerze pochodzenia przed obsłużeniem klienta. Może się tak zdarzyć, gdy zawartość pamięci podręcznej wygasła, ale serwer pochodzenia wskazuje, że zawartość nie uległa zmianie. W takim przypadku zawartość pamięci podręcznej jest dostarczana klientowi, a jej okres ważności jest resetowany.

Nagłówki zapytań

Następujące nagłówki żądań nie są przekazywane do źródła, gdy jest włączone buforowanie:

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

Uwaga / Notatka

Żądania zawierające nagłówek autoryzacji nie będą buforowane, chyba że odpowiedź zawiera dyrektywę Cache-Control zezwalającą na 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 buforowana, Set-Cookie nagłówek jest usuwany przed wysłaniem odpowiedzi do klienta. Jeśli odpowiedź źródła nie jest buforowana, usługa Front Door nie usuwa nagłówka. Jeśli na przykład odpowiedź źródłowa zawiera nagłówek Cache-Control z wartością max-age, wskazuje ona usłudze Front Door, że odpowiedź można buforować, a nagłówek Set-Cookie jest usunięty.

Ponadto Front Door dołącza nagłówek X-Cache 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 w pamięci podręcznej, a zawartość jest obsługiwana z pamięci podręcznej usługi Front Door.
  • TCP_MISS: Pierwsze 8 MB odpowiedzi są pominięte przez pamięć podręczną, a zawartość jest pobierana ze źródła.
  • PRIVATE_NOSTORE: Nie można przechowywać żądania w pamięci podręcznej, ponieważ nagłówek odpowiedzi Cache-Control jest ustawiony na private lub no-store.
  • CONFIG_NOCACHE: Żądanie jest skonfigurowane tak, aby nie buforować w profilu usługi Front Door.

Uwaga / Notatka

Usługa Azure Front Door usuwa nagłówek Content-Type dla pustych plików, kiedy buforowanie jest włączone. Aby kontynuować wysyłanie tego nagłówka do klientów, użyj mechanizmu reguł usługi Azure Front Door (Akcja — Modyfikowanie nagłówka odpowiedzi, Operator — Zastępowanie, Nazwa nagłówka — Typ zawartości), aby ręcznie zastąpić go dla takich plików. Można również wyłączyć buforowanie pustych plików, ale takie podejście jest mniej zalecane, ponieważ zwiększa obciążenie źródła i może mieć wpływ na wydajność.

Dzienniki i raporty

Dziennik dostępu zawiera stan pamięci podręcznej dla każdego żądania. Ponadto raporty zawierają informacje o tym, jak pamięć podręczna usługi Azure Front Door jest używana 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 Silniku reguł. Konfiguracja buforowania silnika 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 pamięć podręczna jest włączona, jej zachowanie różni się w zależności od wartości zachowania pamięci podręcznej zastosowanej przez silnik reguł.

    • Honoruj pochodzenie: usługa Azure Front Door zawsze honoruje dyrektywę nagłówka odpowiedzi źródła. Jeśli brakuje dyrektywy origin, usługa Azure Front Door buforuje zawartość na okres od jednego do trzech dni.
    • Zastąp zawsze: usługa Azure Front Door zawsze zastępuje czas trwania pamięci podręcznej, co oznacza, że buforuje zawartość czasu trwania pamięci podręcznej, ignorując wartości z dyrektyw odpowiedzi źródła. To zachowanie ma zastosowanie tylko wtedy, gdy odpowiedź można buforować.
    • Zastąp, jeśli wartości pochodzenia są brakujące: Gdy pochodzenie nie zwraca wartości czasu życia w pamięci podręcznej, usługa Azure Front Door używa określonego czasu trwania pamięci podręcznej. To zachowanie ma zastosowanie tylko wtedy, gdy odpowiedź można buforować.

Uwaga / Notatka

  • Usługa Azure Front Door nie udziela żadnych gwarancji dotyczących czasu przechowywania zawartości 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 być w stanie obsłużyć dane z pamięci podręcznej, nawet jeśli dane w pamięci podręcznej wygasły. Takie zachowanie może sprawić, że witryna pozostanie częściowo dostępna, gdy źródła są w trybie offline.
  • Źródła mogą określać, aby nie buforować określonych odpowiedzi przy użyciu nagłówka Cache-Control z wartością no-cache, private lub no-store. Gdy jest używane w odpowiedzi HTTP z serwera źródłowego do Azure Front Door POPs, usługa Azure Front Door obsługuje dyrektywy Cache-control i przestrzega zasad buforowania dla dyrektyw Cache-Control w RFC 7234 — Hypertext Transfer Protocol (HTTP/1.1): Buforowanie (ietf.org).

Zachowanie i czas trwania pamięci podręcznej można skonfigurować zarówno w regule routingu Front Door Designer, jak i w mechanizmie reguł. Konfiguracja pamięci podręcznej Rules Engine zawsze zastępuje konfigurację reguły routingu w projektancie Front Door.

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

  • Gdy buforowanie jest włączone, zachowanie pamięci podręcznej jest różne dla różnych wartości Użyj domyślnego czasu trwania pamięci podręcznej.

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

Uwaga / Notatka

  • Usługa Azure Front Door (klasyczna) nie gwarantuje czasu przechowywania zawartości 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 być w stanie obsłużyć dane z pamięci podręcznej, nawet jeśli dane w pamięci podręcznej wygasły. Takie zachowanie może sprawić, że witryna pozostanie częściowo dostępna, gdy źródła są w trybie offline.
  • Czas trwania pamięci podręcznej ustawiony w regule routingu projektanta usługi Front Door jest minimalnym czasem trwania pamięci podręcznej. Przesłanianie nie działa, jeśli nagłówek sterujący pamięcią podręczną ze źródła ma większy czas wygaśnięcia niż wartość przesłonięcia.

Treści powiązane

  • Last updated on