Jak działa buforowanie

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 jest proces przechowywania danych lokalnie, aby przyszłe żądania dotyczące tych danych mogły być 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 doskonale nadaje się 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 mogą 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 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:
  • Usługi Azure CDN Standard/Premium z usług Edgio i Azure CDN Standard firmy Microsoft obsługują wszystkie Cache-Control dyrektywy.
  • Usługi Azure CDN Standard/Premium z Edgio i Azure CDN Standard firmy Microsoft honoruje 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.

Pragmy:

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

Walidatory

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

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.

Domyślne zachowanie buforowania

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

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.

Następne kroki

• Aby dowiedzieć się, jak dostosować i zastąpić domyślne zachowanie buforowania w sieci dostarczania zawartości za pomocą reguł buforowania, zobacz Kontrolowanie zachowania buforowania usługi Azure Content Delivery Network przy użyciu reguł buforowania.
• Aby dowiedzieć się, jak używać ciągów zapytań do kontrolowania zachowania buforowania, zobacz Control Azure Content Delivery Network caching behavior with query strings (Kontrolowanie zachowania buforowania usługi Azure Content Delivery Network za pomocą ciągów zapytań).