Сайттын ылдамдыгын оптималдаштыруу үчүн дээрлик ар бир макалада же куралда "CDN колдонуңуз" деген жөнөкөй пункт бар. Жалпысынан алганда, CDN мазмун жеткирүү тармагы же мазмун жеткирүү тармагы болуп саналат. Метод лабораториясында биз көбүнчө кардарлардын бул тема боюнча суроолоруна туш болобуз, алардын айрымдары өз CDNдерин иштетет; Бул макаланын максаты - CDN сайтты жүктөө ылдамдыгы жагынан эмне бере аларын, кандай көйгөйлөр пайда болушу мүмкүн экенин жана кайсы учурларда CDNди колдонуу негиздүү экенин түшүнүү.
Сүрөттө тегеректелген кечигүү CDNди колдонуу менен шартталган.
Бир аз тарыхы
Көптөгөн технологиялар сыяктуу эле, CDNs зарылчылыктан улам пайда болгон. Интернет колдонуучулардын арасында интернет-каналдардын өнүгүшү менен онлайн видео сервистер пайда болду. Албетте, видео мазмуну кадимки веб-сайттын мазмунуна (сүрөттөр, текст жана CSS же JS коду) салыштырмалуу көбүрөөк өткөрүү жөндөмдүүлүгүн талап кылат.
Бир серверден көптөгөн кардарларга параллелдүү видео агымын берүүгө аракет кылып жатканда, сервердин Интернет каналы кыйынчылыкка айланат. Эреже катары, типтүү сервер каналын жабуу үчүн бир нече миң жип жетиштүү. Албетте, башка ресурстук чектөөлөр болушу мүмкүн, бирок алар азыр маанилүү эмес. Сервер каналын кеңейтүү өтө кымбат (жана кээде мүмкүн эмес), ошондой эле практикалык эмес экендиги да маанилүү. Берүү учурунда каналга жүктөө циклдүү болот.
Жеке сервердин каналын чектөө маселеси CDN тарабынан эң сонун чечилет. Кардарлар серверге түз эмес, CDN тармагындагы түйүндөргө туташат. Идеалдуу кырдаалда сервер CDN түйүнүнө бир агым жөнөтөт, андан кийин тармак бул агымды көптөгөн колдонуучуларга жеткирүү үчүн өзүнүн ресурстарын колдонот. Экономикалык көз караштан алганда, биз иш жүзүндө керектелген ресурстар үчүн гана төлөйбүз (бул өткөрүү жөндөмдүүлүгү же трафик болушу мүмкүн) жана кызматыбыздын эң сонун масштабдуулугуна ээ болобуз. Оор мазмунду жеткирүү үчүн CDNди колдонуу толугу менен негиздүү жана логикалуу. Белгилей кетчү нерсе, бул мейкиндиктеги эң чоң оюнчулар (мисалы, Netflix) ири коммерциялык CDNдерди (Akamai, Cloudflare, Fastly ж.
Веб өнүккөн сайын, веб-тиркемелердин өзү дагы татаал жана татаал болуп калды. Жүктөө ылдамдыгы маселеси биринчи планга чыкты. Вебсайттын ылдамдыгы ышкыбоздору веб-сайттардын жай жүктөлүшүнө алып келген бир нече негизги көйгөйлөрдү тез аныкташты. Алардын бири тармактын кечигүүлөрү болгон (RTT - айланып келүү убактысы же пинг убактысы). Кечигүүлөр веб-сайтты жүктөөдөгү көптөгөн процесстерге таасирин тийгизет: TCP байланышын орнотуу, TLS сеансын баштоо, ар бир жеке ресурсту жүктөө (сүрөт, JS файлы, HTML документи ж.б.)
Көйгөй HTTP/1.1 протоколун колдонууда (SPDY, QUIC жана HTTP/2 пайда болгонго чейин бул жалгыз вариант болгон) браузерлер бир хостко 6дан ашык эмес TCP байланыштарын ача тургандыгы менен курчуду. Мунун баары байланыштын токтоп калышына жана каналдын өткөрүү жөндөмдүүлүгүн натыйжасыз пайдаланууга алып келди. Көйгөй жарым-жартылай доменди бөлүштүрүү жолу менен чечилди - туташуулар саны боюнча чектөөнү жеңүү үчүн кошумча хостторду түзүү.
Бул жерде CDNдин экинчи жөндөмү пайда болот - көп сандагы чекиттердин жана түйүндөрдүн колдонуучуга жакындыгынан улам күтүү убактысын (RTT) азайтуу. Бул жерде аралык чечүүчү ролду ойнойт: жарыктын ылдамдыгы чектелген (оптикалык була менен 200 000 км/сек). Бул ар бир 1000 км саякат RTTге 5 мс кечигүү же 10 мс кошот дегенди билдирет. Бул берүү үчүн талап кылынган минималдуу убакыт, анткени аралык жабдууларда да кечигүүлөр бар. CDN адатта өзүнүн серверлериндеги объекттерди кантип кэш кылууну билгендиктен, биз CDN аркылуу мындай объекттерди жүктөөдөн пайда алабыз. Бул үчүн зарыл шарттар: кэште объекттин болушу, веб-тиркеме серверине (оригин сервер) салыштырмалуу CDN пунктунун колдонуучуга жакындыгы. CDN түйүнүнүн географиялык жакындыгы аз күтүүгө кепилдик бербестигин түшүнүү маанилүү. Кардар менен CDNдин ортосундагы маршрутташтыруу кардар башка өлкөдөгү, балким, башка континенттеги хост менен туташа тургандай түзүлүшү мүмкүн. Бул жерде байланыш операторлору менен CDN кызматынын ортосундагы мамиле (принг, байланыштар, IXке катышуу ж.б.) жана CDNдин трафикти маршруттоо саясаты ишке кирет. Мисалы, Cloudflare, эки баштапкы планды (акысыз жана арзан) колдонуп жатканда, жакынкы хосттон мазмунду жеткирүүгө кепилдик бербейт - хост минималдуу чыгымга жетүү үчүн тандалат.
Көптөгөн алдыңкы интернет-компаниялар жүктөө ылдамдыгы жана веб-сайттын иштеши темасына коомчулуктун кызыгуусун (веб-иштеп чыгуучулар жана кызмат ээлери) тартат. Бул компаниялардын арасында Yahoo (Yslow куралы), AOL (WebPageTest) жана Google (Page Speed Insights кызматы) бар, алар сайттарды тездетүү боюнча өз сунуштарын иштеп жатышат (биринчи кезекте алар кардарларды оптималдаштырууга тиешелүү). Кийинчерээк веб-сайттын ылдамдыгын текшерүүнүн жаңы куралдары пайда болот, алар веб-сайттын ылдамдыгын жогорулатуу боюнча кеңештерди берет. Бул кызматтардын же плагиндердин ар биринде ырааттуу сунуш бар: "CDN колдонуңуз." Тармактын кечигүү убактысынын кыскарышы, адатта, CDNдин таасирин түшүндүрүү катары келтирилет. Тилекке каршы, CDNдин акселерация эффектисине кантип жетишилгенин жана аны кантип өлчөөгө болорун так түшүнүүгө баары эле даяр эмес, ошондуктан сунуш ишеним боюнча кабыл алынып, постулат катары колдонулат. Чынында, бардык CDNs бирдей түзүлгөн эмес.
Бүгүн CDN колдонуу
CDNдерди колдонуунун пайдалуулугун баалоо үчүн аларды классификациялоо керек. Азыр иш жүзүндө эмнени тапса болот (кашадагы мисалдар, албетте, толук эмес):
- JS китепканаларын жайылтуу үчүн акысыз CDN (MaxCDN, Google. Yandex).
- Кардарларды оптималдаштыруу үчүн кызматтардын CDN'и (мисалы, шрифттер үчүн Google Fonts, Cloudinary, сүрөттөр үчүн Cloudimage).
- CMSде статикалык жана ресурстук оптималдаштыруу үчүн CDN (Bitrix, WordPress жана башкаларда бар).
- Жалпы максаттагы CDN (StackPath, CDNVideo, NGENIX, Megafon).
- Вебсайтты тездетүү үчүн 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 мс менен белгиленген):
CDN сайттын бардык трафигин камтыса (үчүнчү тараптын кызматтарынан башка), анда биз кошумча хостторго туташуудагы күтүү убактысын үнөмдөө менен бир TCP байланышын колдоно алабыз. Албетте, бул HTTP/2 байланыштарына тиешелүү.
Андан аркы айырмачылыктар белгилүү бир CDNдин функционалдуулугу менен аныкталат - биринчи типте ал жөн гана статикалык файлды жайгаштыруу, бешинчи үчүн оптималдаштыруу максатында сайттын мазмунунун бир нече түрүн өзгөртүү.
Вебсайтты тездетүү үчүн CDN мүмкүнчүлүктөрү
Келгиле, CDNдин айрым түрлөрүнүн функционалдуулугун эске албастан сайттарды тездетүү үчүн CDN мүмкүнчүлүктөрүнүн толук спектрин сүрөттөп көрөлү, анан алардын ар биринде эмне ишке ашырылганын карап көрөлү.
1. Тексттик ресурстарды кысуу
Эң негизги жана түшүнүктүү өзгөчөлүк, бирок көп учурда начар ишке ашырылган. Бардык CDN'лер кысуунун бар экендигин тездетүү өзгөчөлүгү катары жарыялашат. Ал эми майда-чүйдөсүнө чейин карасак, кемчиликтер айкын болот:
- динамикалык кысуу үчүн төмөнкү даражаларды колдонсо болот - 5-6 (мисалы, gzip үчүн максимум 9);
- статикалык кысуу (кэштеги файлдар) кошумча функцияларды колдонбойт (мисалы, zopfi же 11 даражадагы бротли)
- натыйжалуу brotli кысуу үчүн эч кандай колдоо жок (gzip салыштырмалуу 20% га жакын үнөмдөө).
Эгер сиз CDNди колдонсоңуз, анда бул бир нече пункттарды текшерип көрүү керек: CDNден келген файлды алып, анын кысылган өлчөмүн жазыңыз жана салыштыруу үчүн кол менен кысыңыз (мисалы, сиз brotli колдоосу менен кээ бир онлайн кызматын колдоно аласыз. ).
2. Кардардын кэш баштарын орнотуу
Ошондой эле жөнөкөй тездетүүнүн өзгөчөлүгү: кардар (браузер) тарабынан мазмунду кэштөө үчүн аталыштарды кошуу. Эң учурдагы аталышы кэш-контроль, эскиргенинин мөөнөтү бүттү. Мындан тышкары, Etag колдонсо болот. Эң негизгиси, кэш-контролдун максималдуу жашы жетиштүү (бир айдан же андан көп болсо, сиз ресурсту мүмкүн болушунча катуу кэштоого даяр болсоңуз, өзгөрүлбөс опцияны кошсоңуз болот).
CDNs максималдуу курактык маанини төмөндөтүп, колдонуучуну статикалык мазмунду тез-тез кайра жүктөөгө мажбурлайт. Бул эмне менен байланыштуу экени түшүнүксүз: тармактагы трафикти көбөйтүү же кэшти кантип калыбына келтирүүнү билбеген сайттар менен шайкештикти жогорулатуу каалоосу. Мисалы, демейки 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 жана башкалар - начар.
Белгилей кетчү нерсе, CDN деңгээлинде TLS колдонгондо да, биздин веб тиркеме менен сервер TLSди иштетиши керек, бирок CDN тараптан, анткени сервер менен CDN ортосундагы трафик коомдук тармакта өтөт. Эң начар учурда, биз эки эселенген TLS туташуу кечигүүлөрүн алабыз (биринчиси CDN хостуна, экинчиси ал менен биздин сервердин ортосунда).
Кээ бир тиркемелер үчүн коопсуздук маселелерине көңүл буруш керек: трафик адатта CDN түйүндөрүндө чечилет жана бул трафикти кармоо үчүн потенциалдуу мүмкүнчүлүк. Трафиксиз иштөө опциясы, адатта, жогорку тарифтик пландарда кошумча төлөмгө сунушталат.
5. Туташуу кечигүүлөрүн азайтыңыз
CDNдин негизги артыкчылыгы бардыгы жөнүндө: CDN хосту менен колдонуучунун ортосундагы аз күтүү (азыраак аралык). Хосттар колдонуучулардын топтолгон жерлеринде (шаарларда, трафик алмашуу пункттарында ж.
Иш жүзүндө ар кандай тармактар үчүн артыкчылыктар конкреттүү аймактарда болушу мүмкүн. Мисалы, россиялык CDNs Россияда көбүрөөк катышуу пункттарына ээ болот. Америкалыктар биринчи кезекте АКШда тармакты өнүктүрүшөт. Мисалы, ири CDN Cloudflare бири Россияда 2 гана пунктка ээ - Москва жана Санкт-Петербург. Башкача айтканда, биз Москвада түз жайгаштырууга салыштырмалуу 10 мс кечиктирүүнү эң көп сактай алабыз.
Көпчүлүк Батыш CDNs Орусияда такыр эле пункттары жок. Аларга туташуу менен, сиз орус аудиторияңыз үчүн кечигүүлөрдү гана көбөйтө аласыз.
6. Мазмунду оптималдаштыруу (минификациялоо, структуралык өзгөртүүлөр)
Эң татаал жана технологиялык жактан өнүккөн пункт. Жеткирүү учурунда мазмунду өзгөртүү өтө кооптуу болушу мүмкүн. Минификацияны алсак да: баштапкы кодду кыскартуу (кошумча мейкиндиктерден, маанилүү эмес структуралардан ж.б. улам) анын иштешине таасир этиши мүмкүн. Эгерде биз олуттуураак өзгөртүүлөр жөнүндө айтсак - JS кодун HTMLдин аягына жылдыруу, файлдарды бириктирүү ж.
Ошондуктан, кээ бир түрү 5 CDNs гана муну. Албетте, ишти тездетүү үчүн зарыл болгон бардык өзгөртүүлөрдү автоматташтыруу мүмкүн эмес — кол менен талдоо жана оптималдаштыруу талап кылынат. Мисалы, пайдаланылбаган же кайталанган кодду алып салуу кол менен аткарылуучу иш.
Эреже катары, бардык мындай оптималдаштыруу жөндөөлөр тарабынан башкарылат жана эң коркунучтуулары демейки боюнча өчүрүлөт.
CDN түрү боюнча тездетүү мүмкүнчүлүктөрүн колдоо
Андыктан, келгиле, CDNдин ар кандай түрлөрү кандай потенциалдуу тездетүү мүмкүнчүлүктөрүн берерин карап көрөлү.
Ыңгайлуу болуу үчүн классификацияны кайталайбыз.
- JS китепканаларын жайылтуу үчүн акысыз CDN (MaxCDN, Google. Yandex).
- Кардарларды оптималдаштыруу үчүн кызматтардын CDN'и (мисалы, шрифттер үчүн Google Fonts, Cloudinary, сүрөттөр үчүн Cloudimage).
- CMSде статикалык жана ресурстук оптималдаштыруу үчүн CDN (Bitrix, WordPress жана башкаларда бар).
- Жалпы максаттагы CDN (StackPath, CDNVideo, NGENIX, Megafon).
- Вебсайтты тездетүү үчүн CDN (Cloudflare, Imperva, Airi).
Эми CDN өзгөчөлүктөрүн жана түрлөрүн салыштырып көрөлү.
мүмкүнчүлүк
Type 1
Type 2
Type 3
Type 4
Type 5
Текстти кысуу
+–
-
+–
+–
+
Кэштин аталыштары
+
+
+
+
+
картинки
-
+–
+–
-
+
TLS
-
-
-
+–
+
Кечигүүлөр
-
-
-
+
+
мазмуну
-
-
-
-
+
Бул таблицада "+" толук колдоо көрсөтүү үчүн колдонулат, "-" колдоо жок, "+-" жарым-жартылай колдоо. Албетте, чындыгында бул таблицадан четтөөлөр болушу мүмкүн (мисалы, кээ бир жалпы багыттагы CDN сүрөттөрдү оптималдаштыруу үчүн функцияларды ишке ашырат), бирок жалпы идея үчүн бул пайдалуу.
натыйжалары
Бул макаланы окугандан кийин, сиз сайттарыңызды тездетүү үчүн "CDN колдонуу" сунушуна байланыштуу айкыныраак сүрөткө ээ болосуз деп үмүттөнөбүз.
Ар кандай бизнестегидей эле, сиз кандайдыр бир кызматтын маркетинг убадаларына ишене албайсыз. Эффекти реалдуу шарттарда өлчөө жана сынап көрүү керек. Эгер сиз CDNди мурунтан эле колдонуп жатсаңыз, макалада сүрөттөлгөн критерийлерди колдонуу менен анын натыйжалуулугун текшериңиз.
CDNди азыр колдонуу сайтыңыздын жүктөө убактысын жайлатышы мүмкүн.
Жалпы сунуш катары биз төмөнкүлөргө токтолсок болот: аудиторияңызды изилдеңиз, анын географиялык масштабын аныктаңыз. Эгерде сиздин негизги аудиторияңыз 1-2 миң километр радиуста топтолсо, анын негизги максаты - күтүү убактысын азайтуу үчүн CDNдин кереги жок. Анын ордуна, сиз өзүңүздүн сервериңизди колдонуучуларыңызга жакыныраак жайгаштырып, аны туура конфигурациялап, макалада сүрөттөлгөн оптималдаштыруулардын көбүн ала аласыз (акысыз жана туруктуу).
Эгер аудиторияңыз чындап географиялык жактан бөлүштүрүлгөн болсо (радиусу 3000 километрден ашык), сапаттуу CDNди колдонуу чындап эле пайдалуу болот. Бирок, сиз CDN эмнени тездете аларын алдын ала түшүнүшүңүз керек (мүмкүнчүлүктөрдүн таблицасын жана алардын сүрөттөмөсүн караңыз). Бирок, веб-сайтты тездетүү дагы эле CDNди туташтыруу менен чечилбей турган татаал маселе бойдон калууда. Жогорудагы оптималдаштыруудан тышкары, CDNдин артында акселерациянын эң эффективдүү каражаттары калат: сервер бөлүгүн оптималдаштыруу, кардар бөлүгүндө өркүндөтүлгөн өзгөртүүлөр (колдонулбаган кодду алып салуу, рендеринг процессин оптималдаштыруу, мазмун менен иштөө, шрифттер, ыңгайлашуу ж.б.у.с.). )
Source: www.habr.com