Is cache always King?

Mnogość usług dostępnych w internecie powoduje, że serwisy, sklepy oraz twórcy walczą o czas użytkownika. Piękny design, czy nawet wysokiej jakości treść często przegrywają z brakiem natychmiastowego dostępu. Wykorzystanie odpowiednich mechanizmów może znacząco podnieść nasze szanse zatrzymanie uwagi użytkownika. Warto jednak upewnić się, czy na pewno dobrze wykorzystujemy dostępne dzisiaj narzędzia i czy jesteśmy świadomi wszystkich zagrożeń, które wynikają z nieprawidłowej ich konfiguracji. W poniższym artykule omówimy, zalety oraz zagrożenia stojące za różnymi mechanizmami “cache”.

Cache – pozwala na zapisywanie części danych, które zazwyczaj niezbyt często ulegają zmianie. Dzięki czemu szybkość dostępu do tych informacji jest znacznie większa. Możemy go podzielić na następujące grupy.

Client Caching – przeglądarka

Za pomocą nagłówków HTTP takich jak „cache-control” czy „expires” jesteśmy w stanie poinstruować przeglądarki na jak długo powinien zostać zapisać dany zasób. Zazwyczaj ogranicza się to tylko do plików statycznych takich jak obrazki oraz pliki z rozszerzeniem css/js. Warto jednak zwrócić uwagę, co stanie się jeżeli pominiemy wcześniej wspomniane nagłówki? Jak wyglądają domyślne ustawienia oraz jaki sposób zachowa się przeglądarka? Czy wszystkie przeglądarki współdzielą te ustawienia?

Większość współczesnych przeglądarek użyje podejścia “heuristic freshness”, i w ten sposób zdecyduje na jak długo zapisać w pamięci podręcznej dany zasób. Obliczanie odbywa się w następujący sposób (więcej na ten temat można znaleźć tutaj RFC 7234).

(obecny czas - czas ostatniej modyfikacji) / 10

Każdy zasób w nagłówkach przesyła informacje o dacie ostatniej modyfikacji. Dla przykładu, jeżeli ostatni raz, obrazek został zmodyfikowany 50 dni temu, to przeglądarka zdecyduje, że warto go zapisać w pamięci na 5 dni bez konieczności ponownego odpytania po “nową” wersję.

Static Files Caching

Dodatkowo coraz więcej stron i aplikacji webowych wykorzystuje mechanizm service worker. Po zarejestrowaniu service worker tworzy osobny wątek, który działa niezależnie względem wątku aktywnej karty po stronie przeglądarki. Jedną z głównych zalet aktywnego service worker jest możliwość cache’owania całych odpowiedzi pochodzących z serwera. Service worker może działać jako caching proxy, które sprawdza czy w danym momencie posiada zapisany element czy też powinien przekazać zapytanie do serwera.

Service Workers

Nie możemy zapomnieć również o ciasteczkach w których możemy przetrzymywać dane. Podobnymi rozwiązanymi cechują się również localStorage oraz sessionStorage, które pozwalają nam na zapisywanie dość sporej ilości danych w formie tekstowej po stronie przeglądarki.

Content Delivery Network

Idea Content Delivery Network (CDN) polega na wykorzystaniu rozproszonej po całym świecie sieci serwerów (Edge Servers) na których przetrzymywane są kopie danych z naszego głównego serwera (Origin Server). Rozwiązanie to szczególnie doceniają twórcy stron i aplikacji, które mają zasięg globalny. Dzięki fizycznemu skróceniu dystansu pomiędzy serwerem a użytkownikiem, znacznie obniżany jest czas odpowiedzi (latency), co przekłada się na szybkość ładowania zasobów. Wykorzystując CDN możemy częściowo lub całkowicie odłączyć nasz główny serwer (Origin Server) z bezpośredniej komunikacji z klientem.

Usługi CDN oferuje wiele firm m.in. Akamai, CloudFlare czy Amazon Web Services (CloudFront). Wielu z dostawców w pakiecie udostępnia darmowe certyfikaty SSL czy też SSL Termination. Posiadanie certyfikatu nie tylko zwiększa bezpieczeństwo użytkowników naszej strony, ale także budzi większe zaufanie. Chrome niejako zmusza twórców do posiadania certyfikatu SSL. Od Lipca 2018 oznacza, strony które nie posiadają certyfikatu jako “niebezpieczne”.

Większość wymienionych usług działa także jako:

1. web application firewall – skupia swoje działania na ochronie stron WWW oraz zapewnia ochronę przed takimi atakami jak np. SQL Injection, Cross Site Scripting, Directory Traversal oraz Command Injection, które mogą prowadzić do podmiany stron WWW, wycieków danych, umieszczenia stron phishingowych lub rozsyłania spamu za pośrednictwem gotowych skryptów.
2. DDoS attack defender – narzędzia tego typu działają jak tarcza dla naszej strony WWW. Uniemożliwiając atakującym zajęcie wszystkich zasobów naszej aplikacji.
3. load balancer – narzędzia odpowiedzialne za odpowiednie rozdzielenie ruchu wewnątrz aplikacji najczęściej w taki sposób aby wszystkie podzespoły tj. procesory, dyski czy połączenia sieciowe działały pod takim samym obciążeniem.

Caching Proxy

Na rynku dostępnych jest wiele gotowych rozwiązań. Od CDN’ów różnią się przede wszystkim tym ,że to my mamy pełną kontrolę nad konfiguracją i możliwością decydowania jaki mechanizm zostanie wykorzystany. Wśród dostępnych narzędzi warto wyróżnić Nginx oraz Varnish, które cieszą się dużą popularnością. Mogą zostać użyte jako “reverse proxy” oraz jako “load balancer”, pozwalają na konfigurację cache’a oraz chronią przed atakami DDoS. Nginx w świadomości wielu użytkowników przede wszystkim figuruje jako “web server”. W sytuacji, gdy korzystamy już z Nginx’a jako web server’a decyzja o wyborze mechanizmu cache jest raczej oczywista. Varnish sprawdzi się dobrze w połączeniu z Apache, które jako bardzo popularny web server nie oferuje tak rozbudowanego mechanizmu cache.

Server Caching – cachowanie po stronie serwera

Często, możemy przyspieszyć naszą stronę, bez ponoszenia dodatkowych kosztów. Z pomocą przychodzą darmowe moduły, które zostały przygotowane przez społeczności budowane wokół danego języka programowania. Wykorzystując istniejące już zasoby i konfigurując odpowiednio dany moduł, możemy w łatwy sposób osiągnąć pożądany efekt. Przykładem, takiego darmowego rozwiązania jest “Alternative PHP Cache”, którego zadaniem jest zmniejszenie ilości pracy jaką wykonuje PHP.

Rozwiązania tego typu są szczególnie warte uwagi, jeżeli zależy nam utrzymaniu kosztów na podobnym poziomie dodatkowo nie wymagają od nas, wprowadzania dodatkowego poziomu komplikacji. Cała operacja odbywa bezpośrednio na serwerach na których działa nasza aplikacja.

Jeżeli już wiemy czym jest cache możemy, zastanowić się na co powinniśmy zwrócić szczególną uwagę.

1. Czy dobrze dobieramy czas cachowania dla danego zasobu?
2. Czy z danego zasobu(server caching) może korzystać więcej niż jeden użytkownik jednoczenie.
3. Jak często dane, które cache’ujemy są odpytywane. Czasami lepiej zrezygnować z cache’a.
4. Czy pamiętamy o tym aby przy kolejnych wersjach naszego kodu wymusić wyczyszczenie cache’a? W przypadku przeglądarek najgorszym rozwiązaniem jest wysłanie informacji do klienta aby wyczyścił cache’a na własną rękę.
5. Czy nasza konfiguracja(server caching) zawiera wykluczenia dla zasobów, których nie chcemy cache’ować.
6. Czy nasz mechanizm cache poprawnie reaguje na nagłówki w protokole HTTP t.j “cache-control: no-cache, no-store”.

Zagrożenia

Użycie cache’a ma jednak swoje wady, o których warto wiedzieć. W zależności od typu rozwiązania:

1. Dodatkowy mechanizm w systemie oznacza jego komplikację i może wprowadzić nowy typ awarii
2. Niepoprawna inwalidacja – np. brak dostępu użytkownika do pewnych funkcjonalności strony z powodu nieaktualnych zasobów
3. Wyciek wrażliwych danych spowodowany cache’owaniem odpowiedzi serwera, które powinny być dostępne tylko w obrębie sesji zalogowanego użytkownika.

To ostatnie zagrożenie jest szczególnie istotne ponieważ uderza w bezpieczeństwo danych klientów sklepu.

Wykrycie nieprawidłowej konfiguracji

W sieci jest wiele dostępnych narzędzi, które przeprowadzą audyt naszej strony pod względem wydajności. Otrzymamy również informacje na temat jej “dostępności”. W jakim stopniu strona jest zgodna z współczesnymi standardami oraz szczegółowy raport z wskazanymi elementami do poprawy. Warto w tym miejscu wspomnieć o narzędziach tj:

1. https://developers.google.com/speed/pagespeed/insights/
2. https://web.dev/
3. “Audits” dostępne z poziomu DevTools przeglądarki Chrome

Jednak żadne z wyżej wymienionych rozwiązań nie poinformuje nas, kiedy na naszej stronie dojdzie do wycieku danych wynikającym ze złej konfiguracji cache’a. Aby pomóc naszym klientom zminimalizować ryzyko takich błędów stworzyliśmy PageCacheDetector. Ten heurystyczny mechanizm jest w stanie ocenić z dużym prawdopodobieństwem czy dochodzi do wycieku danych na sklepach klientów edrone. Bazując na zdarzeniach generowanych przez użytkowników, adresach IP, przeglądarce, typu wizyty i innych czynnikach algorytm ustala prawdopodobieństwo występowania niepoprawnych danych. Gdy próg zostanie przekroczony, mechanizm pobiera zawartość strony, na której może dochodzić do wycieku danych i weryfikuje jej treść. W przypadku potwierdzenia natychmiast informujemy o tym naszego klienta.

Oczywiście najlepszym lekarstwem jest prewencja czyli dobra znajomość używanych przez siebie technologii oraz dokładne testowanie konfiguracji swojego sklepu pod kątem cache’a i danych osobowych.