[Aja] nggunakake CDN

Meh saben artikel utawa alat kanggo ngoptimalake kacepetan situs nduweni klausa sederhana "nggunakake CDN." Umumé, CDN minangka jaringan pangiriman konten utawa jaringan pangiriman konten. Kita ing Method Lab asring nemoni pitakonan saka klien babagan topik iki; sawetara sing ngaktifake CDN dhewe. Tujuan saka artikel iki yaiku kanggo mangerteni apa sing bisa diwenehake CDN babagan kacepetan loading situs, masalah apa sing bisa kedadeyan, lan ing kasus apa wae panggunaan CDN bisa ditrapake.

Penundaan sing dibunderake ing gambar kasebut disebabake nggunakake CDN.

Sawetara sejarah

Kaya akeh teknologi, CDN metu saka kabutuhan. Kanthi pangembangan saluran Internet ing antarane pangguna Internet, layanan video online muncul. Mesthine, konten video mbutuhake urutan bandwidth luwih akeh dibandhingake karo konten situs web biasa (gambar, teks, lan kode CSS utawa JS).

Nalika nyoba nyebarake stream video kanthi paralel karo akeh klien saka siji server, saluran Internet server kasebut bakal dadi bottleneck. Minangka aturan, sawetara ewu thread cukup kanggo clog saluran server khas. Mesthi, bisa uga ana watesan sumber daya liyane, nanging ora penting saiki. Sampeyan uga penting yen ngembangake saluran server larang banget (lan kadhangkala ora mungkin), lan uga ora praktis. Beban ing saluran sajrone siaran bakal dadi siklus.

Masalah kanggo mbatesi saluran saka server individu ditanggulangi kanthi becik dening CDN. Klien ora nyambung menyang server langsung, nanging menyang simpul ing jaringan CDN. Ing kahanan sing becik, server ngirim siji stream menyang simpul CDN, banjur jaringan nggunakake sumber daya dhewe kanggo ngirim stream iki kanggo akeh pangguna. Saka sudut pandang ekonomi, kita mung mbayar sumber daya sing dikonsumsi (bisa uga bandwidth utawa lalu lintas) lan entuk skalabilitas layanan sing apik. Nggunakake CDN kanggo ngirim konten abot pancen bener lan logis. Sanajan kudu dicathet manawa pemain paling gedhe ing papan iki (umpamane Netflix) nggawe CDN dhewe tinimbang nggunakake CDN komersial gedhe (Akamai, Cloudflare, Fastly, lsp.)

Nalika web wis berkembang, aplikasi web dhewe dadi luwih rumit lan rumit. Masalah kacepetan loading teka menyang ngarep. Penggemar kacepetan situs web kanthi cepet ngenali sawetara masalah utama sing nyebabake situs web mbukak alon. Salah sijine yaiku keterlambatan jaringan (RTT - wektu trip utawa wektu ping). Penundaan mengaruhi akeh proses ing loading situs web: nggawe sambungan TCP, miwiti sesi TLS, ngemot saben sumber daya individu (gambar, file JS, dokumen HTML, lsp.)

Masalah kasebut saya tambah amarga kasunyatane nalika nggunakake protokol HTTP / 1.1 (sadurunge munculé SPDY, QUIC lan HTTP / 2 iki mung pilihan), browser mbukak ora luwih saka 6 sambungan TCP menyang siji host. Kabeh iki nyebabake downtime sambungan lan panggunaan bandwidth saluran sing ora efisien. Masalah kasebut sebagian ditanggulangi dening sharding domain - nggawe host tambahan kanggo ngatasi watesan jumlah sambungan.

Iki ngendi kemampuan kapindho CDN katon - nyuda latensi (RTT) amarga akeh titik lan jarak simpul menyang pangguna. Jarak nduweni peran penting ing kene: kacepetan cahya diwatesi (kira-kira 200 km/detik ing serat optik). Iki tegese saben 000 km lelungan nambah 1000 ms wektu tundha utawa 5 ms kanggo RTT. Iki minangka wektu minimal sing dibutuhake kanggo transmisi, amarga ana uga telat ing peralatan penengah. Wiwit CDN biasane ngerti carane nyimpen obyek ing server, kita bisa entuk manfaat saka ngemot obyek kasebut liwat CDN. Kondisi sing dibutuhake kanggo iki: anané obyek ing cache, jarak titik CDN menyang pangguna dibandhingake karo server aplikasi web (server asal). Penting kanggo ngerti manawa jarak geografis saka simpul CDN ora njamin latensi sing sithik. Routing antarane klien lan CDN bisa dibangun ing kuwi cara sing klien bakal nyambung menyang host ing negara liya, lan bisa uga ing bawana liyane. Iki ngendi hubungan antarane operator telekomunikasi lan layanan CDN (peering, sambungan, partisipasi ing IX, etc.) lan kabijakan nuntun lalu lintas CDN dhewe. Contone, Cloudflare, nalika nggunakake rong rencana awal (gratis lan murah), ora njamin pangiriman konten saka host sing paling cedhak - host bakal dipilih kanggo entuk biaya minimal.

Akeh perusahaan Internet sing unggul narik minat umum (pangembang web lan pamilik layanan) menyang topik kacepetan loading lan kinerja situs web. Antarane perusahaan kasebut yaiku Yahoo (alat Yslow), AOL (WebPageTest) lan Google (layanan Page Speed ​​​​Insights), sing ngembangake rekomendasi dhewe kanggo nyepetake situs (utamane ana hubungane karo optimasi klien). Mengko, alat tes kacepetan situs web anyar katon, sing uga menehi tips babagan nambah kacepetan situs web. Saben layanan utawa plugin kasebut duwe rekomendasi sing konsisten: "Gunakake CDN." Pengurangan latensi jaringan biasane diarani minangka panjelasan kanggo efek CDN. Sayange, ora saben wong siap ngerti persis carane efek akselerasi CDN wis digayuh lan carane bisa diukur, supaya Rekomendasi dijupuk ing iman lan digunakake minangka postulate. Nyatane, ora kabeh CDN digawe padha.

Nggunakake CDN Dina iki

Kanggo netepake gunane nggunakake CDN, kudu diklasifikasikake. Apa sing bisa ditemokake saiki ing praktik (conto ing tanda kurung, mesthine ora lengkap):

1. CDN gratis kanggo nyebarake perpustakaan JS (MaxCDN, Google. Yandex).
2. CDN layanan kanggo optimasi klien (contone, Google Fonts kanggo fonts, Cloudinary, Cloudimage kanggo gambar).
3. CDN kanggo optimasi statis lan sumber daya ing CMS (kasedhiya ing Bitrix, WordPress lan liya-liyane).
4. Tujuan umum CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN kanggo akselerasi situs web (Cloudflare, Imperva, Airi).

Bentenane utama ing antarane jinis kasebut yaiku jumlah lalu lintas liwat CDN. Jinis 1-3 minangka pangiriman mung bagean saka konten: saka siji panyuwunan nganti pirang-pirang lusin (biasane gambar). Tipe 4 lan 5 minangka proksi lalu lintas lengkap liwat CDN.

Ing laku, iki tegese jumlah sambungan sing digunakake kanggo mbukak situs. Kanthi HTTP/2, kita nggunakake sambungan TCP siji menyang host kanggo ngolah sawetara panjaluk. Yen kita mbagi sumber daya menyang host utama (asal) lan CDN, mula perlu kanggo nyebarake panjalukan ing sawetara domain lan nggawe sawetara sambungan TCP. Kasus paling awon yaiku: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Rumus iki ora nganggep wektu tundha ing jaringan seluler kanggo ngaktifake saluran radio piranti (yen ora aktif) lan telat ing menara sel.

Mangkene apa sing katon ing grojogan loading situs (latency kanggo nyambungake menyang CDN disorot ing RTT 150 ms):

Yen CDN nyakup kabeh lalu lintas situs (kajaba layanan pihak katelu), mula kita bisa nggunakake sambungan TCP siji, ngirit wektu tundha kanggo nyambung menyang host tambahan. Mesthi, iki ditrapake kanggo sambungan HTTP / 2.

Beda liyane ditemtokake dening fungsi CDN tartamtu - kanggo jinis pisanan mung hosting file statis, kanggo kaping lima ngganti sawetara jinis isi situs kanggo tujuan optimasi.

Kapabilitas CDN kanggo akselerasi situs web

Ayo kita njlèntrèhaké sawetara lengkap Kapabilitas CDN kanggo situs nyepetake, tanpa gati kanggo fungsi saka jinis individu saka CDN, lan banjur ndeleng apa dileksanakake ing saben wong.

1. Kompresi sumber daya teks

Fitur sing paling dhasar lan bisa dingerteni, nanging asring ditindakake kanthi ora apik. Kabeh CDN nyatakake anane kompresi minangka fitur akselerasi. Nanging yen sampeyan ndeleng luwih rinci, kekurangane dadi jelas:

• derajat kurang kanggo komprèsi dinamis bisa digunakake - 5-6 (contone, kanggo gzip maksimum 9);
• kompresi statis (file ing cache) ora nggunakake fitur tambahan (contone, zopfi utawa brotli kanthi gelar 11)
• ora ana dhukungan kanggo kompresi brotli sing efisien (ngirit babagan 20% dibandhingake karo gzip).

Yen sampeyan nggunakake CDN, sampeyan kudu mriksa sawetara poin kasebut: njupuk file sing asale saka CDN, rekam ukuran sing dikompres lan kompres kanthi manual kanggo mbandhingake (sampeyan bisa nggunakake sawetara layanan online kanthi dhukungan brotli, umpamane. vsszhat.rf).

2. Nyetel header caching klien

Uga fitur nyepetake prasaja: nambah header kanggo caching isi dening klien (browser). Header paling anyar yaiku kontrol cache, sing wis kadaluwarsa. Kajaba iku, Etag bisa digunakake. Wangsulan: Bab ingkang utama iku max-umur cache-kontrol cukup gedhe (saka sasi utawa luwih) Yen sampeyan siyap kanggo cache sumber hard sabisa, sampeyan bisa nambah opsi immutable.

CDN bisa ngedhunake nilai umur maksimal, meksa pangguna luwih kerep ngisi konten statis. Ora jelas apa sing disambungake: kepinginan kanggo nambah lalu lintas ing jaringan utawa nambah kompatibilitas karo situs sing ora ngerti carane ngreset cache. Contone, wektu cache header Cloudflare standar yaiku 1 jam, sing sithik banget kanggo data statis sing ora bisa diganti.

3. Optimization gambar

Wiwit CDN njupuk fungsi caching lan porsi gambar, iku bakal logis kanggo ngoptimalake ing sisih CDN lan ngawula menyang pangguna ing wangun iki. Ayo langsung reservasi manawa fitur iki mung kasedhiya kanggo jinis CDN 2, 3 lan 5.

Sampeyan bisa ngoptimalake gambar kanthi macem-macem cara: nggunakake format kompresi canggih (kayata WebP), enkoder sing luwih efisien (MozJPEG), utawa mung ngresiki metadata sing ora perlu.

Umumé, ana rong jinis optimasi kasebut: kanthi mundhut kualitas lan tanpa mundhut kualitas. CDN biasane ngupayakake nggunakake optimasi lossless supaya bisa ngindhari keluhan pelanggan babagan owah-owahan kualitas gambar. Ing kahanan kaya mengkono, gain bakal minimal. Ing kasunyatan, asring tingkat kualitas JPEG luwih dhuwur tinimbang sing dibutuhake lan sampeyan bisa recompress kanthi aman kanthi tingkat kualitas sing luwih murah tanpa kompromi pengalaman pangguna. Ing sisih liya, angel nemtokake tingkat kualitas lan setelan sacara universal kanggo kabeh aplikasi web sing bisa ditindakake, mula CDN nggunakake setelan sing luwih konservatif dibandhingake karo sing bisa ditrapake kanthi njupuk konteks (tujuan gambar, jinis aplikasi web). , lsp.)

4. Ngoptimalake sambungan TLS

Umume lalu lintas saiki liwat sambungan TLS, tegese kita nglampahi wektu ekstra kanggo negosiasi TLS. Bubar, teknologi anyar wis dikembangake kanggo nyepetake proses iki. Contone, iki kriptografi EC, TLS 1.3, cache sesi lan tiket, akselerasi enkripsi hardware (AES-NI), etc. TLS setelan bener bisa nyuda wektu sambungan kanggo 0-1 RTT (ora ngetang DNS lan TCP ).

Kanthi piranti lunak modern, ora angel ngetrapake praktik kasebut dhewe.

Ora kabeh CDN ngetrapake praktik paling apik TLS; sampeyan bisa mriksa iki kanthi ngukur wektu sambungan TLS (contone, ing Webpagetest). Becik kanggo sambungan anyar - 1RTT, 2RTT - tingkat rata-rata, 3RTT lan liyane - ala.

Sampeyan uga kudu dicathet yen sanajan nggunakake TLS ing tingkat CDN, server karo aplikasi web kita uga kudu ngolah TLS, nanging saka sisih CDN, amarga lalu lintas antarane server lan CDN liwat jaringan umum. Ing kasus sing paling ala, kita bakal entuk tundha sambungan TLS kaping pindho (pisanan menyang host CDN, sing nomer loro ing antarane lan server kita).

Kanggo sawetara aplikasi, sampeyan kudu menehi perhatian marang masalah keamanan: lalu lintas biasane didekripsi ing simpul CDN, lan iki minangka kesempatan potensial kanggo intersepsi lalu lintas. Opsi kerja tanpa pambocoran lalu lintas biasane ditawakake ing rencana tarif ndhuwur kanthi biaya tambahan.

5. Ngurangi telat sambungan

Keuntungan utama CDN sing diomongake saben wong: latensi kurang (jarak kurang) antarane host CDN lan pangguna. Digayuh kanthi nggawe arsitektur jaringan sing disebarake sacara geografis, ing ngendi host dumunung ing titik konsentrasi pangguna (kutha, titik ijol-ijolan lalu lintas, lsp.)

Ing praktik, prioritas kanggo jaringan sing beda-beda bisa uga ana ing wilayah tartamtu. Contone, CDN Rusia bakal duwe luwih akeh titik ing Rusia. Amerika bakal pisanan ngembangake jaringan ing AS. Contone, salah siji saka CDN Cloudflare paling gedhé mung 2 poin ing Rusia - Moskow lan St. Yaiku, kita bisa ngirit maksimal sekitar 10 ms latency dibandhingake karo penempatan langsung ing Moskow.

Umume CDN Kulon ora duwe titik ing Rusia. Kanthi nyambungake, sampeyan mung bisa nambah wektu tundha kanggo pamirsa Rusia.

6. Optimasi konten (minifikasi, owah-owahan struktural)

Titik paling rumit lan teknologi maju. Ngganti isi sajrone pangiriman bisa dadi beboyo banget. Malah yen kita njupuk minification: nyuda kode sumber (amarga spasi ekstra, struktur ora penting, etc.) Bisa mengaruhi kinerja. Yen kita ngomong babagan owah-owahan sing luwih serius - mindhah kode JS menyang mburi HTML, nggabungake file, lan liya-liyane - risiko ngganggu fungsi situs kasebut luwih dhuwur.

Mulane, mung sawetara jinis 5 CDNs nindakake iki. Mesthi wae, ora bakal bisa ngotomatisasi kabeh owah-owahan sing dibutuhake kanggo nyepetake-analisa lan optimasi manual dibutuhake. Contone, mbusak kode sing ora digunakake utawa duplikat minangka tugas manual.

Minangka aturan, kabeh optimasi kasebut dikontrol dening setelan lan sing paling mbebayani dipateni kanthi standar.

Dhukungan kanggo kemampuan akselerasi miturut jinis CDN

Dadi, ayo goleki kesempatan akselerasi potensial sing diwenehake dening macem-macem jinis CDN.

Kanggo penak, kita mbaleni klasifikasi.

1. CDN gratis kanggo nyebarake perpustakaan JS (MaxCDN, Google. Yandex).
2. CDN layanan kanggo optimasi klien (contone, Google Fonts kanggo fonts, Cloudinary, Cloudimage kanggo gambar).
3. CDN kanggo optimasi statis lan sumber daya ing CMS (kasedhiya ing Bitrix, WordPress lan liya-liyane).
4. Tujuan umum CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN kanggo akselerasi situs web (Cloudflare, Imperva, Airi).

Saiki ayo mbandhingake fitur lan jinis CDN.

Opportunity
Tipe 1
Tipe 2
Tipe 3
Tipe 4
Tipe 5

Kompresi teks
+–
-
+–
+–
+

Cache header
+
+
+
+
+

Gambar
-
+–
+–
-
+

TLS
-
-
-
+–
+

telat
-
-
-
+
+

Paragraf
-
-
-
-
+

Ing tabel iki, "+" digunakake kanggo nuduhake dhukungan lengkap, "-" ora ana dhukungan, lan "+–" minangka dhukungan parsial. Mesthi, bisa uga ana panyimpangan saka tabel iki ing kasunyatan (contone, sawetara CDN tujuan umum bakal ngetrapake fitur kanggo ngoptimalake gambar), nanging kanggo gagasan umum migunani.

Hasil

Muga-muga, sawise maca artikel iki sampeyan bakal duwe gambaran sing luwih jelas babagan rekomendasi "nggunakake CDN" kanggo nyepetake situs sampeyan.

Kaya ing bisnis apa wae, sampeyan ora bisa percaya janji pemasaran layanan apa wae. Efek kasebut kudu diukur lan diuji ing kahanan nyata. Yen sampeyan wis nggunakake CDN, priksa efektifitas nggunakake kritéria sing diterangake ing artikel kasebut.

Bisa uga yen nggunakake CDN saiki bakal nyuda wektu loading situs sampeyan.

Minangka rekomendasi umum, kita bisa fokus ing ngisor iki: sinau pamirsa, nemtokake ruang lingkup geografis. Yen pamirsa utama sampeyan konsentrasi ing radius 1-2 ewu kilometer, sampeyan ora butuh CDN kanggo tujuan utama - nyuda latensi. Nanging, sampeyan bisa nyelehake server sampeyan luwih cedhak karo pangguna lan ngatur kanthi bener, entuk akeh optimasi sing diterangake ing artikel kasebut (gratis lan permanen).

Yen pamirsa sampeyan bener-bener disebarake sacara geografis (radius luwih saka 3000 kilometer), nggunakake CDN sing berkualitas pancen migunani. Nanging, sampeyan kudu ngerti luwih dhisik apa sing bisa dicepetake CDN sampeyan (ndeleng tabel kapabilitas lan katrangane). Nanging, akselerasi situs web isih tetep dadi tugas rumit sing ora bisa ditanggulangi kanthi nyambungake CDN. Saliyane optimasi ing ndhuwur, cara akselerasi sing paling efektif tetep ana ing mburi CDN: optimasi bagean server, owah-owahan lanjut ing bagean klien (mbusak kode sing ora digunakake, ngoptimalake proses rendering, nggarap konten, font, adaptasi, lsp. )

Source: www.habr.com