How to Configure Cache-Control Headers in Apache

  • Anthony Heddings
  • July 29, 2020, 11:00am EDT

apache

Przeglądarka każdego użytkownika korzysta z wbudowanej pamięci podręcznej do przechowywania pobranych obiektów, co może znacznie przyspieszyć ponowne odwiedziny witryny dzięki ładowaniu z dysku, a nie z sieci. Oto jak to skonfigurować w Apache.

Jak działa buforowanie?

Przy pierwszym połączeniu z witryną użytkownik pobiera wszystkie zasoby statyczne niezbędne do renderowania strony, włączając w to rzeczy takie jak logo. Kiedy użytkownik przejdzie do nowej strony, załaduje logo z pamięci, zamiast prosić o nie ponownie, co znacznie przyspieszy działanie i zmniejszy obciążenie serwera sieciowego w tym procesie.

Jest to pamięć podręczna po stronie klienta, ale wiele witryn będzie również korzystać z sieci dostarczania treści, lub CDN. CDN to sieć serwerów, które siedzą przed Twoim głównym serwerem internetowym lub serwerem „origin”. Ta sieć buforuje strony, zwiększając maksymalną przepustowość, zmniejszając opóźnienia w dostępie i znacznie zmniejszając obciążenie serwera źródłowego. Jeśli chcesz dowiedzieć się więcej o sieciach CDN, możesz przeczytać nasz przewodnik na ich temat tutaj.

Cache-Control to nagłówek, który możesz skonfigurować swój serwer WWW, aby dodawał go do wszystkich wychodzących żądań, które powiedzą przeglądarce i sieciom CDN, jak buforować twoją zawartość.

Reklama

Niektóre strony nigdy nie powinny być buforowane przez współdzielone pamięci podręczne, takie jak sieci CDN. Zrobienie tego spowoduje ryzyko wyświetlenia danych osobowych jednego użytkownika innym. Jako ogólna zasada, jeśli strona będzie dokładnie taka sama dla wszystkich użytkowników, jak strona główna, możesz ją buforować. Jeśli natomiast pokazuje poufne informacje o użytkowniku, należy usunąć ją z pamięci podręcznej na czarną listę. Zasoby statyczne, takie jak CSS i obrazy, mogą być zazwyczaj buforowane dla wszystkich, często na znacznie dłużej.

Ważna jest również ilość czasu, jaką obiekt spędza w buforze. Określany jako Time-To-Live (TTL), maksymalny wiek twoich zbuforowanych zasobów określa jak długo obiekt pozostanie w buforze zanim zostanie unieważniony i skłoni użytkownika do zażądania nowego obiektu. Dla statycznych zasobów, które nie zmieniają się zbytnio, możesz ustawić bardzo wysokie wartości TTL, zazwyczaj około dwóch lat. Dla rzeczy, które możesz chcieć aktualizować, będziesz chciał ustawić niższe wartości TTL, aby zapobiec zbyt długiemu przebywaniu nieświeżych zasobów w pamięci podręcznej.

Zawsze możesz użyć nazw plików z wersjami, aby wywołać przeładowanie pamięci podręcznej. Jeśli wypuścisz nową wersję arkusza stylów CSS, możesz nazwać go styles-1.0.1.css, a przeglądarka użytkownika (i wszystkie sieci CDN przed nią) zobaczy go jako nowy plik, który musi zostać ponownie pobrany. Dodatkowo, dla niektórych CDN-ów, możesz wydawać ręczne unieważnienia, aby przepłukać istniejącą pamięć podręczną bez zmiany nazw plików.

How to Use Cache-Control in Apache

Cache-Control ma kilka opcji:

  • public – Może być buforowany przez każdego, włączając przeglądarki i CDN-y. Użyj tej opcji dla większości obiektów statycznych.
  • private – Zawiera wrażliwe dane, które nie mogą być buforowane przez sieci CDN lub odwrotne proxy. Przeglądarka użytkownika może buforować je lokalnie. Użyj tego dla większości stron uwierzytelnionych.
  • no-cache – Pomimo nazwy, nie wyłącza buforowania. Przeglądarka może nadal buforować odpowiedź w celu zwiększenia wydajności, ale musi sprawdzić aktualizacje na serwerze źródłowym przed jej użyciem. Użyj tego, jeśli chcesz, aby użytkownik musiał ponownie zatwierdzać za każdym razem.
  • no-store – Wyłącza buforowanie całkowicie. Użyj tego tylko dla bardzo wrażliwych danych, które nie powinny być wysyłane dwa razy.

Dodatkowo, możesz dodać dyrektywę no-transform, która wyłącza wszelkie konwersje, które mogą być wykonane na zasobie. Na przykład, niektóre sieci CDN kompresują obrazy, aby zmniejszyć przepustowość. Ta dyrektywa wyłącza takie zachowanie.

W Apache będziesz musiał ustawić ten nagłówek ręcznie, używając dyrektywy Header set, jak poniżej:

Header set Cache-Control "max-age=84600, public"

Wartość max-age jest ustawiana w sekundach, na przykład max-age=300 dla pięciominutowego TTL, a max-age=63072000 dla dwóch lat.

Reklama

Możesz umieścić tę dyrektywę w korzeniu swojej konfiguracji, aby zastosować ją w całej witrynie, ale lepszą metodą jest zastosowanie ustawień w zależności od typu pliku. Na przykład, aby ustawić wysoki TTL dla większości statycznych mediów, możesz użyć bloku FilesMatch:

<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$"> Header set Cache-Control "max-age=63072000, public" </FilesMatch>

Jeśli chcesz umieścić konkretną ścieżkę na czarnej liście przed buforowaniem przez CDNy, możesz użyć bloku Directory:

<Directory "/private"> Header set Cache-Control "max-age=300, private" </Directory> 

Albo po prostu dopasować pojedynczy plik:

<File "protected.html"> Header set Cache-Control "max-age=300, private" </File>

Bloki z bardziej szczegółowymi dopasowaniami będą miały pierwszeństwo przed ogólnymi dopasowaniami regex, ale będziesz chciał sprawdzić, czy wszystko jest ustawione poprawnie po stronie odbierającej. Możesz to sprawdzić w DevTools Chrome’a, w zakładce Network > Headers.

chrome devtools network tab

Jeśli masz dostęp tylko do konfiguracji .htaccess, możesz nadal używać dopasowywania katalogów, tworząc nowy plik .htaccess w każdym podkatalogu.

Use Surrogate-Control to Modify CDN Behaviorly Directly

Nagłówek Surrogate-Control działa dokładnie tak samo jak Cache-Control, ale wyszczególnia konkretne instrukcje dla sieci CDN i odwrotnych serwerów proxy, a nie dla użytkowników końcowych. W ten sposób można powiedzieć sieciom CDN, aby robiły jedną rzecz, ale wysyłały różne kierunki do przeglądarki.

Reklama

Będziesz musiał ustawić ten nagłówek ręcznie, w taki sam sposób, jak ustawiłeś Cache-Control:

Header set Surrogate-Control "max-age=300, public"

Na pewno chcesz przetestować swoją sieć CDN, aby sprawdzić, czy to działa-Surrogate-Control jest dość nowy i nie jest uniwersalny.

Anthony Heddings
Anthony Heddings jest inżynierem ds. chmury dla LifeSavvy Media, pisarzem technicznym, programistą i ekspertem platformy AWS firmy Amazon. Napisał setki artykułów dla How-To Geek i CloudSavvy IT, które zostały przeczytane miliony razy.Read Full Bio ”

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.