[Nie] używaj CDN

Prawie każdy artykuł lub narzędzie do optymalizacji szybkości witryny zawiera skromną klauzulę „użyj CDN”. Ogólnie rzecz biorąc, CDN to sieć dostarczania treści lub sieć dostarczania treści. W Method Lab często spotykamy się z pytaniami klientów na ten temat; niektórzy z nich umożliwiają własne CDN. Celem tego artykułu jest zrozumienie, co CDN może zapewnić w zakresie szybkości ładowania witryny, jakie problemy mogą się pojawić i w jakich przypadkach użycie CDN jest uzasadnione.

Opóźnienia zakreślone na obrazku są spowodowane użyciem sieci CDN.

Trochę historii

Podobnie jak wiele technologii, sieci CDN pojawiły się z konieczności. Wraz z rozwojem kanałów internetowych wśród internautów pojawiły się usługi wideo online. Naturalnie treść wideo wymaga o rząd wielkości większej przepustowości w porównaniu ze zwykłą zawartością witryny internetowej (zdjęcia, tekst i kod CSS lub JS).

Podczas próby transmisji strumienia wideo równolegle do wielu klientów z jednego serwera, kanał internetowy serwera najprawdopodobniej stanie się wąskim gardłem. Z reguły wystarczy kilka tysięcy wątków, aby zatkać typowy kanał serwera. Oczywiście mogą istnieć inne ograniczenia zasobów, ale nie są one obecnie ważne. Ważne jest również to, że rozbudowa kanału serwerowego jest zbyt kosztowna (a czasami niemożliwa), a także niepraktyczna. Obciążenie kanału podczas transmisji będzie miało charakter cykliczny.

Problem ograniczenia kanału pojedynczego serwera doskonale rozwiązuje CDN. Klienci nie łączą się bezpośrednio z serwerem, ale z węzłami w sieci CDN. W idealnej sytuacji serwer wysyła jeden strumień do węzła CDN, a następnie sieć wykorzystując własne zasoby dostarcza ten strumień do wielu użytkowników. Z ekonomicznego punktu widzenia płacimy tylko za faktycznie wykorzystane zasoby (może to być przepustowość lub ruch) i uzyskujemy doskonałą skalowalność naszej usługi. Korzystanie z CDN do dostarczania ciężkich treści jest w pełni uzasadnione i logiczne. Chociaż warto zauważyć, że najwięksi gracze w tej przestrzeni (np. Netflix) budują własne sieci CDN zamiast korzystać z dużych komercyjnych sieci CDN (Akamai, Cloudflare, Fastly itp.)

Wraz z ewolucją Internetu same aplikacje internetowe stały się bardziej złożone i złożone. Na pierwszy plan wysunął się problem szybkości ładowania. Entuzjaści szybkości witryn szybko zidentyfikowali kilka głównych problemów, które powodowały powolne ładowanie witryn. Jednym z nich były opóźnienia sieciowe (RTT – round trip time lub ping time). Opóźnienia wpływają na wiele procesów ładowania strony internetowej: nawiązanie połączenia TCP, rozpoczęcie sesji TLS, załadowanie każdego pojedynczego zasobu (obrazu, pliku JS, dokumentu HTML itp.)

Problem pogłębiał fakt, że w przypadku korzystania z protokołu HTTP/1.1 (przed pojawieniem się SPDY, QUIC i HTTP/2 była to jedyna możliwość) przeglądarki otwierają nie więcej niż 6 połączeń TCP z jednym hostem. Wszystko to doprowadziło do przestojów w łączeniu i nieefektywnego wykorzystania przepustowości kanału. Problem został częściowo rozwiązany poprzez sharding domeny – utworzenie dodatkowych hostów w celu pokonania limitu liczby połączeń.

Tutaj pojawia się druga zdolność CDN - redukcja opóźnień (RTT) ze względu na dużą liczbę punktów i bliskość węzłów do użytkownika. Odległość odgrywa tu decydującą rolę: prędkość światła jest ograniczona (w światłowodzie około 200 000 km/s). Oznacza to, że każde 1000 km podróży dodaje 5 ms opóźnienia lub 10 ms do RTT. Jest to minimalny czas wymagany do transmisji, ponieważ występują również opóźnienia na urządzeniach pośredniczących. Ponieważ sieć CDN zazwyczaj wie, jak buforować obiekty na swoich serwerach, możemy skorzystać z ładowania takich obiektów za pośrednictwem sieci CDN. Warunki niezbędne do tego: obecność obiektu w pamięci podręcznej, bliskość punktu CDN do użytkownika w porównaniu z serwerem aplikacji internetowej (serwerem pochodzenia). Ważne jest, aby zrozumieć, że bliskość geograficzna węzła CDN nie gwarantuje małych opóźnień. Routing pomiędzy klientem a siecią CDN można zbudować w taki sposób, aby klient łączył się z hostem w innym kraju i ewentualnie na innym kontynencie. Tutaj wchodzą w grę relacje pomiędzy operatorami telekomunikacyjnymi a usługą CDN (peering, połączenia, udział w IX itp.) oraz polityka routingu ruchu samego CDN. Przykładowo Cloudflare korzystając z dwóch planów początkowych (bezpłatnego i taniego) nie gwarantuje dostarczenia treści od najbliższego hosta – host zostanie wybrany tak, aby osiągnąć minimalny koszt.

Wiele wiodących firm internetowych przyciąga zainteresowanie opinii publicznej (twórców stron internetowych i właścicieli usług) tematem szybkości ładowania i wydajności witryny. Wśród tych firm są Yahoo (narzędzie Yslow), AOL (WebPageTest) i Google (usługa Page Speed ​​Insights), które opracowują własne rekomendacje dotyczące przyspieszania stron (dotyczą one przede wszystkim optymalizacji klienta). Później pojawiają się nowe narzędzia do testowania szybkości witryny, które zawierają również wskazówki dotyczące zwiększania szybkości witryny. Każda z tych usług lub wtyczek ma spójne zalecenie: „Użyj CDN”. Jako wyjaśnienie wpływu CDN zwykle podaje się zmniejszenie opóźnień sieci. Niestety nie wszyscy są gotowi dokładnie zrozumieć, w jaki sposób osiąga się efekt przyspieszenia CDN i jak można go zmierzyć, dlatego zalecenie należy brać na wiarę i traktować jako postulat. W rzeczywistości nie wszystkie sieci CDN są sobie równe.

Korzystanie z CDN dzisiaj

Aby ocenić przydatność wykorzystania sieci CDN, należy je sklasyfikować. Co można obecnie znaleźć w praktyce (przykłady w nawiasach nie są oczywiście wyczerpujące):

1. Bezpłatny CDN do dystrybucji bibliotek JS (MaxCDN, Google. Yandex).
2. CDN usług optymalizacji klienta (na przykład Google Fonts dla czcionek, Cloudinary, Cloudimage dla obrazów).
3. CDN do optymalizacji statycznej i zasobów w CMS (dostępny w Bitrix, WordPress i innych).
4. CDN ogólnego przeznaczenia (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN do przyspieszania stron internetowych (Cloudflare, Imperva, Airi).

Kluczową różnicą między tymi typami jest ilość ruchu przechodzącego przez CDN. Typy 1-3 to dostarczenie tylko części treści: od jednego żądania do kilkudziesięciu (zwykle zdjęć). Typy 4 i 5 to pełne proxy ruchu poprzez CDN.

W praktyce oznacza to liczbę połączeń, które służą do załadowania witryny. W przypadku protokołu HTTP/2 używamy pojedynczego połączenia TCP z hostem do przetwarzania dowolnej liczby żądań. Jeśli podzielimy zasoby na głównego hosta (Origin) i CDN, wówczas konieczne jest rozłożenie żądań na kilka domen i utworzenie kilku połączeń TCP. Najgorszy przypadek to: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Wzór ten nie uwzględnia opóźnień w sieciach komórkowych w przypadku aktywacji kanału radiowego urządzenia (jeżeli nie był on aktywny) oraz opóźnień na wieży komórkowej.

Oto jak to wygląda w kaskadzie ładowania witryny (opóźnienia w łączeniu się z CDN są podświetlone przy RTT 150 ms):

Jeśli CDN pokrywa cały ruch w witrynie (z wyjątkiem usług stron trzecich), wówczas możemy skorzystać z pojedynczego połączenia TCP, oszczędzając opóźnienia w łączeniu się z dodatkowymi hostami. Dotyczy to oczywiście połączeń HTTP/2.

Dalsze różnice zależą od funkcjonalności konkretnego CDN - w przypadku pierwszego typu jest to po prostu hosting pliku statycznego, w przypadku piątego zmienia się kilka rodzajów zawartości witryny w celu optymalizacji.

Możliwości CDN do przyspieszania stron internetowych

Opiszmy pełen zakres możliwości CDN w zakresie akceleracji witryn, bez względu na funkcjonalność poszczególnych typów CDN, a następnie zobaczmy, co jest zaimplementowane w każdym z nich.

1. Kompresja zasobów tekstowych

Najbardziej podstawowa i zrozumiała funkcja, ale często słabo zaimplementowana. Wszystkie sieci CDN deklarują obecność kompresji jako funkcję przyspieszania. Ale jeśli przyjrzysz się bardziej szczegółowo, niedociągnięcia staną się jasne:

• można zastosować niskie stopnie kompresji dynamicznej - 5-6 (na przykład dla gzip maksymalnie 9);
• kompresja statyczna (pliki w pamięci podręcznej) nie wykorzystuje dodatkowych funkcji (np. zopfi lub brotli o stopniu 11)
• nie ma obsługi wydajnej kompresji brotli (oszczędność około 20% w porównaniu do gzip).

Jeśli korzystasz z CDN, warto sprawdzić te kilka punktów: weź plik, który przyszedł z CDN, zapisz jego skompresowany rozmiar i skompresuj go ręcznie dla porównania (możesz skorzystać z jakiegoś serwisu internetowego z obsługą brotli, np. vsszhat.rf).

2. Ustawianie nagłówków buforowania klienta

Również prosta funkcja przyspieszania: dodaj nagłówki do buforowania zawartości przez klienta (przeglądarkę). Najbardziej aktualny nagłówek to kontrola pamięci podręcznej, przestarzały wygasł. Dodatkowo można zastosować Etag. Najważniejsze jest to, że maksymalny wiek kontroli pamięci podręcznej jest wystarczająco duży (od miesiąca lub dłużej).Jeśli jesteś gotowy, aby buforować zasób tak mocno, jak to możliwe, możesz dodać opcję niezmienną.

Sieci CDN mogą obniżyć wartość maksymalnego wieku, zmuszając użytkownika do częstszego ponownego ładowania zawartości statycznej. Nie jest jasne, z czym jest to związane: chęcią zwiększenia ruchu w sieci lub zwiększenia kompatybilności z witrynami, które nie wiedzą, jak zresetować pamięć podręczną. Na przykład domyślny czas pamięci podręcznej nagłówka Cloudflare wynosi 1 godzinę, co jest bardzo krótkim czasem w przypadku niezmiennych danych statycznych.

3. Optymalizacja obrazu

Ponieważ CDN przejmuje funkcje buforowania i udostępniania obrazów, logiczne byłoby zoptymalizowanie ich po stronie CDN i udostępnienie użytkownikom w tej formie. Zarezerwujmy od razu, że ta funkcja jest dostępna tylko dla CDN typu 2, 3 i 5.

Możesz optymalizować obrazy na różne sposoby: używając zaawansowanych formatów kompresji (takich jak WebP), wydajniejszych koderów (MozJPEG) lub po prostu usuwając niepotrzebne metadane.

Ogólnie rzecz biorąc, istnieją dwa rodzaje takich optymalizacji: z utratą jakości i bez utraty jakości. Sieci CDN zwykle starają się stosować optymalizację bezstratną, aby uniknąć ewentualnych skarg klientów dotyczących zmian w jakości obrazu. W takich warunkach zysk będzie minimalny. W rzeczywistości często poziom jakości JPEG jest znacznie wyższy niż jest to konieczne i można bezpiecznie dokonać ponownej kompresji przy niższym poziomie jakości, nie pogarszając komfortu użytkowania. Z drugiej strony trudno określić uniwersalnie poziom jakości i ustawienia dla wszystkich możliwych aplikacji webowych, dlatego CDN-y stosują bardziej konserwatywne ustawienia w porównaniu do tych, które można zastosować biorąc pod uwagę kontekst (przeznaczenie obrazów, rodzaj aplikacji webowej) itp.)

4. Optymalizacja połączenia TLS

Większość ruchu odbywa się obecnie za pośrednictwem połączeń TLS, co oznacza, że ​​spędzamy dodatkowy czas na negocjacjach TLS. Ostatnio opracowano nowe technologie, które przyspieszają ten proces. Na przykład jest to kryptografia EC, TLS 1.3, pamięć podręczna sesji i bilety, sprzętowa akceleracja szyfrowania (AES-NI) itp. Prawidłowe ustawienie TLS może skrócić czas połączenia do 0-1 RTT (nie licząc DNS i TCP ).

Dzięki nowoczesnemu oprogramowaniu samodzielne wdrożenie takich praktyk nie jest trudne.

Nie wszystkie sieci CDN wdrażają najlepsze praktyki TLS; możesz to sprawdzić, mierząc czas połączenia TLS (na przykład w teście strony internetowej). Idealny na nowe połączenie - 1RTT, 2RTT - poziom średni, 3RTT i więcej - zły.

Należy też zaznaczyć, że nawet w przypadku korzystania z TLS na poziomie CDN, serwer z naszą aplikacją webową również musi przetwarzać TLS, ale od strony CDN, gdyż ruch pomiędzy serwerem a CDN przechodzi po sieci publicznej. W najgorszym wypadku otrzymamy podwójne opóźnienia połączenia TLS (pierwsze do hosta CDN, drugie pomiędzy nim a naszym serwerem).

W przypadku niektórych aplikacji warto zwrócić uwagę na kwestie bezpieczeństwa: ruch jest zwykle odszyfrowywany w węzłach CDN i jest to potencjalna szansa na przechwycenie ruchu. Opcja pracy bez ujawniania ruchu jest zwykle oferowana w najlepszych planach taryfowych za dodatkową opłatą.

5. Zmniejsz opóźnienia w połączeniach

Główna zaleta CDN, o której wszyscy mówią: małe opóźnienia (mniejsza odległość) między hostem CDN a użytkownikiem. Osiąga się to poprzez stworzenie rozproszonej geograficznie architektury sieciowej, w której hosty zlokalizowane są w punktach koncentracji użytkowników (miasta, punkty wymiany ruchu itp.)

W praktyce priorytety dla różnych sieci mogą dotyczyć określonych regionów. Na przykład rosyjskie sieci CDN będą miały więcej punktów obecności w Rosji. Amerykańscy będą przede wszystkim rozwijać sieć w USA. Przykładowo jeden z największych CDN Cloudflare ma tylko 2 punkty w Rosji – w Moskwie i Sankt Petersburgu. Oznacza to, że możemy zaoszczędzić maksymalnie około 10 ms opóźnienia w porównaniu z bezpośrednim umieszczeniem w Moskwie.

Większość zachodnich sieci CDN w ogóle nie ma punktów w Rosji. Łącząc się z nimi, możesz jedynie zwiększyć opóźnienia dla rosyjskich odbiorców.

6. Optymalizacja treści (minifikacja, zmiany strukturalne)

Najbardziej złożony i zaawansowany technologicznie punkt. Zmiana treści w trakcie dostawy może być bardzo ryzykowna. Nawet jeśli przyjmiemy minifikację: zmniejszenie kodu źródłowego (ze względu na dodatkowe spacje, nieistotne struktury itp.) może mieć wpływ na jego wydajność. Jeśli mówimy o poważniejszych zmianach - przeniesieniu kodu JS na koniec HTML, łączeniu plików itp. - ryzyko zakłócenia funkcjonalności serwisu jest jeszcze większe.

Dlatego robią to tylko niektóre sieci CDN typu 5. Oczywiście nie da się zautomatyzować wszystkich zmian potrzebnych do przyspieszenia działania – wymagana jest ręczna analiza i optymalizacja. Na przykład usunięcie nieużywanego lub zduplikowanego kodu jest zadaniem ręcznym.

Z reguły wszystkie takie optymalizacje są kontrolowane przez ustawienia, a najbardziej niebezpieczne są domyślnie wyłączone.

Obsługa możliwości akceleracji według typu CDN

Przyjrzyjmy się więc, jakie potencjalne możliwości przyspieszenia zapewniają różne typy sieci CDN.

Dla wygody powtarzamy klasyfikację.

1. Bezpłatny CDN do dystrybucji bibliotek JS (MaxCDN, Google. Yandex).
2. CDN usług optymalizacji klienta (na przykład Google Fonts dla czcionek, Cloudinary, Cloudimage dla obrazów).
3. CDN do optymalizacji statycznej i zasobów w CMS (dostępny w Bitrix, WordPress i innych).
4. CDN ogólnego przeznaczenia (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN do przyspieszania stron internetowych (Cloudflare, Imperva, Airi).

Porównajmy teraz funkcje i typy CDN.

Okazja
Typ 1
Typ 2
Typ 3
Typ 4
Typ 5

Kompresja tekstu
+–
-
+–
+–
+

Nagłówki pamięci podręcznej
+
+
+
+
+

Zdjęcia
-
+–
+–
-
+

TLS
-
-
-
+–
+

Opóźnienia
-
-
-
+
+

Zawartość
-
-
-
-
+

W tej tabeli „+” oznacza pełne wsparcie, „–” oznacza brak wsparcia, a „+–” oznacza częściowe wsparcie. Oczywiście w rzeczywistości mogą występować odchylenia od tej tabeli (na przykład niektóre CDN ogólnego przeznaczenia zaimplementują funkcje optymalizacji obrazów), ale dla ogólnego pomysłu jest to przydatne.

Wyniki

Mamy nadzieję, że po przeczytaniu tego artykułu będziesz miał jaśniejszy obraz zalecenia „użyj CDN”, aby przyspieszyć swoje witryny.

Jak w każdym biznesie, nie można wierzyć obietnicom marketingowym jakiejkolwiek usługi. Efekt należy zmierzyć i przetestować w rzeczywistych warunkach. Jeśli korzystasz już z CDN-a, sprawdź jego skuteczność, korzystając z kryteriów opisanych w artykule.

Możliwe, że korzystanie z CDN w tej chwili spowalnia czas ładowania Twojej witryny.

Ogólnie rzecz biorąc, możemy skupić się na następujących kwestiach: zbadaj swoją publiczność, określ jej zasięg geograficzny. Jeśli Twoi główni odbiorcy są skupieni w promieniu 1-2 tysięcy kilometrów, nie potrzebujesz CDN do swojego głównego celu - zmniejszenia opóźnień. Zamiast tego możesz umieścić swój serwer bliżej użytkowników i odpowiednio go skonfigurować, uzyskując większość optymalizacji opisanych w artykule (bezpłatnie i na stałe).

Jeśli Twoi odbiorcy są naprawdę rozproszeni geograficznie (w promieniu ponad 3000 kilometrów), korzystanie z wysokiej jakości CDN będzie naprawdę przydatne. Musisz jednak z góry zrozumieć, co dokładnie może przyspieszyć Twój CDN (zobacz tabelę możliwości i ich opis). Jednak przyspieszenie strony internetowej nadal pozostaje złożonym zadaniem, którego nie da się rozwiązać poprzez podłączenie CDN. Oprócz powyższych optymalizacji, za CDN pozostają najskuteczniejsze środki przyspieszające: optymalizacja części serwerowej, zaawansowane zmiany w części klienckiej (usunięcie nieużywanego kodu, optymalizacja procesu renderowania, praca z treścią, czcionkami, możliwości adaptacji itp.). )

Źródło: www.habr.com