Udostępnij za pośrednictwem

Jak działa buforowanie

  • Artykuł

Ważne

Usługa Azure CDN Standard firmy Microsoft (klasyczna) zostanie wycofana 30 września 2027 r. Aby uniknąć zakłóceń w działaniu usługi, należy przeprowadzić migrację profilów usługi Azure CDN Standard z usługi Microsoft (klasycznej) do warstwy Azure Front Door Standard lub Premium do 30 września 2027 r. Aby uzyskać więcej informacji, zobacz Azure CDN Standard from Microsoft (classic) retirement (Wycofanie usługi Azure CDN w warstwie Standardowa z firmy Microsoft (wersja klasyczna).

Usługa Azure CDN z Edgio zostanie wycofana 4 listopada 2025 r. Przed tą datą należy przeprowadzić migrację obciążenia do usługi Azure Front Door, aby uniknąć przerw w działaniu usługi. Aby uzyskać więcej informacji, zobacz Azure CDN from Edgio retirement FAQ (Usługa Azure CDN from Edgio retirement FAQ).

Ten artykuł zawiera omówienie ogólnych pojęć dotyczących buforowania oraz sposobu, w jaki usługa Azure Content Delivery Network używa buforowania w celu zwiększenia wydajności. Jeśli chcesz dowiedzieć się, jak dostosować zachowanie buforowania w punkcie końcowym sieci dostarczania zawartości, zobacz Kontrolowanie zachowania buforowania usługi Azure Content Delivery Network przy użyciu reguł buforowania i Kontrolowanie zachowania buforowania usługi Azure Content Delivery Network przy użyciu ciągów zapytań.

Wprowadzenie do buforowania

Buforowanie to proces przechowywania danych lokalnie, dzięki czemu przyszłe żądania dotyczące tych danych będą uzyskiwane szybciej. W najczęściej używanym typie buforowania buforowanie przeglądarki internetowej przeglądarka internetowa przechowuje kopie danych statycznych lokalnie na lokalnym dysku twardym. Dzięki buforowaniu przeglądarka internetowa może uniknąć wykonywania wielu rund na serwerze i zamiast tego uzyskiwać dostęp do tych samych danych lokalnie, co pozwala zaoszczędzić czas i zasoby. Buforowanie jest odpowiednie do lokalnego zarządzania małymi danymi statycznymi, takimi jak obrazy statyczne, pliki CSS i pliki JavaScript.

Podobnie buforowanie jest używane przez sieć dostarczania zawartości na serwerach brzegowych w pobliżu użytkownika, aby uniknąć żądań powrotnych do źródła i zmniejszenia opóźnienia użytkownika końcowego. W przeciwieństwie do pamięci podręcznej przeglądarki internetowej, która jest używana tylko dla jednego użytkownika, sieć dostarczania zawartości ma udostępnioną pamięć podręczną. W udostępnionej pamięci podręcznej sieci dostarczania zawartości żądanie pliku przez użytkownika może być używane przez innego użytkownika, co znacznie zmniejsza liczbę żądań do serwera pochodzenia.

Zasoby dynamiczne, które zmieniają się często lub są unikatowe dla pojedynczego użytkownika, nie mogą być buforowane. Te typy zasobów mogą jednak korzystać z optymalizacji przyspieszania witryn dynamicznych (DSA) w sieci dostarczania zawartości platformy Azure w celu zwiększenia wydajności.

Buforowanie może wystąpić na wielu poziomach między serwerem pochodzenia a użytkownikiem końcowym:

  • Serwer sieci Web: używa udostępnionej pamięci podręcznej (dla wielu użytkowników).
  • Sieć dostarczania zawartości: używa udostępnionej pamięci podręcznej (dla wielu użytkowników).
  • Dostawca usług internetowych (ISP): używa udostępnionej pamięci podręcznej (dla wielu użytkowników).
  • Przeglądarka internetowa: używa prywatnej pamięci podręcznej (dla jednego użytkownika).

Każda pamięć podręczna zwykle zarządza własną aktualnością zasobów i przeprowadza walidację, gdy plik jest nieaktualny. To zachowanie jest zdefiniowane w specyfikacji buforowania HTTP RFC 7234.

Świeżość zasobów

Ponieważ zasób buforowany może być potencjalnie nieaktualny lub nieaktualny (w porównaniu z odpowiednim zasobem na serwerze pochodzenia), ważne jest, aby każdy mechanizm buforowania kontrolować, kiedy zawartość pobiera odświeżanie. Aby zaoszczędzić czas i zużycie przepustowości, zasób buforowany nie jest porównywany z wersją na serwerze pochodzenia za każdym razem, gdy jest uzyskiwany dostęp. Zamiast tego, o ile zasób buforowany jest uznawany za świeży, przyjmuje się, że jest to najnowsza wersja i jest wysyłany bezpośrednio do klienta. Zasób buforowany jest uznawany za świeży, gdy jego wiek jest krótszy niż wiek lub okres zdefiniowany przez ustawienie pamięci podręcznej. Na przykład gdy przeglądarka ponownie ładuje stronę internetową, sprawdza, czy każdy zasób buforowany na dysku twardym jest świeży i ładuje go. Jeśli zasób nie jest świeży (nieaktualny), kopia aktualna jest ładowana z serwera.

Walidacja

Jeśli zasób jest uznawany za nieaktualny, serwer pochodzenia zostanie poproszony o zweryfikowanie go w celu ustalenia, czy dane w pamięci podręcznej nadal są zgodne z tym, co znajduje się na serwerze pochodzenia. Jeśli plik został zmodyfikowany na serwerze pochodzenia, pamięć podręczna aktualizuje jego wersję zasobu. W przeciwnym razie, jeśli zasób jest świeży, dane są dostarczane bezpośrednio z pamięci podręcznej bez wcześniejszego weryfikowania.

Buforowanie sieci dostarczania zawartości

Buforowanie jest integralną częścią sposobu działania sieci dostarczania zawartości w celu przyspieszenia dostarczania i zmniejszenia obciążenia źródła dla zasobów statycznych, takich jak obrazy, czcionki i filmy wideo. W buforowaniu sieci dostarczania zawartości zasoby statyczne są selektywnie przechowywane na strategicznie umieszczonych serwerach, które są bardziej lokalne dla użytkownika i oferują następujące korzyści:

  • Ponieważ większość ruchu internetowego jest statyczna (na przykład obrazy, czcionki i klipy wideo), buforowanie sieci dostarczania zawartości zmniejsza opóźnienie sieci, przenosząc zawartość bliżej użytkownika, zmniejszając w ten sposób odległość, z jaką dane są przesyłane.

  • Odciążając pracę z siecią dostarczania zawartości, buforowanie może zmniejszyć ruch sieciowy i obciążenie serwera pochodzenia. Zmniejsza to koszty i wymagania dotyczące zasobów aplikacji, nawet jeśli istnieje duża liczba użytkowników.

Podobnie jak w przypadku implementacji buforowania w przeglądarce internetowej, można kontrolować sposób buforowania w sieci dostarczania zawartości, wysyłając nagłówki dyrektywy cache-directive. Nagłówki dyrektywy pamięci podręcznej to nagłówki HTTP, które są zwykle dodawane przez serwer pochodzenia. Chociaż większość tych nagłówków została pierwotnie zaprojektowana do obsługi buforowania w przeglądarkach klienckich, są one również używane przez wszystkie pośrednie pamięci podręczne, takie jak sieci dostarczania zawartości.

Dwa nagłówki mogą służyć do definiowania aktualności pamięci podręcznej: Cache-Control i Expires. Cache-Control jest bardziej aktualny i ma pierwszeństwo przed parametrem Expires, jeśli oba istnieją. Istnieją również dwa typy nagłówków używanych do walidacji (nazywanych modułami sprawdzania poprawności): ETag i Last-Modified. ETag jest bardziej aktualna i ma pierwszeństwo przed parametrem Last-Modified, jeśli obie są zdefiniowane.

Nagłówki dyrektywy pamięci podręcznej

Ważne

Domyślnie punkt końcowy usługi Azure Content Delivery Network zoptymalizowany pod kątem dsA ignoruje nagłówki dyrektywy pamięci podręcznej i pomija buforowanie. W przypadku profilów usługi Azure CDN Standard from Edgio można dostosować sposób traktowania tych nagłówków przez punkt końcowy usługi Azure Content Delivery Network przy użyciu reguł buforowania sieci dostarczania zawartości w celu włączenia buforowania. Tylko w przypadku profilów usługi Azure CDN Premium from Edgio aparat reguł umożliwia buforowanie.

Usługa Azure Content Delivery Network obsługuje następujące nagłówki dyrektywy HTTP cache-directive, które definiują czas trwania pamięci podręcznej i udostępnianie pamięci podręcznej.

Kontrolka pamięci podręcznej:

  • Wprowadzono w protokole HTTP 1.1, aby zapewnić wydawcom sieci Web większą kontrolę nad ich zawartością i sprostać ograniczeniom nagłówka Expires .
  • Expires Zastępuje nagłówek, jeśli jest on zdefiniowany i Cache-Control zdefiniowany.
  • W przypadku użycia w żądaniu HTTP od klienta do sieci dostarczania zawartości POP Cache-Control jest domyślnie ignorowane przez wszystkie profile usługi Azure Content Delivery Network.
  • W przypadku użycia w odpowiedzi HTTP z serwera pochodzenia do sieci dostarczania zawartości POP:

Wygasa:

  • Starszy nagłówek wprowadzony w protokole HTTP 1.0; obsługiwane w celu zapewnienia zgodności z poprzednimi wersjami.
  • Używa godziny wygaśnięcia opartej na dacie z drugą precyzją.
  • Podobnie jak Cache-Control: max-age.
  • Używany, gdy Cache-Control nie istnieje.

Pragma:

  • Domyślnie nie są honorowane przez usługę Azure Content Delivery Network.
  • Starszy nagłówek wprowadzony w protokole HTTP 1.0; obsługiwane w celu zapewnienia zgodności z poprzednimi wersjami.
  • Używany jako nagłówek żądania klienta z następującą dyrektywą: no-cache. Ta dyrektywa nakazuje serwerowi dostarczenie nowej wersji zasobu.
  • Pragma: no-cache jest równoważne z Cache-Control: no-cache.

Moduły sprawdzania poprawności

Gdy pamięć podręczna jest nieaktualna, moduły sprawdzania poprawności pamięci podręcznej HTTP są używane do porównywania buforowanej wersji pliku z wersją na serwerze pochodzenia. Usługa Azure CDN w warstwie Standardowa/Premium z usługi Edgio domyślnie obsługuje zarówno ETag moduły sprawdzania poprawności, jak i Last-Modified moduły sprawdzania poprawności, natomiast usługa Azure CDN Standard firmy Microsoft obsługuje tylko Last-Modified.

ETag:

  • Usługa Azure CDN w warstwie Standardowa/Premium z usługi Edgio domyślnie obsługuje ETag usługę Azure CDN Standard, natomiast usługa Azure CDN Standard firmy Microsoft nie obsługuje.
  • ETag definiuje ciąg, który jest unikatowy dla każdego pliku i wersji pliku. Na przykład ETag: "17f0ddd99ed5bbe4edffdd6496d7131f".
  • Wprowadzony w protokole HTTP 1.1 i jest bardziej aktualny niż Last-Modified. Przydatne, gdy data ostatniej modyfikacji jest trudna do określenia.
  • Obsługuje zarówno silną walidację, jak i słabą walidację; Jednak usługa Azure Content Delivery Network obsługuje tylko silną walidację. W przypadku silnej weryfikacji dwie reprezentacje zasobów muszą być identyczne w bajtach.
  • Pamięć podręczna weryfikuje plik używany ETag przez wysłanie nagłówka If-None-Match z co najmniej jednym ETag modułem sprawdzania poprawności w żądaniu. Na przykład If-None-Match: "17f0ddd99ed5bbe4edffdd6496d7131f". Jeśli wersja serwera jest zgodna z modułem ETag sprawdzania poprawności na liście, wysyła kod stanu 304 (niezmodyfikowany) w odpowiedzi. Jeśli wersja jest inna, serwer odpowiada kodem stanu 200 (OK) i zaktualizowanym zasobem.

Ostatnia modyfikacja:

  • W przypadku usługi Azure CDN w warstwie Standardowa/Premium tylko z pakietu Edgio jest używana, Last-Modified jeśli ETag nie jest częścią odpowiedzi HTTP.
  • Określa datę i godzinę ostatniej modyfikacji zasobu przez serwer pochodzenia. Na przykład Last-Modified: Thu, 19 Oct 2017 09:28:00 GMT.
  • W przypadku zawartości większej niż 8 MB serwery zaplecza pochodzenia powinny zachować spójne Last-Modified znaczniki czasu na zasób. Zwracanie niespójnych Last-Modified czasów z serwerów zaplecza spowoduje błędy niezgodności modułu sprawdzania poprawności i spowoduje błędy HTTP 5XX. Usługa Azure Storage może nie obsługiwać spójnych Last-Modified sygnatur czasowych w replikach, co może powodować podobne błędy niezgodności modułu sprawdzania poprawności.
  • Pamięć podręczna weryfikuje plik przy użyciu, Last-Modified wysyłając If-Modified-Since nagłówek z datą i godziną w żądaniu. Serwer pochodzenia porównuje datę z nagłówkiem Last-Modified najnowszego zasobu. Jeśli zasób nie został zmodyfikowany od określonego czasu, serwer zwraca kod stanu 304 (niezmodyfikowany) w odpowiedzi. Jeśli zasób został zmodyfikowany, serwer zwraca kod stanu 200 (OK) i zaktualizowany zasób.

Określanie, które pliki mogą być buforowane

Nie wszystkie zasoby można buforować. W poniższej tabeli przedstawiono zasoby, które można buforować na podstawie typu odpowiedzi HTTP. Zasoby dostarczane z odpowiedziami HTTP, które nie spełniają wszystkich tych warunków, nie mogą być buforowane. Tylko w przypadku usługi Azure CDN Premium z usługi Edgio można użyć aparatu reguł, aby dostosować niektóre z tych warunków.

Usługa Azure Content Delivery Network firmy Microsoft Usługa Azure Content Delivery Network z pakietu Edgio
Kody stanu HTTP 200, 203, 206, 300, 301, 410, 416 200
Metody HTTP GET, HEAD GET
Limity rozmiaru pliku 300 GB 300 GB

Aby buforowanie usługi Azure CDN w warstwie Standardowa firmy Microsoft działało na zasobie, serwer pochodzenia musi obsługiwać wszystkie żądania HEAD i GET HTTP, a wartości długości zawartości muszą być takie same dla wszystkich odpowiedzi HEAD i GET HTTP dla zasobu. W przypadku żądania HEAD serwer pochodzenia musi obsługiwać żądanie HEAD i musi odpowiadać przy użyciu tych samych nagłówków, jak w przypadku otrzymania żądania GET.

Uwaga

Żądania zawierające nagłówek autoryzacji nie będą buforowane.

Domyślne zachowanie buforowania

W poniższej tabeli opisano domyślne zachowanie buforowania dla produktów Azure Content Delivery Network i ich optymalizacji.

Microsoft: Ogólne dostarczanie w Internecie Edgio: Ogólne dostarczanie w Internecie Edgio: DSA
Pochodzenie honorowe Tak Tak Nie.
czas trwania pamięci podręcznej sieci dostarczania zawartości Dwa dni Siedem dni Brak

Pochodzenie honoru: określa, czy należy honorować obsługiwane nagłówki dyrektywy cache-, jeśli istnieją w odpowiedzi HTTP z serwera pochodzenia.

Czas trwania pamięci podręcznej usługi CDN: określa czas, przez który zasób jest buforowany w sieci dostarczania zawartości platformy Azure. Jeśli jednak źródło honoru ma wartość Tak, a odpowiedź HTTP z serwera pochodzenia zawiera nagłówek Expires dyrektywy pamięci podręcznej lub Cache-Control: max-age, usługa Azure Content Delivery Network używa wartości czasu trwania określonej przez nagłówek.

Uwaga

Usługa Azure Content Delivery Network nie gwarantuje minimalnego czasu przechowywania obiektu w pamięci podręcznej. Buforowana zawartość może zostać wykluczony z pamięci podręcznej sieci dostarczania zawartości, zanim wygaśnie, jeśli zawartość nie jest żądana tak często, aby zapewnić miejsce na częściej żądaną zawartość.

Następne kroki