[Не] използвайте CDN

Практически във всяка статия или инструмент за оптимизация на скоростта на сайтовете има скромен пункт „използвайте CDN“. Всъщност, CDN е мрежа за доставка на съдържание. В компанията „Метод Лаб“ често получаваме въпроси от клиенти по тази тема, а някои сами активират CDN. Целта на тази статия е да изясни какво може да предложи CDN от гледна точка на скоростта на зареждане на сайта, какви проблеми могат да възникнат и в какви случаи използването на CDN е оправдано.

Обведените на картинката забавяния са причинени от използването на CDN.

Малко история

Както много технологии, CDN се появяват по необходимост. С развитието на интернет каналите за потребителите на мрежата, се появяват услуги за онлайн видео. Естествено, че видео съдържанието изисква многократно по-голяма пропускна способност в сравнение с обикновеното съдържание на сайтовете (картини, текст и CSS или JS код).

При опит за паралелна транслация на видео поток на множество клиенти от един сървър, тесният момент вероятно ще бъде интернет каналът на сървъра. Обикновено, няколко хиляди потока са достатъчни, за да запушат типичния канал на сървъра. Разбира се, могат да има и други ограничения по ресурсите, но в момента те не са важни. Също така е важно, че разширяването на канала на сървъра е твърде скъпо (а понякога и невъзможно), и не е икономически целесъобразно. Натоварването на канала при транслации ще бъде циклично.

Проблемът с ограничението на канала на отделния сървър отлично се решава от CDN. Клиентите не се свързват директно със сървъра, а с възли на мрежата на CDN. В идеалната ситуация, сървърът предоставя един поток на възела на CDN, а по-нататък мрежата използва собствените си ресурси за доставка на този поток на множество потребители. От икономическа гледна точка, плащаме само за фактически използваните ресурси (може да бъде пропускната способност или трафик) и получаваме отлична мащабируемост на нашия сервис. Използването на CDN за доставка на тежко съдържание е напълно оправдано и логично. Въпреки това, струва си да се отбележи, че най-големите играчи в тази област (например, Netflix) изграждат свои собствени CDN вместо да използват големи търговски CDN (Akamai, Cloudflare, Fastly и т.н.).

С развитието на уеба, самите уеб приложения станаха по-сложни и тежки. На преден план излезе проблемът със скоростта на зареждане. Ентусиастите по бързината на сайтовете доста бързо откриха няколко основни проблема, които водят до бавно зареждане на сайтовете. Един от тях бяха закъсненията в мрежата (RTT — round trip time или время ping). Закъсненията влияят на много процеси при зареждането на сайта: установяване на TCP връзка, стартиране на TLS сесия, зареждане на всеки отделен ресурс (снимки, JS файл, HTML документ и т.н.)

Проблемът се усложняваше от факта, че при използването на протокола HTTP/1.1 (до появата на SPDY, QUIC и HTTP/2 това беше единственият вариант) браузърите отварят не повече от 6 TCP връзки към един хост. Всичко това води до простоене на връзките и неефективно използване на пропускателната способност на канала. Проблемът частично се решаваше с доменен шардинг – създаване на допълнителни хостове, за да се преодолее лимитът на броя на връзките.

Тук се появява второто предимство на CDN – намаляване на закъсненията (RTT) чрез голям брой точки и близост на възлите до потребителя. Разстоянието играе решаваща роля: скоростта на светлината е ограничена (около 200 000 км/сек в оптичния кабел). Следователно, всеки 1000 км път добавя 5 мс закъснение или 10 мс в RTT. Това са минималните разходи на време за предаване, тъй като има и закъснения на междинното оборудване. Тъй като CDN обикновено може да кешира обекти на своите сървъри, можем да спечелим от зареждането на такива обекти през CDN. Необходими условия за това са: наличието на обект в кеша и близост на точката на CDN до потребителя в сравнение с уеб приложение сървър (origin server). Важно е да се разбере: географската близост на възела на CDN не гарантира ниски закъснения. Маршрутизацията между клиента и CDN може да бъде изградена по такъв начин, че клиентът да се свърже с хост в друга страна, а може би и на друг континент. Тук влизат в действие отношенията между операторите на свързаност и услугата CDN (пиринг, наличието на свързвания, участие в IX и т.н.) и политиката на маршрутизиране на трафика на самия CDN. Например, Cloudflare при използване на двата начални плана (безплатен и евтин) не гарантира доставка на съдържанието от най-близкия възел – избора на хост ще се извършва за постигане на минимална цена.

Много от водещите интернет компании привлекат общественото внимание (уеб разработчици и собственици на услуги) към темата за скоростта на зареждане и работа на сайтовете. Между тези компании са Yahoo (инструментът Yslow), AOL (WebPageTest) и Google (услугата Page Speed Insights), които разработват свои препоръки за ускоряване на сайтовете (преди всичко те засягат клиентската оптимизация). По-късно се появяват нови средства за тестване на скоростта на сайтове, които също дават съвети за увеличаване на скоростта на сайтовете. Във всеки от тези услуги или плъгини присъства неизменната препоръка „Използвайте CDN“. В качеството на обяснение на ефекта на CDN обикновено се посочва съкращаване на мрежовите закъснения. За съжаление, не всички са готови да разберат как точно се постига ефектът на ускорение от CDN и как може да бъде измерен, затова препоръката се приема за истина и се използва като постулат. Всъщност, далеч не всички CDN са еднакво полезни.

Използването на CDN днес

За оценка на полезността от приложението на CDN, те трябва да се класифицират. Какво може да срещнете в практиката сега (примерите в скобки, разбира се, не са изчерпателни):

1. Безплатни CDN за раздаване на JS библиотеки (MaxCDN, Google, Yandex).
2. CDN услуги за клиентска оптимизация (например Google Fonts за шрифтове, Cloudinary, Cloudimage за картинки).
3. CDN за статични ресурси и оптимизация в CMS (налични в Битрикс, WordPress и други).
4. CDN с общо предназначение (StackPath, CDNVideo, NGENIX, Мегафон).
5. CDN за ускоряване на сайтове (Cloudflare, Imperva, Айри).

Ключовото различие между тези типове е следното: коя част от трафика преминава през CDN. Типове 1-3 доставят само част от съдържанието: от една заявка до няколко десетки (обикновено картинки). Типове 4 и 5 представляват пълно проксиране на трафика през CDN.

На практика това означава количеството връзки, които се използват за зареждане на сайта. При използване на HTTP/2 ние използваме едно TCP свръзка с хоста за обработка на всяко количество заявки. Ако разделим ресурсите на основния хост (origin) и CDN, е необходимо да разделим заявките на няколко домейна и да създадем няколко TCP свръзки. В най-лошия случай: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. В тази формула не се взимат предвид закъсненията в мобилните мрежи при активиране на радио канала на устройството (ако той не е бил активен) и закъсненията на клетъчната кула.

Ето как изглежда на водопада при зареждане на сайта (забавяния за свързване с CDN при RTT 150 ms):

Ако CDN покрива целия трафик на сайта (с изключение на външни услуги), можем да използваме едно единствено TCP-соединение, спестявайки забавяния при свързване с допълнителни хостове. Разбира се, това важи и за HTTP/2-соединения.

По-нататъшните различия се определят от функционалността на конкретния CDN – за първия тип това е просто хостинг статичен файл, за петия – изменение на няколко типа съдържание на сайта с цел оптимизация.

Възможности на CDN за ускоряване на сайта

Нека опишем целия спектър от възможности на CDN за ускоряване на сайтове, без да се фокусираме върху функционалността на отделните типове CDN, а след това ще видим какво от това е реализирано в тях.

1. Сжатие на текстовите ресурси

Най-основната и разбираема функция, въпреки че често е реализирана лошо. Присъствието на компресия декларират всички CDN като своя функция за ускорение. Но ако погледнете по-подробно, излизат недочети:

• може да се използват ниски степени за динамично сжатие – 5-6 (например, за gzip максимум – 9);
• в статичната компресия (файлове в кеша) не се използват допълнителни възможности (например, zopfi или brotli със степен 11)
• няма поддръжка за ефективно сжатие brotli (икономия от около 20% в сравнение с gzip).

Ако използвате CDN, си струва да проверите тези няколко пункта: вземете файл, който е дошъл от CDN, запишете размера му в компресиран вид и компресирайте ръчно за сравнение (можете да използвате някакъв онлайн-сервис с поддръжка на brotli, например всичко сжатие.рф).

2. Настройка на заглавките за клиентско кеширане

Също така проста функция за ускорение: настройване на заглавки за кеширане на съдържанието от клиента (браузъра). Най-актуалното заглавие е cache-control, а остарялото – expires. Допълнително може да се използва Etag. Най-важното е, че max-age на cache-control трябва да бъде достатъчно голямо (от месец и повече), ако искате да кеширате ресурса максимално строго, можете да добавите опцията immutable.

CDN могат да намалят стойността на max-age, принуждавайки потребителя да зарежда статичните файлове по-често. Причината за това не е ясна: дали е желание за увеличаване на трафика в мрежата или необходимост от повишаване на съвместимостта с сайтове, които не могат да изчистват кеша. Например, времето за кеширане в заглавията на Cloudflare по подразбиране е 1 час, което е много малко за неизменна статична информация.

3. Оптимизация на изображенията

Тъй като CDN поема функциите на кеширане и доставка на изображения, логично е да ги оптимизираме от страна на CDN и да ги предоставяме на потребителите в тази форма. Нека подчертаем, че тази възможност е налична само за типове CDN 2, 3 и 5.

Оптимизацията на изображенията може да бъде постигната по различни начини: чрез използване на напреднали формати за компресия (например, WebP), по-ефективни кодера (MozJPEG) или просто чрез изтриване на излишни метаданни.

Като цяло има два типа оптимизации: с загуба на качество и без загуба на качество. CDN обикновено се стремят да използват оптимизация без загуби – за да избегнат възможни оплаквания от клиенти относно промяната на качеството на изображенията. В тези условия, печалбата от оптимизацията ще бъде минимална. В действителност, често нивото на качество на JPEG значително надвишава необходимото, така че може смело да се проведе рекомпресия с по-нисък показател на качество, без да се вреди на восприятието от страна на потребителите. От друга страна, определянето на нивото на качество и настройките универсално за всички възможни уеб приложения е трудно, което е причина CDN да използват по-консервативни настройки в сравнение с тези, които биха могли да се приложат, вземайки предвид контекста (предназначение на изображенията, тип уеб приложение и т.н.)

4. Оптимизация на TLS връзката

Повечето трафик днес се предава чрез TLS връзки, а това означава, че губим допълнително време за TLS споразумение. През последното време бяха разработени нови технологии за ускоряване на този процес. Например, EC криптография, TLS 1.3, кеш на сесии и тикети (session tickets), хардуерно ускорение на шифроването (AES-NI) и т.н. Правилната настройка на TLS позволява да се намали времето за свързване до 0-1 RTT (без да се броят DNS и TCP).

При наличието на съвременен софтуер, внедряването на такива практики не е трудно на собствените мощност.

Далеч не всички CDN прилагат най-добрите практики за TLS, което може да се провери чрез измерване на времето за TLS свързване (например в Webpagetest). Идеалното за ново свързване е 1RTT, 2RTT - средно ниво, 3RTT и повече – лошо.

Също така трябва да се отбележи, че дори при използване на TLS на ниво CDN, сървърът с нашето уеб приложение също трябва да обработва TLS, но от страна на CDN, тъй като трафикът между сървъра и CDN преминава в публична мрежа. В най-лошия случай получаваме двойно забавяне на TLS свързването (първото към хоста на CDN, второто между него и нашия сървър).

За някои приложения си струва да се обърне внимание на въпросите за сигурността: обикновено трафикът се разшифрова на възлите на CDN, което е потенциална възможност за прихващане на трафика. Вариант за работа без разкриване на трафика обикновено се предлага в топовите тарифни планове за отделна такса.

5. Съкращаване на закъсненията при свързване

Основното предимство на CDN, за което всички говорят: ниски закъснения (по-малко разстояние) между хоста на CDN и потребителя. Това се постига чрез създаване на географски разпределена мрежова архитектура, в която хостовете са разположени в точки на концентрация на потребители (градове, точки на обмен на трафик и т.н.)

На практика приоритетите за различни мрежи може да са в конкретни региони. Например, руски CDN ще имат повече точки на присъствие в Русия. Американските основно ще развиват мрежата в САЩ. Например, един от най-големите CDN, Cloudflare, има само 2 точки в Русия - Москва и Санкт Петербург. Тоест, максимално можем да спестим около 10 мс закъснение в сравнение с директно разполагане в Москва.

Повечето западни CDN изобщо нямат точки в Русия. Свързвайки се с тях, можете само да увеличите закъсненията за вашата руска аудитория.

6. Оптимизация на съдържанието (минификация, структурни промени)

Най-сложната и технологична точка. Променянето на съдържанието при доставка може да бъде много рисково. Дори ако говорим за минификация: съкращаването на изходния код (чрез излишни интервали, неважни конструкции и т.н.) може да повлияе на работоспособността му. Ако говорим за по-сериозни промени - преместването на JS кода в края на HTML, обединяване на файлове и подобни - рискът да се наруши функционалността на сайта е още по-висок.

Следователно, само някои CDN от тип 5 се занимават с това. Разбира се, автоматизацията на всички необходими промени за ускорение не е възможна – необходима е ръчна оценка и оптимизация. Например, премахването на неизползван или дублиращ код попада в категорията на ръчните задачи.

Обикновено всички подобни оптимизации се управляват чрез настройки и най-опасните са изключени по подразбиране.

Поддръжка на ускорителни възможности по типове CDN

И така, нека разгледаме какви потенциални възможности за ускорение предлагат различните типове CDN.

За удобство, нека повторим класификацията.

1. Безплатни CDN за раздаване на JS библиотеки (MaxCDN, Google, Yandex).
2. CDN услуги за клиентска оптимизация (например Google Fonts за шрифтове, Cloudinary, Cloudimage за картинки).
3. CDN за статични ресурси и оптимизация в CMS (налични в Битрикс, WordPress и други).
4. CDN с общо предназначение (StackPath, CDNVideo, NGENIX, Мегафон).
5. CDN за ускоряване на сайтове (Cloudflare, Imperva, Айри).

Сега ще съпоставим функциите и типовете CDN.

Възможност
Тип 1
Тип 2
Тип 3
Тип 4
Тип 5

Стисване на текст
+–
–
+–
+–
+

Заглавия на кеша
+
+
+
+
+

Снимки
–
+–
+–
–
+

TLS
–
–
–
+–
+

Закъснения
–
–
–
+
+

Съдържание
–
–
–
–
+

В тази таблица „+“ се използва за индикация на пълна поддръжка, „–“ – отсъствие, „+–“ – частична поддръжка. Разбира се, реалността може да се отклонява от тази таблица (например, някой CDN от общо предназначение може да внедри функции за оптимизация на снимки), но за общо разбиране тя е полезна.

Итог

Надявам се, след като прочетете тази статия, да имате по-ясна представа относно препоръката „използвайте CDN“ за ускорение на сайтове.

Както при всяко нещо, не трябва да вярвате на маркетинговите обещания на някоя услуга. Ефектът трябва да се измерва и проверява при реални условия. Ако вече използвате някой CDN, проверете неговата ефективност според критериите, описани в статията.

Възможно е в момента използването на CDN да забавя зареждането на вашия сайт.

Като обща препоръка може да се спре на следното: изучете своята аудитория, определете нейния географски обхват. Ако вашата основна аудитория е концентрирана в радиус от 1-2 хиляди километра, не ви е необходим CDN по основното предназначение – намаляване на закъсненията. Вместо това можете да разположите своя сървър по-близо до потребителите и да го конфигурирате правилно, като получите повечето оптимизации, описани в статията (безплатно и постоянно).

Ако вашата аудитория е наистина географски разпределена (с радиус над 3000 километра), използването на качествена CDN наистина ще бъде полезно. Въпреки това, трябва да разберете от самото начало какво точно може да ускори вашата CDN (вижте таблицата с възможностите и тяхното описание). Ускорението на сайта остава комплексна задача, която не се решава единствено с подключването на CDN. Освен посочените оптимизации, извън CDN остават най-ефективните средства за ускорение: оптимизация на сървърната част, напреднали промени в клиентската част (премахване на неизползван код, оптимизация на процеса на рендериране, работа с съдържание, шрифтове, адаптивност и др.)

Източник: habr.com