[Ulah] ngagunakeun CDN

Ampir unggal artikel atanapi alat pikeun ngaoptimalkeun kagancangan situs ngagaduhan klausa anu sederhana "nganggo CDN." Sacara umum, CDN nyaéta jaringan pangiriman eusi atawa jaringan pangiriman eusi. Kami di Method Lab sering mendakan patarosan ti klien ngeunaan topik ieu; sababaraha di antarana ngaktifkeun CDN sorangan. Tujuan tina tulisan ieu nyaéta pikeun ngartos naon anu tiasa disayogikeun ku CDN tina segi kecepatan ngamuat situs, masalah naon anu timbul, sareng dina kasus naon waé panggunaan CDN diyakinkeun.

Keterlambatan dikurilingan dina gambar disababkeun ku pamakéan CDN.

A sajarah saeutik

Sapertos seueur téknologi, CDN muncul tina kabutuhan. Kalayan ngembangkeun saluran Internét diantara pangguna Internét, jasa pidéo online muncul. Alami, eusi video merlukeun pesenan badagna leuwih rubakpita dibandingkeun eusi ramatloka biasa (gambar, téks, jeung CSS atawa kode JS).

Nalika nyobian nyiarkeun aliran pidéo paralel sareng seueur klien tina hiji server, saluran Internét pangladén sigana bakal janten bottleneck. Sakumaha aturan, sababaraha sarébu threads cukup pikeun bakiak saluran server has. Tangtosna, meureun aya watesan sumberdaya sanés, tapi aranjeunna henteu penting ayeuna. Éta ogé penting yén ngembangna saluran server teuing mahal (jeung kadang teu mungkin), sarta ogé praktis. Beban dina saluran salila siaran bakal cyclical.

Masalah ngawatesan saluran hiji server individu sampurna direngsekeun ku CDN. Klién henteu langsung nyambung ka server, tapi ka titik dina jaringan CDN. Dina kaayaan idéal, server ngirimkeun hiji aliran ka titik CDN, lajeng jaringan ngagunakeun sumberdaya sorangan pikeun nganteurkeun aliran ieu ka loba pamaké. Tina sudut pandang ékonomi, urang ngan ukur mayar kanggo sumber daya anu dikonsumsi (ieu tiasa janten rubakpita atanapi lalu lintas) sareng kéngingkeun skalabilitas jasa kami. Ngagunakeun CDN pikeun nganteurkeun eusi beurat sagemblengna diyakinkeun tur logis. Sanajan éta sia noting yén pamaén pangbadagna di rohangan ieu (misalna Netflix) ngawangun CDN sorangan tinimbang ngagunakeun CDN komérsial badag (Akamai, Cloudflare, Fastly, jsb)

Nalika wéb parantos mekar, aplikasi wéb nyalira janten langkung kompleks sareng kompleks. Masalah speed loading sumping ka fore. Peminat kacepetan situs wéb gancang ngaidentipikasi sababaraha masalah utama anu nyababkeun halaman wéb laun dimuat. Salah sahijina nyaéta telat jaringan (RTT - waktos perjalanan buleud atanapi waktos ping). Telat mangaruhan seueur prosés dina ngamuat halaman wéb: ngadegkeun sambungan TCP, ngamimitian sési TLS, ngamuat unggal sumber daya individu (gambar, file JS, dokumén HTML, jsb.)

Masalahna diperparah ku kanyataan yén nalika nganggo protokol HTTP / 1.1 (saméméh mecenghulna SPDY, QUIC sareng HTTP / 2 ieu mangrupikeun hiji-hijina pilihan), panyungsi muka henteu langkung ti 6 sambungan TCP ka hiji host. Sadaya ieu nyababkeun downtime sambungan sareng panggunaan bandwidth saluran anu teu cekap. Masalahna sawaréh direngsekeun ku sharding domain - nyiptakeun host tambahan pikeun ngatasi wates jumlah sambungan.

Ieu dimana kamampuan kadua CDN muncul - ngirangan latency (RTT) kusabab jumlah titik anu ageung sareng jarak titik ka pangguna. Jarak maénkeun peran anu penting di dieu: laju cahaya diwatesan (kira-kira 200 km/s dina serat optik). Ieu ngandung harti yén unggal 000 km perjalanan nambahan 1000 mdet reureuh atawa 5 mdet RTT. Ieu mangrupikeun waktos minimum anu diperyogikeun pikeun pangiriman, sabab aya ogé telat dina alat-alat panengah. Kusabab CDN biasana terang kumaha cache objék dina server na, urang tiasa nyandak kauntungan tina ngamuat objék sapertos ngalangkungan CDN. Kaayaan anu dipikabutuh pikeun ieu: ayana obyék dina cache, jarak titik CDN ka pangguna dibandingkeun sareng server aplikasi wéb (server asal). Penting pikeun ngarti yén jarak geografis tina titik CDN henteu ngajamin latency rendah. Routing antara klien tur CDN bisa diwangun dina cara sapertos nu klien bakal nyambung ka host di nagara sejen, jeung kamungkinan dina buana sejen. Ieu dimana hubungan antara operator telekomunikasi jeung layanan CDN (peering, sambungan, partisipasi dina IX, jsb) jeung kawijakan routing lalulintas CDN sorangan datang kana antrian. Contona, Cloudflare, nalika ngagunakeun dua rencana awal (gratis tur mirah), teu ngajamin pangiriman eusi ti host pangcaketna - host bakal dipilih pikeun ngahontal biaya minimum.

Seueur perusahaan Internét anu unggul narik minat umum (pamekar wéb sareng pamilik jasa) kana topik ngeunaan laju ngamuat sareng kinerja halaman wéb. Di antara perusahaan-perusahaan ieu nyaéta Yahoo (alat Yslow), AOL (WebPageTest) sareng Google (layanan Page Speed ​​​​Insights), anu ngembangkeun saran sorangan pikeun nyepetkeun situs (utamana aya hubunganana sareng optimasi klien). Engké, alat nguji speed ramatloka anyar muncul, nu ogé nyadiakeun tips on ngaronjatkeun kagancangan ramatloka. Masing-masing jasa atanapi plugins ieu gaduh rekomendasi anu konsisten: "Paké CDN." Pangurangan dina latency jaringan biasana dicutat salaku panjelasan pikeun pangaruh CDN. Hanjakal, teu sadaya jelema siap ngartos persis kumaha pangaruh akselerasi CDN kahontal sarta kumaha eta bisa diukur, jadi rekomendasi nu dicokot dina iman sarta dipaké salaku postulat a. Kanyataanna, teu kabeh CDNs dijieun sarua.

Ngagunakeun CDN Dinten

Pikeun meunteun mangpaat ngagunakeun CDN, aranjeunna kedah digolongkeun. Naon anu tiasa dipendakan ayeuna dina prakna (conto dina kurung, tangtosna, henteu lengkep):

1. CDN bébas pikeun ngadistribusikaeun perpustakaan JS (MaxCDN, Google. Yandex).
2. CDN jasa pikeun optimasi klien (contona, Google Fonts pikeun fon, Cloudinary, Cloudimage pikeun gambar).
3. CDN pikeun optimasi statik sareng sumber daya dina CMS (sayogi dina Bitrix, WordPress sareng anu sanésna).
4. Tujuan umum CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN pikeun akselerasi ramatloka (Cloudflare, Imperva, Airi).

Beda konci antara jenis ieu téh sabaraha lalulintas ngaliwatan CDN. Tipe 1-3 mangrupikeun pangiriman ngan ukur bagian tina eusi: tina hiji pamundut ka sababaraha belasan (biasana gambar). Tipe 4 sareng 5 mangrupikeun proksi pinuh ku lalu lintas via CDN.

Dina prakna, ieu hartosna jumlah sambungan anu dianggo pikeun ngamuat situs. Kalayan HTTP / 2, kami nganggo sambungan TCP tunggal ka host pikeun ngolah sajumlah pamundut. Lamun urang ngabagi sumberdaya kana host utama (asal) jeung CDN, mangka perlu pikeun ngadistribusikaeun requests sakuliah sababaraha domain jeung nyieun sababaraha sambungan TCP. Kasus awon nyaeta: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Rumus ieu henteu nganggap telat dina jaringan sélulér pikeun aktivasina saluran radio alat (upami henteu aktip) sareng telat dina menara sél.

Kieu kumaha rupana dina curug loading situs (latency pikeun nyambungkeun ka CDN disorot dina RTT 150 ms):

Upami CDN nyertakeun sadaya lalu lintas situs (iwal jasa pihak katilu), maka urang tiasa nganggo sambungan TCP tunggal, ngahemat telat dina nyambungkeun ka host tambahan. Tangtu, ieu manglaku ka HTTP / 2 sambungan.

Bedana salajengna ditangtukeun ku pungsionalitas CDN tinangtu - pikeun tipe kahiji ieu ngan hosting file statik, pikeun kalima eta ngarobah sababaraha jenis eusi situs keur kaperluan optimasi.

kamampuhan CDN pikeun akselerasi ramatloka

Hayu urang ngajelaskeun rentang pinuh ku kamampuhan CDN pikeun accelerating situs, tanpa hal ka pungsionalitas tipe individu CDN, lajeng tingali naon dilaksanakeun dina unggal sahijina.

1. Komprési sumberdaya téks

Fitur anu paling dasar sareng kaharti, tapi sering kirang dilaksanakeun. Sadaya CDN nyatakeun ayana komprési salaku fitur akselerasina. Tapi lamun nempo leuwih jéntré, shortcomings jadi jelas:

• derajat low pikeun komprési dinamis bisa dipaké - 5-6 (contona, pikeun gzip maksimum nyaéta 9);
• komprési statik (file dina cache) henteu nganggo fitur tambahan (contona, zopfi atanapi brotli kalayan gelar 11)
• euweuh rojongan pikeun komprési brotli efisien (nyimpen ngeunaan 20% dibandingkeun gzip).

Upami anjeun nganggo CDN, éta patut pariksa sababaraha titik ieu: cokot file anu asalna tina CDN, rekam ukuranana anu dikomprés sareng komprési sacara manual pikeun ngabandingkeun (anjeun tiasa nganggo sababaraha layanan online kalayan dukungan brotli, contona. vsszhat.rf).

2. Nyetél lulugu cache klien

Ogé fitur speedup basajan: nambahkeun lulugu pikeun eusi cache ku klien (browser). Header anu paling ayeuna nyaéta cache-control, anu luntur parantos kadaluwarsa. Salaku tambahan, Etag tiasa dianggo. Hal utama anu max-umur cache-kontrol cukup badag (ti sabulan atawa leuwih) Mun anjeun geus siap cache sumberdaya sakumaha teuas sabisa, Anjeun bisa nambah pilihan immutable.

CDN tiasa nurunkeun nilai umur maksimal, maksa pangguna pikeun ngamuat eusi statik langkung sering. Henteu écés naon hubunganana ieu: kahayang pikeun ningkatkeun lalu lintas dina jaringan atanapi ningkatkeun kasaluyuan sareng situs anu henteu terang kumaha ngareset cache. Salaku conto, standar Cloudflare header waktos cache nyaéta 1 jam, anu rendah pisan pikeun data statik anu teu tiasa dirobih.

3. Optimasi gambar

Kusabab CDN nyandak fungsi caching sareng ngalayanan gambar, éta logis pikeun ngaoptimalkeunana dina sisi CDN sareng ngalayanan ka pangguna dina bentuk ieu. Hayu urang ngadamel reservasi langsung yén fitur ieu ngan sadia pikeun tipe CDN 2, 3 jeung 5.

Anjeun tiasa ngaoptimalkeun gambar ku sababaraha cara: nganggo format komprési canggih (sapertos WebP), enkoder langkung éfisién (MozJPEG), atanapi ngan ukur ngabersihkeun metadata anu teu perlu.

Sacara umum, aya dua jinis optimasi sapertos: kalayan leungitna kualitas sareng tanpa leungitna kualitas. CDNs biasana narékahan ngagunakeun optimasi lossless guna nyingkahan keluhan customer mungkin ngeunaan parobahan kualitas gambar. Dina kaayaan kitu, gain bakal minimal. Kanyataanana, sering tingkat kualitas JPEG jauh leuwih luhur ti diperlukeun tur anjeun bisa aman recompress kalawan tingkat kualitas handap tanpa kompromi pangalaman pamaké. Di sisi anu sanésna, hese nangtukeun tingkat kualitas sareng setélan sacara universal pikeun sadaya aplikasi wéb anu mungkin, ku kituna CDN nganggo setélan anu langkung konservatif dibandingkeun sareng anu tiasa diterapkeun kalayan merhatikeun kontéks (tujuan gambar, jinis aplikasi wéb. , jsb.)

4. Optimizing sambungan TLS

Kaseueuran lalu lintas ayeuna ngalangkungan sambungan TLS, anu hartosna urang nyéépkeun waktos tambahan dina hungkul TLS. Anyar-anyar ieu, téknologi anyar parantos dikembangkeun pikeun nyepetkeun prosés ieu. Contona, ieu EC kriptografi, TLS 1.3, sési cache sarta tiket, akselerasi enkripsi hardware (AES-NI), jsb bener setelan TLS bisa ngurangan waktu sambungan ka 0-1 RTT (teu cacah DNS na TCP ).

Kalayan parangkat lunak modéren, henteu sesah ngalaksanakeun prakték sapertos kitu nyalira.

Henteu sadayana CDN ngalaksanakeun prakték pangsaéna TLS; anjeun tiasa pariksa ieu ku cara ngukur waktos sambungan TLS (contona, dina Webpagetest). Idéal pikeun sambungan anyar - 1RTT, 2RTT - tingkat rata, 3RTT tur leuwih - goréng.

Ogé kudu dicatet yén sanajan ngagunakeun TLS di tingkat CDN, server jeung aplikasi wéb urang ogé kudu ngolah TLS, tapi ti sisi CDN, sabab lalulintas antara server jeung CDN ngaliwatan jaringan umum. Dina kasus anu paling parah, urang bakal nampi dua kali telat sambungan TLS (kahiji ka host CDN, anu kadua antara éta sareng server kami).

Kanggo sababaraha aplikasi, éta patut nengetan masalah kaamanan: lalu lintas biasana didekripsi dina titik CDN, sareng ieu mangrupikeun kasempetan poténsial pikeun interception lalulintas. Pilihan pikeun digawé tanpa panyingkepan lalu lintas biasana ditawarkeun dina rencana tarif luhur pikeun biaya tambahan.

5. Ngurangan telat sambungan

Kauntungan utama CDN anu diomongkeun ku sadayana: latency rendah (jarak kirang) antara host CDN sareng pangguna. Kahontal ku nyiptakeun arsitéktur jaringan anu disebarkeun sacara geografis, dimana host lokasina di titik konsentrasi pangguna (kota, titik pertukaran lalu lintas, jsb.)

Dina prakték, prioritas pikeun jaringan béda bisa jadi di wewengkon husus. Salaku conto, CDN Rusia bakal gaduh langkung seueur titik ayana di Rusia. Anu Amérika munggaran bakal ngembangkeun jaringan di AS. Salaku conto, salah sahiji CDN Cloudflare panggedéna ngan ukur 2 titik di Rusia - Moscow sareng St. Nyaéta, urang tiasa nyimpen maksimal sakitar 10 ms latency dibandingkeun sareng panempatan langsung di Moskow.

Kaseueuran CDN Kulon henteu ngagaduhan titik di Rusia. Ku ngahubungkeun ka aranjeunna, anjeun ngan ukur tiasa ningkatkeun telat pikeun pamiarsa Rusia anjeun.

6. Optimasi eusi (minification, parobahan struktural)

Titik paling pajeulit jeung technologically canggih. Ngarobah eusi salila pangiriman tiasa pisan picilakaeun. Malah lamun urang nyandak minification: ngurangan kodeu sumber (kusabab spasi tambahan, struktur teu penting, jsb) bisa mangaruhan kinerja na. Lamun urang ngobrol ngeunaan parobahan leuwih serius - mindahkeun kode JS ka ahir HTML, merging file, jsb - résiko disrupting pungsionalitas situs malah leuwih luhur.

Ku alatan éta, ngan sababaraha tipe 5 CDNs ngalakukeun ieu. Tangtosna, éta moal mungkin pikeun ngajadikeun otomatis sadaya parobihan anu dipikabutuh pikeun nyepetkeun hal-hal éta peryogi analisis manual sareng optimasi. Salaku conto, ngahapus kode anu henteu dianggo atanapi duplikat mangrupikeun tugas manual.

Sakumaha aturan, sadaya optimasi sapertos dikawasa ku setélan sareng anu paling bahaya ditumpurkeun sacara standar.

Rojongan pikeun kamampuan akselerasi ku jinis CDN

Janten hayu urang tingali naon kasempetan akselerasi poténsi anu disayogikeun ku sababaraha jinis CDN.

Pikeun genah, urang ngulang klasifikasi.

1. CDN bébas pikeun ngadistribusikaeun perpustakaan JS (MaxCDN, Google. Yandex).
2. CDN jasa pikeun optimasi klien (contona, Google Fonts pikeun fon, Cloudinary, Cloudimage pikeun gambar).
3. CDN pikeun optimasi statik sareng sumber daya dina CMS (sayogi dina Bitrix, WordPress sareng anu sanésna).
4. Tujuan umum CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN pikeun akselerasi ramatloka (Cloudflare, Imperva, Airi).

Ayeuna urang ngabandingkeun fitur sareng jinis CDN.

kasempetan
Ketik 1
Ketik 2
Ketik 3
Ketik 4
Ketik 5

Komprési téks
+–
-
+–
+–
+

Cache lulugu
+
+
+
+
+

Gambar
-
+–
+–
-
+

TLS
-
-
-
+–
+

reureuh
-
-
-
+
+

Eusi
-
-
-
-
+

Dina tabel ieu, "+" dianggo pikeun nunjukkeun dukungan lengkep, "-" henteu aya dukungan, sareng "+-" mangrupikeun dukungan parsial. Tangtosna, meureun aya panyimpangan tina tabel ieu dina kanyataanana (contona, sababaraha CDN tujuan umum bakal nerapkeun fitur pikeun ngaoptimalkeun gambar), tapi pikeun ide umum éta mangpaat.

hasil

Muga-muga, saatos maca tulisan ieu anjeun bakal gaduh gambaran anu langkung jelas ngeunaan rekomendasi "nganggo CDN" pikeun nyepetkeun situs anjeun.

Sapertos dina bisnis naon waé, anjeun moal tiasa percanten kana janji pamasaran jasa naon waé. Pangaruhna kedah diukur sareng diuji dina kaayaan nyata. Upami anjeun parantos nganggo CDN, pariksa efektivitasna nganggo kriteria anu dijelaskeun dina tulisan.

Éta kamungkinan yén ngagunakeun CDN ayeuna ngalambatkeun waktos ngamuat situs anjeun.

Salaku rekomendasi umum, urang tiasa difokuskeun ieu: diajar panongton anjeun, nangtukeun wengkuan geografis na. Upami panongton utama anjeun konsentrasi dina radius 1-2 sarébu kilométer, anjeun henteu peryogi CDN pikeun tujuan utami - ngirangan latency. Gantina, anjeun tiasa nempatkeun server anjeun ngadeukeutan ka pamaké anjeun sarta ngonpigurasikeun eta leres, meunang lolobana optimizations dijelaskeun dina artikel (gratis tur permanén).

Bisi panongton anjeun leres-leres disebarkeun sacara geografis (radius langkung ti 3000 kilométer), ngagunakeun CDN anu kualitasna bakal mangpaat. Nanging, anjeun kedah ngartos sateuacanna naon anu CDN anjeun tiasa nyepetkeun (tingali tabel kamampuan sareng pedaranana). Sanajan kitu, akselerasi ramatloka masih tetep tugas kompléks nu teu bisa direngsekeun ku nyambungkeun CDN a. Salian optimasi di luhur, cara akselerasi anu paling efektif tetep aya di tukangeun CDN: optimasi bagian server, parobahan maju ka bagian klien (ngahapus kode anu henteu kapake, ngaoptimalkeun prosés rendering, damel sareng eusi, fon, adaptasi, jsb. )

sumber: www.habr.com