[Не] користете CDN

Речиси секоја статија или алатка за оптимизирање на брзината на страницата има скромна клаузула „користете CDN“. Општо земено, CDN е мрежа за испорака на содржина или мрежа за испорака на содржина. Ние во Method Lab често наидуваме на прашања од клиенти на оваа тема; некои од нив овозможуваат сопствен 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 km патување додава 1000 ms доцнење или 5 ms на RTT. Ова е минималното време потребно за пренос, бидејќи има и доцнења на средната опрема. Бидејќи CDN обично знае како да ги кешира објектите на своите сервери, можеме да имаме корист од вчитување на такви објекти преку CDN. Потребни услови за ова: присуство на објектот во кешот, близината на ЦДН-точката до корисникот во споредба со серверот за веб-апликации (сервер за потекло). Важно е да се разбере дека географската близина на CDN јазол не гарантира мала латентност. Рутирањето помеѓу клиентот и CDN може да биде изградено на таков начин што клиентот ќе се поврзе со домаќин во друга земја, а можеби и на друг континент. Тука стапуваат во игра врската помеѓу телекомуникациските оператори и услугата CDN (перинг, врски, учество во IX, итн.) и политиката за рутирање на сообраќајот на самиот CDN. На пример, Cloudflare, кога користите два првични планови (бесплатен и евтин), не гарантира испорака на содржина од најблискиот домаќин - домаќинот ќе биде избран за да се постигне минималната цена.

Многу водечки интернет компании привлекуваат јавен интерес (веб-програмери и сопственици на услуги) за темата на брзината на вчитување и перформансите на веб-страниците. Меѓу овие компании се Yahoo (алатката Yslow), AOL (WebPageTest) и Google (услуга за брзина на страницата Insights), кои развиваат свои препораки за забрзување на сајтовите (првенствено тие се однесуваат на оптимизација на клиентите). Подоцна се појавуваат нови алатки за тестирање на брзината на веб-страницата, кои исто така даваат совети за зголемување на брзината на веб-страницата. Секоја од овие услуги или приклучоци има конзистентна препорака: „Користете CDN“. Намалувањето на латентноста на мрежата обично се наведува како објаснување за ефектот на CDN. За жал, не секој е подготвен да разбере како точно се постигнува ефектот на забрзување на ЦДН и како може да се измери, па препораката се зема на вера и се користи како постулат. Всушност, не сите CDN се создадени еднакви.

Користење на CDN денес

За да се процени корисноста од користењето на ЦДН, тие треба да се класифицираат. Што може да се најде сега во пракса (примерите во загради, се разбира, не се исцрпни):

1. Бесплатен CDN за дистрибуција на JS библиотеки (MaxCDN, Google. Yandex).
2. ЦДН на услуги за оптимизација на клиентот (на пример, 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. Поставување заглавија за кеширање на клиентот

Исто така едноставна функција за забрзување: додадете заглавија за кеширање на содржината од клиентот (прелистувач). Најактуелното заглавие е контрола на кешот, а застареното истекува. Дополнително, може да се користи Etag. Главната работа е што максималната возраст на контрола на кешот е доволно голема (од еден месец или повеќе).

ЦДН може да ја намалат вредноста на максималната возраст, принудувајќи го корисникот да ја превчитува статичката содржина почесто. Не е јасно со што е поврзано ова: желбата да се зголеми сообраќајот на мрежата или да се зголеми компатибилноста со сајтови кои не знаат како да го ресетираат кешот. На пример, стандардното време на кешот на заглавието на Cloudflare е 1 час, што е многу ниско за непроменливи статички податоци.

3. Оптимизација на сликата

Бидејќи CDN ги презема функциите на кеширање и сервирање слики, би било логично да се оптимизираат на страната на CDN и да се сервираат на корисниците во оваа форма. Ајде да направиме резервација веднаш дека оваа функција е достапна само за типови CDN 2, 3 и 5.

Можете да ги оптимизирате сликите на различни начини: користејќи напредни формати за компресија (како WebP), поефикасни енкодери (MozJPEG) или едноставно чистење на непотребните метаподатоци.

Општо земено, постојат два вида на такви оптимизации: со губење на квалитетот и без губење на квалитетот. ЦДН обично се стремат да користат оптимизација без загуби со цел да избегнат можни поплаки на клиентите за промени во квалитетот на сликата. Во такви услови добивката ќе биде минимална. Во реалноста, честопати нивото на квалитет на 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 Cloudflare има само 2 точки во Русија - Москва и Санкт Петербург. Односно, можеме да заштедиме максимум околу 10 ms латентност во споредба со директното поставување во Москва.

Повеќето западни ЦДН воопшто немаат точки во Русија. Со поврзување со нив, можете само да ги зголемите одложувањата за вашата руска публика.

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

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

Затоа, само некои CDN од тип 5 го прават ова. Се разбира, нема да биде можно да се автоматизираат сите промени потребни за да се забрзаат работите - потребна е рачна анализа и оптимизација. На пример, отстранувањето на неискористениот или дупликат код е рачна задача.

Како по правило, сите такви оптимизации се контролираат од поставките, а најопасните се стандардно оневозможени.

Поддршка за способности за забрзување според типот CDN

Значи, ајде да погледнеме какви потенцијални можности за забрзување обезбедуваат различните типови на CDN.

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

1. Бесплатен CDN за дистрибуција на JS библиотеки (MaxCDN, Google. Yandex).
2. ЦДН на услуги за оптимизација на клиентот (на пример, 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