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

Почти всяка статия или инструмент за оптимизиране на скоростта на сайта има скромна клауза „използване на CDN“. Като цяло CDN е мрежа за доставка на съдържание или мрежа за доставка на съдържание. Ние от Method Lab често срещаме въпроси от клиенти по тази тема; някои от тях активират своя собствена CDN. Целта на тази статия е да разбере какво може да осигури CDN по отношение на скоростта на зареждане на сайта, какви проблеми могат да възникнат и в кои случаи използването на CDN е оправдано.

Закъсненията, оградени на снимката, са причинени от използването на CDN.

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

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

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

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

С развитието на мрежата самите уеб приложения стават все по-сложни и комплексни. Проблемът със скоростта на зареждане излезе на преден план. Любителите на скоростта на уебсайтове бързо идентифицираха няколко основни проблема, които караха уебсайтовете да се зареждат бавно. Едно от тях бяха закъсненията в мрежата (RTT - време за двупосочно пътуване или време за пинг). Закъсненията засягат много процеси при зареждането на уебсайта: установяване на TCP връзка, стартиране на TLS сесия, зареждане на всеки отделен ресурс (изображение, JS файл, HTML документ и т.н.)

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

Тук се появява втората възможност на CDN - намаляване на латентността (RTT) поради големия брой точки и близостта на възлите до потребителя. Разстоянието играе решаваща роля тук: скоростта на светлината е ограничена (около 200 000 км/сек при оптични влакна). Това означава, че всеки 1000 км пътуване добавя 5 ms забавяне или 10 ms към RTT. Това е минималното време, необходимо за предаване, тъй като има забавяния и на междинното оборудване. Тъй като CDN обикновено знае как да кешира обекти на своите сървъри, можем да се възползваме от зареждането на такива обекти чрез CDN. Необходими условия за това: наличието на обекта в кеша, близостта на CDN точката до потребителя в сравнение със сървъра за уеб приложения (оригинален сървър). Важно е да се разбере, че географската близост на 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 (предлага се в Bitrix, WordPress и други).
4. CDN с общо предназначение (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN за ускоряване на уебсайтове (Cloudflare, Imperva, Airi).

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

На практика това означава броя на връзките, които се използват за зареждане на сайта. С HTTP/2 използваме една TCP връзка към хоста, за да обработим произволен брой заявки. Ако разделим ресурсите на главния хост (произход) и 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, например vsszhat.rf).

2. Задаване на заглавки за кеширане на клиента

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

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

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

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

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

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

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

По-голямата част от трафика днес преминава през TLS връзки, което означава, че отделяме допълнително време за договаряне на TLS. Наскоро бяха разработени нови технологии за ускоряване на този процес. Например, това е EC криптография, TLS 1.3, сесиен кеш и билети, хардуерно ускоряване на криптиране (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 ms латентност в сравнение с директното поставяне в Москва.

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

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

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

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

По правило всички подобни оптимизации се контролират от настройките, а най-опасните са деактивирани по подразбиране.

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

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

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

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

Сега нека сравним характеристиките и видовете CDN.

Възможност
Въведете 1
Въведете 2
Въведете 3
Въведете 4
Въведете 5

Компресиране на текст
+–
-
+–
+–
+

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

снимки
-
+–
+–
-
+

TLS
-
-
-
+–
+

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

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

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

Резултати от

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

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

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

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

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

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