Saytın sürətini optimallaşdırmaq üçün demək olar ki, hər bir məqalə və ya alətdə “CDN istifadə edin” müddəası var. Ümumiyyətlə, CDN məzmun çatdırma şəbəkəsi və ya məzmun çatdırma şəbəkəsidir. Method Lab-da biz tez-tez müştərilərin bu mövzuda sualları ilə qarşılaşırıq; onlardan bəziləri öz CDN-lərini işə salır. Bu məqalənin məqsədi CDN-nin saytın yükləmə sürəti baxımından nə təmin edə biləcəyini, hansı problemlərin yarana biləcəyini və hansı hallarda CDN-dən istifadənin əsaslandırıldığını başa düşməkdir.
Şəkildə dövrələnmiş gecikmələr CDN-dən istifadə ilə bağlıdır.
Bir az tarixi
Bir çox texnologiyalar kimi, CDN-lər də zərurətdən yaranıb. İnternet istifadəçiləri arasında internet kanallarının inkişafı ilə onlayn video xidmətləri meydana çıxdı. Təbii ki, video məzmunu adi veb-sayt məzmunu (şəkillər, mətn və CSS və ya JS kodu) ilə müqayisədə daha çox bant genişliyi tələb edir.
Bir serverdən bir çox müştəriyə paralel olaraq video axını yayımlamağa çalışarkən, serverin İnternet kanalı çox güman ki, darboğaza çevriləcək. Bir qayda olaraq, tipik bir server kanalını bağlamaq üçün bir neçə min mövzu kifayətdir. Əlbəttə ki, başqa resurs məhdudiyyətləri ola bilər, lakin onlar hazırda vacib deyil. Server kanalının genişləndirilməsinin çox bahalı (və bəzən qeyri-mümkün) olması da vacibdir, həm də praktiki deyil. Yayımlar zamanı kanalın yükü tsiklik olacaq.
Fərdi serverin kanalının məhdudlaşdırılması problemi CDN tərəfindən mükəmməl şəkildə həll edilir. Müştərilər birbaşa serverə deyil, CDN şəbəkəsindəki qovşaqlara qoşulurlar. İdeal vəziyyətdə server CDN qovşağına bir axın göndərir və sonra şəbəkə bu axını bir çox istifadəçiyə çatdırmaq üçün öz resurslarından istifadə edir. İqtisadi nöqteyi-nəzərdən, biz yalnız faktiki istehlak edilmiş resurslara görə ödəyirik (bu, bant genişliyi və ya trafik ola bilər) və xidmətimizin mükəmməl miqyasını əldə edirik. Ağır məzmunu çatdırmaq üçün CDN-dən istifadə tamamilə əsaslandırılmış və məntiqlidir. Qeyd etmək lazımdır ki, bu məkanda ən böyük oyunçular (məsələn, Netflix) böyük kommersiya CDN-lərindən (Akamai, Cloudflare, Fastly və s.) istifadə etmək əvəzinə öz CDN-lərini qururlar.
Veb inkişaf etdikcə, veb proqramların özləri daha mürəkkəb və mürəkkəb hala gəldi. Yükləmə sürəti problemi gündəmə gəldi. Veb sayt sürətinin həvəskarları veb saytların yavaş yüklənməsinə səbəb olan bir neçə əsas problemi tez bir zamanda müəyyən etdilər. Onlardan biri şəbəkə gecikmələri idi (RTT - gediş-gəliş vaxtı və ya ping vaxtı). Gecikmələr veb saytın yüklənməsində bir çox proseslərə təsir edir: TCP bağlantısının qurulması, TLS sessiyasının başlaması, hər bir fərdi resursun yüklənməsi (şəkil, JS faylı, HTML sənədi və s.)
Problem HTTP/1.1 protokolundan istifadə edərkən (SPDY, QUIC və HTTP/2-nin yaranmasından əvvəl bu yeganə seçim idi) brauzerlərin bir hosta 6-dan çox olmayan TCP bağlantısını açması ilə daha da ağırlaşdı. Bütün bunlar əlaqənin kəsilməsinə və kanalın genişliyindən səmərəsiz istifadəyə gətirib çıxardı. Problem qismən domen parçalanması ilə həll edildi - bağlantıların sayına məhdudiyyəti aradan qaldırmaq üçün əlavə hostların yaradılması.
CDN-nin ikinci qabiliyyəti burada ortaya çıxır - çox sayda nöqtə və qovşaqların istifadəçiyə yaxınlığı səbəbindən gecikmənin azaldılması (RTT). Burada məsafə həlledici rol oynayır: işığın sürəti məhduddur (optik lifdə təxminən 200 km/san). Bu o deməkdir ki, hər 000 km səyahət RTT-yə 1000 ms gecikmə və ya 5 ms əlavə edir. Bu, ötürmə üçün tələb olunan minimum vaxtdır, çünki aralıq avadanlıqda da gecikmələr olur. CDN adətən öz serverlərindəki obyektləri necə önbelleğe almağı bildiyi üçün biz belə obyektləri CDN vasitəsilə yükləməkdən faydalana bilərik. Bunun üçün zəruri şərtlər: obyektin keş yaddaşda olması, veb proqram serveri (mənbə serveri) ilə müqayisədə CDN nöqtəsinin istifadəçiyə yaxınlığı. CDN nodeunun coğrafi yaxınlığının aşağı gecikməyə zəmanət vermədiyini başa düşmək vacibdir. Müştəri ilə CDN arasında marşrutlaşdırma elə qurula bilər ki, müştəri başqa ölkədə və ola bilsin ki, başqa qitədəki hosta qoşulsun. Burada telekommunikasiya operatorları ilə CDN xidməti (peering, əlaqə, IX-da iştirak və s.) arasındakı əlaqə və CDN-nin özünün trafik marşrutlaşdırma siyasəti işə düşür. Məsələn, Cloudflare, iki ilkin plandan (pulsuz və ucuz) istifadə edərkən məzmunun ən yaxın hostdan çatdırılmasına zəmanət vermir - minimum xərcə nail olmaq üçün host seçiləcək.
Bir çox aparıcı İnternet şirkətləri yükləmə sürəti və veb saytın performansı mövzusuna ictimai marağı (veb tərtibatçıları və xidmət sahibləri) cəlb edir. Bu şirkətlər arasında saytları sürətləndirmək üçün öz tövsiyələrini hazırlayan Yahoo (Yslow aləti), AOL (WebPageTest) və Google (Page Speed Insights xidməti) var (əsasən müştərilərin optimallaşdırılmasına aiddir). Daha sonra, veb sayt sürətini artırmaq üçün məsləhətlər verən yeni veb sayt sürət testi alətləri görünür. Bu xidmətlərin və ya plaginlərin hər birinin ardıcıl tövsiyəsi var: “CDN istifadə edin”. Şəbəkə gecikmə müddətinin azalması adətən CDN-nin təsirinin izahı kimi göstərilir. Təəssüf ki, hər kəs CDN-nin sürətləndirici təsirinin necə əldə edildiyini və onun necə ölçülə biləcəyini dəqiq başa düşməyə hazır deyil, buna görə də tövsiyə iman üzərində qəbul edilir və bir postulat kimi istifadə olunur. Əslində, bütün CDN-lər bərabər yaradılmır.
Bu gün CDN-dən istifadə
CDN-lərdən istifadənin faydalılığını qiymətləndirmək üçün onları təsnif etmək lazımdır. İndi praktikada nə tapmaq olar (mötərizədə göstərilən nümunələr, əlbəttə ki, tam deyil):
- JS kitabxanalarının yayılması üçün pulsuz CDN (MaxCDN, Google. Yandex).
- Müştərilərin optimallaşdırılması üçün xidmətlərin CDN-i (məsələn, şriftlər üçün Google Fonts, Cloudinary, şəkillər üçün Cloudimage).
- CMS-də statik və resurs optimallaşdırılması üçün CDN (Bitrix, WordPress və başqalarında mövcuddur).
- Ümumi təyinatlı CDN (StackPath, CDNVideo, NGENIX, Megafon).
- Veb saytın sürətləndirilməsi üçün CDN (Cloudflare, Imperva, Airi).
Bu növlər arasındakı əsas fərq, trafikin nə qədər CDN-dən keçməsidir. 1-3 növlər məzmunun yalnız bir hissəsinin çatdırılmasıdır: bir sorğudan bir neçə onlarla (adətən şəkillər). 4 və 5-ci növlər CDN vasitəsilə trafikin tam proxyləşdirilməsidir.
Praktikada bu, saytı yükləmək üçün istifadə olunan əlaqələrin sayı deməkdir. HTTP/2 ilə biz istənilən sayda sorğunu emal etmək üçün hosta tək TCP bağlantısından istifadə edirik. Əgər resursları əsas host (mənşə) və CDN-ə bölsək, onda sorğuları bir neçə domen üzrə paylamaq və bir neçə TCP əlaqəsi yaratmaq lazımdır. Ən pis vəziyyət: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Bu düstur cihazın radio kanalının aktivləşdirilməsi üçün mobil şəbəkələrdə gecikmələri (əgər aktiv deyildisə) və mobil qüllədəki gecikmələri nəzərə almır.
Saytın yükləmə şəlaləsində belə görünür (CDN-yə qoşulma gecikmələri RTT 150 ms-də vurğulanır):
CDN bütün sayt trafikini əhatə edirsə (üçüncü tərəf xidmətləri istisna olmaqla), onda biz əlavə hostlara qoşulma gecikmələrinə qənaət edərək tək TCP bağlantısından istifadə edə bilərik. Təbii ki, bu HTTP/2 bağlantılarına aiddir.
Əlavə fərqlər müəyyən bir CDN-nin funksionallığı ilə müəyyən edilir - birinci növ üçün o, sadəcə statik faylı saxlayır, beşincisi üçün optimallaşdırma məqsədilə bir neçə növ sayt məzmununu dəyişir.
Veb saytın sürətləndirilməsi üçün CDN imkanları
Fərdi CDN növlərinin funksionallığını nəzərə almadan saytları sürətləndirmək üçün CDN imkanlarının tam spektrini təsvir edək və sonra onların hər birində nəyin həyata keçirildiyinə baxaq.
1. Mətn resurslarının sıxılması
Ən əsas və başa düşülən xüsusiyyət, lakin çox vaxt zəif həyata keçirilir. Bütün CDN-lər sıxılmanın mövcudluğunu sürətləndirmə xüsusiyyəti kimi elan edir. Ancaq daha ətraflı baxsanız, çatışmazlıqlar aydın olur:
- dinamik sıxılma üçün aşağı dərəcələrdən istifadə edilə bilər - 5-6 (məsələn, gzip üçün maksimum 9-dur);
- statik sıxılma (keshdəki fayllar) əlavə funksiyalardan istifadə etmir (məsələn, zopfi və ya 11 dərəcə ilə brotli)
- səmərəli brotli sıxılma dəstəyi yoxdur (gzip ilə müqayisədə təxminən 20% qənaət).
CDN istifadə edirsinizsə, bu bir neçə məqamı yoxlamağa dəyər: CDN-dən gələn faylı götürün, sıxılmış ölçüsünü qeyd edin və müqayisə üçün əl ilə sıxın (məsələn, brotli dəstəyi ilə bəzi onlayn xidmətlərdən istifadə edə bilərsiniz. ).
2. Müştəri keşləmə başlıqlarının qurulması
Həmçinin sadə sürətləndirmə xüsusiyyəti: müştəri (brauzer) tərəfindən məzmunun keşlənməsi üçün başlıqlar əlavə edin. Ən cari başlıq keş-nəzarətdir, köhnəlmiş başlığın müddəti bitmişdir. Bundan əlavə, Etag istifadə edilə bilər. Əsas odur ki, keş-nəzarətin maksimal yaşı kifayət qədər böyükdür (bir aydan və ya daha çox) Əgər siz resursu mümkün qədər sərt şəkildə keşləməyə hazırsınızsa, dəyişməz variantı əlavə edə bilərsiniz.
CDN-lər maksimum yaş dəyərini aşağı sala bilər, bu da istifadəçini statik məzmunu daha tez-tez yenidən yükləməyə məcbur edir. Bunun nə ilə əlaqəli olduğu aydın deyil: şəbəkədə trafiki artırmaq və ya keşi necə sıfırlamağı bilməyən saytlarla uyğunluğu artırmaq istəyi. Məsələn, defolt Cloudflare başlıq keş vaxtı 1 saatdır, bu dəyişməz statik məlumatlar üçün çox aşağıdır.
3. Təsvirin optimallaşdırılması
CDN şəkillərin önbelleğe alınması və təqdim edilməsi funksiyalarını öz üzərinə götürdüyü üçün onları CDN tərəfində optimallaşdırmaq və bu formada istifadəçilərə xidmət etmək məntiqli olardı. Dərhal qeyd edək ki, bu funksiya yalnız CDN 2, 3 və 5 növləri üçün əlçatandır.
Siz müxtəlif üsullarla şəkilləri optimallaşdıra bilərsiniz: qabaqcıl sıxılma formatlarından (məsələn, WebP), daha səmərəli kodlayıcılardan (MozJPEG) istifadə etməklə və ya sadəcə olaraq lazımsız metadataları təmizləmək.
Ümumiyyətlə, bu cür optimallaşdırmaların iki növü var: keyfiyyət itkisi ilə və keyfiyyət itkisi olmadan. CDN-lər adətən görüntü keyfiyyətindəki dəyişikliklərlə bağlı mümkün müştəri şikayətlərinin qarşısını almaq üçün itkisiz optimallaşdırmadan istifadə etməyə çalışırlar. Belə şəraitdə qazanc minimal olacaqdır. Əslində, çox vaxt JPEG keyfiyyət səviyyəsi lazım olandan çox yüksək olur və siz istifadəçi təcrübəsinə xələl gətirmədən aşağı keyfiyyət səviyyəsi ilə təhlükəsiz şəkildə yenidən sıxışdıra bilərsiniz. Digər tərəfdən, bütün mümkün veb proqramlar üçün universal olaraq keyfiyyət və parametrlərin səviyyəsini müəyyən etmək çətindir, ona görə də CDN-lər kontekst (şəkillərin məqsədi, veb tətbiqinin növü) nəzərə alınmaqla tətbiq oluna bilənlərlə müqayisədə daha mühafizəkar parametrlərdən istifadə edir. və s.)
4. TLS bağlantısının optimallaşdırılması
Bu gün əksər trafik TLS bağlantıları üzərindən keçir, yəni TLS danışıqlarına əlavə vaxt sərf edirik. Son zamanlar bu prosesi sürətləndirmək üçün yeni texnologiyalar işlənib hazırlanmışdır. Məsələn, bu, EC kriptoqrafiyası, TLS 1.3, sessiya keşi və biletləri, aparat şifrələməsinin sürətləndirilməsi (AES-NI) və s.dir. TLS-nin düzgün qurulması qoşulma vaxtını 0-1 RTT-yə qədər azalda bilər (DNS və TCP nəzərə alınmadan ).
Müasir proqram təminatı ilə bu cür təcrübələri təkbaşına həyata keçirmək çətin deyil.
Bütün CDN-lər TLS ən yaxşı təcrübələrini tətbiq etmir; siz TLS əlaqə vaxtını ölçməklə bunu yoxlaya bilərsiniz (məsələn, Webpagetest-də). Yeni əlaqə üçün idealdır - 1RTT, 2RTT - orta səviyyə, 3RTT və daha çox - pis.
Onu da qeyd etmək lazımdır ki, hətta CDN səviyyəsində TLS-dən istifadə edərkən belə, bizim veb proqramımız olan server TLS-ni də emal etməlidir, lakin CDN tərəfdən, çünki server və CDN arasındakı trafik ictimai şəbəkədən keçir. Ən pis halda, ikiqat TLS əlaqə gecikmələri alacağıq (birincisi CDN hostuna, ikincisi onunla serverimiz arasında).
Bəzi proqramlar üçün təhlükəsizlik məsələlərinə diqqət yetirməyə dəyər: trafik adətən CDN qovşaqlarında şifrələnir və bu, trafikin qarşısını almaq üçün potensial imkandır. Trafik açıqlanmadan işləmək seçimi adətən əlavə ödəniş üçün yüksək tarif planlarında təklif olunur.
5. Bağlantı gecikmələrini azaldın
CDN-nin hər kəsin danışdığı əsas faydası: CDN sahibi ilə istifadəçi arasında aşağı gecikmə (daha az məsafə). Hostların istifadəçilərin cəmləşdiyi yerlərdə (şəhərlər, trafik mübadiləsi nöqtələri və s.)
Praktikada müxtəlif şəbəkələr üçün prioritetlər konkret regionlarda ola bilər. Məsələn, Rusiya CDN-lərinin Rusiyada daha çox iştirak nöqtəsi olacaq. Amerikalılar ilk növbədə ABŞ-da şəbəkəni inkişaf etdirəcəklər. Məsələn, ən böyük CDN Cloudflare-dən biri Rusiyada - Moskva və Sankt-Peterburqda cəmi 2 nöqtəyə malikdir. Yəni, Moskvada birbaşa yerləşdirmə ilə müqayisədə maksimum təxminən 10 ms gecikmə saxlaya bilərik.
Əksər Qərb CDN-lərinin Rusiyada ümumiyyətlə nöqtələri yoxdur. Onlara qoşulmaqla siz yalnız rus auditoriyanız üçün gecikmələri artıra bilərsiniz.
6. Məzmunun optimallaşdırılması (minifikasiya, struktur dəyişiklikləri)
Ən mürəkkəb və texnoloji cəhətdən inkişaf etmiş nöqtə. Çatdırılma zamanı məzmunun dəyişdirilməsi çox riskli ola bilər. Kiçikləşdirmə götürsək belə: mənbə kodunun azaldılması (əlavə boşluqlar, əhəmiyyətsiz strukturlar və s. görə) onun işinə təsir edə bilər. Daha ciddi dəyişikliklərdən danışsaq - JS kodunu HTML-in sonuna köçürmək, faylları birləşdirmək və s. - saytın funksionallığını pozmaq riski daha da yüksəkdir.
Buna görə də, yalnız bəzi tip 5 CDN-lər bunu edir. Əlbəttə ki, işləri sürətləndirmək üçün lazım olan bütün dəyişiklikləri avtomatlaşdırmaq mümkün olmayacaq - əl ilə təhlil və optimallaşdırma tələb olunur. Məsələn, istifadə olunmamış və ya dublikat kodu silmək əl işidir.
Bir qayda olaraq, bütün bu cür optimallaşdırmalar parametrlər tərəfindən idarə olunur və ən təhlükəli olanlar standart olaraq söndürülür.
CDN növü üzrə sürətləndirmə imkanlarına dəstək
Beləliklə, müxtəlif CDN növlərinin hansı potensial sürətləndirmə imkanlarına nəzər salaq.
Rahatlıq üçün təsnifatı təkrarlayırıq.
- JS kitabxanalarının yayılması üçün pulsuz CDN (MaxCDN, Google. Yandex).
- Müştərilərin optimallaşdırılması üçün xidmətlərin CDN-i (məsələn, şriftlər üçün Google Fonts, Cloudinary, şəkillər üçün Cloudimage).
- CMS-də statik və resurs optimallaşdırılması üçün CDN (Bitrix, WordPress və başqalarında mövcuddur).
- Ümumi təyinatlı CDN (StackPath, CDNVideo, NGENIX, Megafon).
- Veb saytın sürətləndirilməsi üçün CDN (Cloudflare, Imperva, Airi).
İndi CDN-nin xüsusiyyətlərini və növlərini müqayisə edək.
Imkan
1 yazın
2 yazın
3 yazın
4 yazın
5 yazın
Mətnin sıxılması
+–
-
+–
+–
+
Keş başlıqları
+
+
+
+
+
Şəkillər
-
+–
+–
-
+
TLS
-
-
-
+–
+
Gecikmələr
-
-
-
+
+
Məzmun
-
-
-
-
+
Bu cədvəldə “+” tam dəstəyi göstərmək üçün istifadə olunur, “–” dəstəyi yoxdur, “+–” isə qismən dəstəyi göstərir. Əlbəttə ki, reallıqda bu cədvəldən kənarlaşmalar ola bilər (məsələn, bəzi ümumi təyinatlı CDN şəkilləri optimallaşdırmaq üçün funksiyaları həyata keçirəcək), lakin ümumi fikir üçün bu faydalıdır.
Nəticələri
Ümid edirik ki, bu məqaləni oxuduqdan sonra saytlarınızı sürətləndirmək üçün “CDN istifadə edin” tövsiyəsi ilə bağlı daha aydın təsəvvür əldə edəcəksiniz.
Hər hansı bir işdə olduğu kimi, heç bir xidmətin marketinq vədlərinə inana bilməzsiniz. Təsiri real şəraitdə ölçmək və sınaqdan keçirmək lazımdır. Əgər siz artıq bir CDN istifadə edirsinizsə, məqalədə təsvir olunan meyarlardan istifadə edərək effektivliyini yoxlayın.
Ola bilsin ki, hazırda CDN-dən istifadə saytınızın yükləmə vaxtını ləngidir.
Ümumi tövsiyə olaraq aşağıdakılara diqqət yetirə bilərik: auditoriyanızı öyrənin, onun coğrafi əhatəsini müəyyənləşdirin. Əsas auditoriyanız 1-2 min kilometr radiusda cəmləşibsə, onun əsas məqsədi - gecikmə müddətini azaltmaq üçün CDN-ə ehtiyacınız yoxdur. Bunun əvəzinə, məqalədə təsvir olunan optimallaşdırmaların əksəriyyətini əldə edərək (pulsuz və daimi) serverinizi istifadəçilərinizə daha yaxın yerləşdirə və düzgün konfiqurasiya edə bilərsiniz.
Auditoriyanız həqiqətən coğrafi olaraq paylanmışsa (radius 3000 kilometrdən çox), keyfiyyətli CDN-dən istifadə etmək həqiqətən faydalı olacaq. Bununla belə, CDN-nin tam olaraq nəyi sürətləndirə biləcəyini əvvəlcədən başa düşməlisiniz (imkanlar cədvəlinə və onların təsvirinə baxın). Bununla belə, veb saytın sürətləndirilməsi hələ də CDN-ni birləşdirməklə həll edilə bilməyən mürəkkəb bir vəzifə olaraq qalır. Yuxarıda göstərilən optimallaşdırmalara əlavə olaraq, CDN-nin arxasında ən təsirli sürətləndirmə vasitələri qalır: server hissəsinin optimallaşdırılması, müştəri hissəsinə qabaqcıl dəyişikliklər (istifadə olunmamış kodun çıxarılması, göstərmə prosesinin optimallaşdırılması, məzmunla işləmək, şriftlər, uyğunlaşma və s.). )
Mənbə: www.habr.com