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

Практически във всяка статия или инструмент за оптимизация на скоростта на уебсайтове има скромен пункт «използвайте CDN». Всъщност, CDN означава content delivery network или мрежа за доставка на съдържание. Ние в компанията «Метод Лаб» често се срещаме с въпросите на клиентите по тази тема, много от които сами активират 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 мс са подчертани):

Ако 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

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

Cache заглавия
+
+
+
+
+

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

TLS
–
–
–
+–
+

Забавяния
–
–
–
+
+

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

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

Резюме

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

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

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

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

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

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