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 została wycofana 15 stycznia 2025 r. 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

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 Cache-Control jest domyślnie honorowany przez wszystkie profile usługi Azure Content Delivery Network. Usługa Azure CDN honoruje również zachowania buforowania dla dyrektyw Cache-Control w RFC 7234 — Protokół transferu hipertekstowego (HTTP/1.1): buforowanie (ietf.org).

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 Standard firmy Microsoft obsługuje tylko Last-Modifiedusługę .

Uwaga

Usługa Azure CDN firmy Microsoft (klasyczna) nie obsługuje ETagusługi .

Ostatnia modyfikacja:

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

Warunki Wartość
Kody stanu HTTP 200, 203, 206, 300, 301, 410, 416
Metody HTTP GET, HEAD
Limity rozmiaru pliku 300 GB

Aby buforowanie 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

Domyślnym zachowaniem buforowania dla usługi Azure CDN jest honorowanie zawartości źródła i pamięci podręcznej przez dwa dni.

Pochodzenie honoru: to ustawienie określa, czy należy przestrzegać nagłówków dyrektywy cache-(Cache-Control lub Expires), jeśli znajdują się one w odpowiedzi HTTP z serwera pochodzenia.

Czas trwania pamięci podręcznej usługi CDN: to ustawienie określa czas trwania, przez który zasób jest buforowany w usłudze Azure CDN. Jeśli źródło Honor jest włączone, a odpowiedź HTTP z serwera pochodzenia zawiera Cache-Control: max-age nagłówek lub Expires , usługa Azure CDN będzie używać czasu trwania określonego przez te nagłówki zamiast domyślnego okresu dwudniowego.

Uwaga

Usługa Azure CDN 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