[Не] выкарыстоўвайце 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. СDN для паскарэння сайтаў (Cloudflare, Imperva, Айры).

Ключавое адрозненне гэтых тыпаў складаецца з наступнага: якая частка трафіку праходзіць праз CDN. Тыпы 1-3 гэта дастаўка толькі часткі кантэнту: ад аднаго запыту да некалькіх дзясяткаў (звычайна карцінак). Тыпы 4 і 5 гэта поўнае праксіраванне трафіку праз CDN.

На практыцы гэта азначае колькасць падлучэнняў, якія выкарыстоўваюцца для загрузкі сайта. Пры выкарыстанні HTTP/2 мы выкарыстоўваем адно TCP-падлучэнне да хаста для апрацоўкі любой колькасці запытаў. Калі мы падзяляем рэсурсы на асноўны хост (origin) і CDN, тое неабходна разводзіць запыты па некалькіх даменах і ствараць некалькі ТСP-злучэнняў. У горшым выпадку гэта: 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. СDN для паскарэння сайтаў (Cloudflare, Imperva, Айры).

Цяпер супастаўны фічы і тыпы CDN.

Магчымасць
тып 1
тып 2
тып 3
тып 4
тып 5

Сціск тэксту
+–
-
+–
+–
+

Загалоўкі кэша
+
+
+
+
+

Малюнкі
-
+–
+–
-
+

TLS
-
-
-
+–
+

затрымкі
-
-
-
+
+

Кантэнт
-
-
-
-
+

У гэтай табліцы "+" выкарыстоўваецца для індыкацыі поўнай падтрымкі, "-" - адсутнасць, "+-" - частковая падтрымка. Вядома, магчымыя адхіленні ад гэтай табліцы ў рэальнасці (напрыклад, які-небудзь CDN агульнага прызначэння ўкарэніць фічы па аптымізацыі малюнкаў), але для агульнага ўяўлення яна карысная.

Вынікі

Спадзяюся, прачытаўшы гэты артыкул у вас з'явіцца больш ясная карціна адносна рэкамендацыі "выкарыстоўвайце CDN" для паскарэння сайтаў.

Як і ў любой справе, нельга верыць маркетынгавым абяцанням які-небудзь сэрвісу. Эфект трэба вымяраць і правяраць у рэальных умовах. Калі вы ўжо выкарыстоўваеце нейкі CDN, праверце яго на прадмет эфектыўнасці па крытэрыях, апісаных у артыкуле.

Магчыма, выкарыстанне CDN прама зараз запавольвае загрузку вашага сайта.

У якасці агульнай рэкамендацыі можна спыніцца на наступным: вывучыце сваю аўдыторыю, вызначыце яе геаграфічныя рамкі. Калі ваша асноўная аўдыторыя сканцэнтравана ў радыусе 1-2 тысяч кіламетраў, вам не патрабуецца CDN па асноўным прызначэнні - зніжэнню затрымак. Замест гэтага, вы можаце размясціць свой сервер бліжэй да карыстальнікаў і наладзіць яго належным чынам, атрымліваючы большасць аптымізацый, апісаных у артыкуле (бясплатна і ўвесь час).

У выпадку, калі ваша аўдыторыя сапраўды геаграфічна размеркавана (радыус больш за 3000 кіламетраў), выкарыстанне якаснай CDN сапраўды будзе карысна. Аднак трэба загадзя разумець, што менавіта зможа паскорыць ваша CDN (гл. табліцу магчымасцяў і іх апісанне). Паскарэнне сайта пры гэтым усё роўна застаецца комплекснай задачай, якая не вырашаецца падключэннем CDN. Апроч паказаных аптымізацый за бортам CDN застаюцца самыя эфектыўныя сродкі паскарэння: аптымізацыя сервернай часткі, прасунутыя змены кліенцкай часткі (выдаленне невыкарыстоўванага кода, аптымізацыя працэсу рэндэрынгу, праца з кантэнтам, шрыфтамі, адаптыўнасцю і г.д.)

Крыніца: habr.com