[Huwag] gumamit ng CDN

Halos bawat artikulo o tool para sa pag-optimize ng bilis ng site ay may katamtamang sugnay na "gumamit ng CDN." Sa pangkalahatan, ang CDN ay isang network ng paghahatid ng nilalaman o network ng paghahatid ng nilalaman. Kami sa Method Lab ay madalas na nakakaharap ng mga tanong mula sa mga kliyente sa paksang ito; ang ilan sa kanila ay nagpapagana ng kanilang sariling CDN. Ang layunin ng artikulong ito ay upang maunawaan kung ano ang maaaring ibigay ng isang CDN sa mga tuntunin ng bilis ng pag-load ng site, kung anong mga problema ang maaaring lumitaw, at kung saan ang mga kaso ay makatwiran ang paggamit ng isang CDN.

Ang mga pagkaantala na nakabilog sa larawan ay sanhi ng paggamit ng CDN.

Ang isang maliit na kasaysayan

Tulad ng maraming mga teknolohiya, ang mga CDN ay lumitaw dahil sa pangangailangan. Sa pagbuo ng mga channel sa Internet sa mga gumagamit ng Internet, lumitaw ang mga serbisyong online na video. Natural, ang nilalaman ng video ay nangangailangan ng mga order ng magnitude na mas maraming bandwidth kumpara sa regular na nilalaman ng website (mga larawan, teksto, at CSS o JS code).

Kapag sinusubukang i-broadcast ang isang video stream na kahanay sa maraming mga kliyente mula sa isang server, ang Internet channel ng server ay malamang na maging bottleneck. Bilang isang patakaran, ang ilang libong mga thread ay sapat na upang mabara ang isang karaniwang channel ng server. Siyempre, maaaring may iba pang mga limitasyon sa mapagkukunan, ngunit hindi ito mahalaga sa ngayon. Mahalaga rin na ang pagpapalawak ng channel ng server ay masyadong mahal (at minsan imposible), at hindi rin praktikal. Ang pag-load sa channel sa panahon ng mga broadcast ay magiging cyclical.

Ang problema ng paglilimita sa channel ng isang indibidwal na server ay perpektong nalutas ng CDN. Ang mga kliyente ay hindi direktang kumonekta sa server, ngunit sa mga node sa network ng CDN. Sa isang perpektong sitwasyon, ang server ay nagpapadala ng isang stream sa CDN node, at pagkatapos ay ang network ay gumagamit ng sarili nitong mga mapagkukunan upang maihatid ang stream na ito sa maraming mga gumagamit. Mula sa isang pang-ekonomiyang punto ng view, nagbabayad lamang kami para sa mga mapagkukunang aktwal na natupok (ito ay maaaring bandwidth o trapiko) at nakakakuha ng mahusay na scalability ng aming serbisyo. Ang paggamit ng CDN upang maghatid ng mabibigat na nilalaman ay ganap na makatwiran at lohikal. Bagama't nararapat na tandaan na ang pinakamalaking manlalaro sa espasyong ito (hal. Netflix) ay gumagawa ng sarili nilang mga CDN sa halip na gumamit ng malalaking komersyal na CDN (Akamai, Cloudflare, Fastly, atbp.)

Habang umuunlad ang web, ang mga web application mismo ay naging mas kumplikado at kumplikado. Ang problema sa bilis ng paglo-load ay dumating sa unahan. Mabilis na natukoy ng mga mahilig sa bilis ng website ang ilang pangunahing problema na naging sanhi ng mabagal na pag-load ng mga website. Isa na rito ang pagkaantala sa network (RTT - round trip time o ping time). Nakakaapekto ang mga pagkaantala sa maraming proseso sa paglo-load ng website: pagtatatag ng koneksyon sa TCP, pagsisimula ng session ng TLS, paglo-load ng bawat indibidwal na mapagkukunan (larawan, JS file, HTML na dokumento, atbp.)

Ang problema ay pinalubha ng katotohanan na kapag gumagamit ng HTTP/1.1 protocol (bago ang pagdating ng SPDY, QUIC at HTTP/2 ito ang tanging opsyon), ang mga browser ay nagbubukas ng hindi hihigit sa 6 na koneksyon sa TCP sa isang host. Ang lahat ng ito ay humantong sa downtime ng koneksyon at hindi mahusay na paggamit ng bandwidth ng channel. Ang problema ay bahagyang nalutas sa pamamagitan ng domain sharding - ang paglikha ng mga karagdagang host upang malampasan ang limitasyon sa bilang ng mga koneksyon.

Dito lumalabas ang pangalawang kakayahan ng CDN - pagbabawas ng latency (RTT) dahil sa malaking bilang ng mga puntos at ang lapit ng mga node sa user. Ang distansya ay gumaganap ng isang mapagpasyang papel dito: ang bilis ng liwanag ay limitado (mga 200 km/sec sa optical fiber). Nangangahulugan ito na ang bawat 000 km ng paglalakbay ay nagdaragdag ng 1000 ms ng pagkaantala o 5 ms sa RTT. Ito ang minimum na oras na kinakailangan para sa paghahatid, dahil mayroon ding mga pagkaantala sa intermediate na kagamitan. Dahil karaniwang alam ng isang CDN kung paano mag-cache ng mga bagay sa mga server nito, maaari tayong makinabang sa paglo-load ng mga naturang bagay sa pamamagitan ng isang CDN. Mga kinakailangang kondisyon para dito: ang pagkakaroon ng bagay sa cache, ang kalapitan ng CDN ay tumuturo sa user kumpara sa web application server (origin server). Mahalagang maunawaan na ang geographic proximity ng isang CDN node ay hindi ginagarantiyahan ang mababang latency. Ang pagruruta sa pagitan ng kliyente at ng CDN ay maaaring itayo sa paraang kumonekta ang kliyente sa isang host sa ibang bansa, at posibleng sa ibang kontinente. Dito pumapasok ang ugnayan sa pagitan ng mga operator ng telecom at ng serbisyo ng CDN (peering, mga koneksyon, paglahok sa IX, atbp.) at ang patakaran sa pagruruta ng trapiko ng CDN mismo. Halimbawa, ang Cloudflare, kapag gumagamit ng dalawang paunang plano (libre at mura), ay hindi ginagarantiyahan ang paghahatid ng nilalaman mula sa pinakamalapit na host - ang host ay pipiliin upang makamit ang pinakamababang gastos.

Maraming nangungunang kumpanya sa Internet ang nakakaakit ng interes ng publiko (mga web developer at may-ari ng serbisyo) sa paksa ng bilis ng pag-load at pagganap ng website. Kabilang sa mga kumpanyang ito ay ang Yahoo (Yslow tool), AOL (WebPageTest) at Google (Page Speed ​​​​Insights service), na gumagawa ng sarili nilang mga rekomendasyon para sa pagpapabilis ng mga site (pangunahing nauugnay ang mga ito sa pag-optimize ng kliyente). Sa ibang pagkakataon, lalabas ang mga bagong tool sa pagsubok ng bilis ng website, na nagbibigay din ng mga tip sa pagpapataas ng bilis ng website. Ang bawat isa sa mga serbisyo o plugin na ito ay may pare-parehong rekomendasyon: "Gumamit ng CDN." Ang pagbawas sa latency ng network ay karaniwang binabanggit bilang paliwanag para sa epekto ng CDN. Sa kasamaang palad, hindi lahat ay handa na maunawaan nang eksakto kung paano nakakamit ang acceleration effect ng CDN at kung paano ito masusukat, kaya ang rekomendasyon ay kinuha sa pananampalataya at ginamit bilang isang postulate. Sa katunayan, hindi lahat ng CDN ay nilikhang pantay.

Gamit ang CDN Ngayon

Upang masuri ang pagiging kapaki-pakinabang ng paggamit ng mga CDN, kailangan nilang maiuri. Ano ang makikita ngayon sa pagsasanay (ang mga halimbawa sa mga bracket ay, siyempre, hindi kumpleto):

1. Libreng CDN para sa pamamahagi ng mga aklatan ng JS (MaxCDN, Google. Yandex).
2. CDN ng mga serbisyo para sa pag-optimize ng kliyente (halimbawa, Google Fonts para sa mga font, Cloudinary, Cloudimage para sa mga larawan).
3. CDN para sa static at resource optimization sa CMS (available sa Bitrix, WordPress at iba pa).
4. Pangkalahatang layunin CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN para sa acceleration ng website (Cloudflare, Imperva, Airi).

Ang pangunahing pagkakaiba sa pagitan ng mga uri na ito ay kung gaano karami ng trapiko ang dumadaan sa CDN. Ang mga uri 1-3 ay ang paghahatid ng bahagi lamang ng nilalaman: mula sa isang kahilingan hanggang sa ilang dosena (karaniwan ay mga larawan). Ang mga uri 4 at 5 ay ganap na pag-proxy ng trapiko sa pamamagitan ng CDN.

Sa pagsasagawa, nangangahulugan ito ng bilang ng mga koneksyon na ginagamit upang i-load ang site. Sa HTTP/2, gumagamit kami ng isang koneksyon sa TCP sa host para iproseso ang anumang bilang ng mga kahilingan. Kung hahatiin natin ang mga mapagkukunan sa pangunahing host (pinagmulan) at CDN, kinakailangan na ipamahagi ang mga kahilingan sa ilang domain at lumikha ng ilang koneksyon sa TCP. Ang pinakamasamang kaso ay: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. Hindi isinasaalang-alang ng formula na ito ang mga pagkaantala sa mga mobile network para sa pag-activate ng channel ng radyo ng device (kung hindi ito aktibo) at mga pagkaantala sa cell tower.

Narito kung ano ang hitsura nito sa naglo-load na waterfall ng site (ang mga latency para sa pagkonekta sa CDN ay naka-highlight sa RTT 150 ms):

Kung saklaw ng CDN ang lahat ng trapiko sa site (maliban sa mga serbisyo ng third-party), maaari kaming gumamit ng isang koneksyon sa TCP, na nakakatipid ng mga pagkaantala sa pagkonekta sa mga karagdagang host. Siyempre, nalalapat ito sa mga koneksyon sa HTTP/2.

Ang mga karagdagang pagkakaiba ay tinutukoy ng functionality ng isang partikular na CDN - para sa unang uri ay nagho-host lang ito ng isang static na file, para sa ikalima ay binabago nito ang ilang uri ng nilalaman ng site para sa layunin ng pag-optimize.

Mga kakayahan ng CDN para sa acceleration ng website

Ilarawan natin ang buong hanay ng mga kakayahan ng CDN para sa pagpapabilis ng mga site, nang hindi isinasaalang-alang ang paggana ng mga indibidwal na uri ng CDN, at pagkatapos ay tingnan kung ano ang ipinatupad sa bawat isa sa kanila.

1. Pag-compress ng mga mapagkukunan ng teksto

Ang pinakapangunahing at nauunawaan na tampok, ngunit madalas na hindi maganda ang pagpapatupad. Ang lahat ng mga CDN ay nagdedeklara ng pagkakaroon ng compression bilang kanilang tampok na acceleration. Ngunit kung titingnan mo nang mas detalyado, ang mga pagkukulang ay nagiging malinaw:

• mababang degree para sa dynamic na compression ay maaaring gamitin - 5-6 (halimbawa, para sa gzip ang maximum ay 9);
• ang static compression (mga file sa cache) ay hindi gumagamit ng mga karagdagang feature (halimbawa, zopfi o brotli na may degree 11)
• walang suporta para sa mahusay na brotli compression (nagtitipid ng humigit-kumulang 20% ​​kumpara sa gzip).

Kung gumagamit ka ng CDN, sulit na suriin ang ilang mga puntong ito: kunin ang file na nagmula sa CDN, itala ang naka-compress na laki nito at manu-manong i-compress ito para sa paghahambing (maaari kang gumamit ng ilang online na serbisyo na may suporta sa brotli, halimbawa vsszhat.rf).

2. Pagtatakda ng mga header ng pag-cache ng kliyente

Isa ring simpleng tampok na pagpapabilis: magdagdag ng mga header para sa pag-cache ng nilalaman ng kliyente (browser). Ang pinakakasalukuyang header ay cache-control, ang hindi napapanahon ay mag-e-expire. Bukod pa rito, maaaring gamitin ang Etag. Ang pangunahing bagay ay ang max-age ng cache-control ay sapat na malaki (mula sa isang buwan o higit pa). Kung handa ka nang i-cache ang mapagkukunan hangga't maaari, maaari mong idagdag ang hindi nababagong opsyon.

Maaaring babaan ng mga CDN ang halaga ng max-age, na pinipilit ang user na i-reload nang mas madalas ang static na content. Hindi malinaw kung ano ang nauugnay dito: ang pagnanais na dagdagan ang trapiko sa network o dagdagan ang pagiging tugma sa mga site na hindi alam kung paano i-reset ang cache. Halimbawa, ang default na Cloudflare header cache time ay 1 oras, na napakababa para sa hindi nababagong static na data.

3. Pag-optimize ng imahe

Dahil ang CDN ay tumatagal ng mga function ng pag-cache at paghahatid ng mga imahe, magiging lohikal na i-optimize ang mga ito sa gilid ng CDN at ihatid ang mga ito sa mga user sa form na ito. Magpareserba tayo kaagad na ang feature na ito ay available lang para sa mga uri ng CDN 2, 3 at 5.

Maaari mong i-optimize ang mga larawan sa iba't ibang paraan: gamit ang mga advanced na format ng compression (gaya ng WebP), mas mahusay na mga encoder (MozJPEG), o simpleng paglilinis ng hindi kinakailangang metadata.

Sa pangkalahatan, mayroong dalawang uri ng naturang mga pag-optimize: na may pagkawala ng kalidad at walang pagkawala ng kalidad. Karaniwang nagsusumikap ang mga CDN na gumamit ng lossless optimization upang maiwasan ang mga posibleng reklamo ng customer tungkol sa mga pagbabago sa kalidad ng imahe. Sa ganitong mga kondisyon, ang pakinabang ay magiging minimal. Sa totoo lang, kadalasan ang antas ng kalidad ng JPEG ay mas mataas kaysa sa kinakailangan at maaari mong ligtas na mag-recompress na may mas mababang antas ng kalidad nang hindi nakompromiso ang karanasan ng user. Sa kabilang banda, mahirap matukoy ang antas ng kalidad at mga setting sa pangkalahatan para sa lahat ng posibleng mga web application, kaya ang mga CDN ay gumagamit ng mas konserbatibong mga setting kumpara sa mga maaaring ilapat na isinasaalang-alang ang konteksto (layunin ng mga larawan, uri ng web application , atbp.)

4. Pag-optimize ng koneksyon sa TLS

Karamihan sa trapiko ngayon ay naglalakbay sa mga koneksyon sa TLS, na nangangahulugang gumugugol kami ng karagdagang oras sa pakikipag-usap sa TLS. Kamakailan lamang, ang mga bagong teknolohiya ay binuo upang mapabilis ang prosesong ito. Halimbawa, ito ay EC cryptography, TLS 1.3, session cache at mga tiket, hardware encryption acceleration (AES-NI), atbp. Ang tamang pagtatakda ng TLS ay maaaring mabawasan ang oras ng koneksyon sa 0-1 RTT (hindi binibilang ang DNS at TCP ).

Sa makabagong software, hindi mahirap ipatupad ang gayong mga kasanayan nang mag-isa.

Hindi lahat ng CDN ay nagpapatupad ng pinakamahuhusay na kagawian sa TLS; maaari mong suriin ito sa pamamagitan ng pagsukat sa oras ng koneksyon ng TLS (halimbawa, sa Webpagetest). Tamang-tama para sa isang bagong koneksyon - 1RTT, 2RTT - average na antas, 3RTT at higit pa - masama.

Dapat ding tandaan na kahit na gumagamit ng TLS sa antas ng CDN, ang server na may aming web application ay dapat ding magproseso ng TLS, ngunit mula sa bahagi ng CDN, dahil ang trapiko sa pagitan ng server at CDN ay dumadaan sa pampublikong network. Sa pinakamasamang kaso, makakakuha tayo ng dobleng pagkaantala sa koneksyon ng TLS (ang una sa host ng CDN, ang pangalawa sa pagitan nito at ng aming server).

Para sa ilang mga application, ito ay nagkakahalaga ng pagbibigay pansin sa mga isyu sa seguridad: ang trapiko ay karaniwang decrypted sa CDN node, at ito ay isang potensyal na pagkakataon para sa traffic interception. Ang opsyon ng pagtatrabaho nang walang pagsisiwalat sa trapiko ay karaniwang inaalok sa mga nangungunang plano ng taripa para sa karagdagang bayad.

5. Bawasan ang pagkaantala ng koneksyon

Ang pangunahing benepisyo ng CDN na pinag-uusapan ng lahat: mababang latency (mas kaunting distansya) sa pagitan ng host ng CDN at ng user. Nakamit sa pamamagitan ng paglikha ng isang geographically distributed network architecture, kung saan ang mga host ay matatagpuan sa mga punto ng konsentrasyon ng mga user (mga lungsod, traffic exchange point, atbp.)

Sa pagsasagawa, ang mga priyoridad para sa iba't ibang network ay maaaring nasa mga partikular na rehiyon. Halimbawa, ang mga Russian CDN ay magkakaroon ng higit pang mga punto ng presensya sa Russia. Ang mga Amerikano ay una sa lahat bubuo ng network sa USA. Halimbawa, ang isa sa pinakamalaking CDN Cloudflare ay may 2 puntos lamang sa Russia - Moscow at St. Ibig sabihin, makakatipid tayo ng maximum na humigit-kumulang 10 ms ng latency kumpara sa direktang paglalagay sa Moscow.

Karamihan sa mga Western CDN ay walang mga puntos sa Russia. Sa pamamagitan ng pagkonekta sa kanila, maaari mo lamang taasan ang mga pagkaantala para sa iyong Russian audience.

6. Pag-optimize ng nilalaman (minification, mga pagbabago sa istruktura)

Ang pinaka-kumplikado at teknolohikal na advanced na punto. Ang pagbabago ng nilalaman sa panahon ng paghahatid ay maaaring maging lubhang mapanganib. Kahit na kumuha kami ng minification: ang pagbabawas ng source code (dahil sa mga dagdag na espasyo, hindi mahalagang istruktura, atbp.) ay maaaring makaapekto sa pagganap nito. Kung pag-uusapan natin ang tungkol sa mas malubhang pagbabago - ang paglipat ng JS code sa dulo ng HTML, pagsasama-sama ng mga file, atbp. - ang panganib na maabala ang paggana ng site ay mas mataas.

Samakatuwid, ilang uri lamang ng 5 CDN ang gumagawa nito. Siyempre, hindi posibleng i-automate ang lahat ng pagbabagong kailangan para mapabilis ang mga bagay—kailangan ang manual na pagsusuri at pag-optimize. Halimbawa, ang pag-alis ng hindi nagamit o duplicate na code ay isang manu-manong gawain.

Bilang isang patakaran, ang lahat ng naturang pag-optimize ay kinokontrol ng mga setting at ang mga pinaka-mapanganib ay hindi pinagana bilang default.

Suporta para sa mga kakayahan sa pagpabilis ayon sa uri ng CDN

Kaya tingnan natin kung ano ang mga potensyal na pagkakataon sa pagpapabilis na ibinibigay ng iba't ibang uri ng mga CDN.

Para sa kaginhawahan, inuulit namin ang pag-uuri.

1. Libreng CDN para sa pamamahagi ng mga aklatan ng JS (MaxCDN, Google. Yandex).
2. CDN ng mga serbisyo para sa pag-optimize ng kliyente (halimbawa, Google Fonts para sa mga font, Cloudinary, Cloudimage para sa mga larawan).
3. CDN para sa static at resource optimization sa CMS (available sa Bitrix, WordPress at iba pa).
4. Pangkalahatang layunin CDN (StackPath, CDNVideo, NGENIX, Megafon).
5. CDN para sa acceleration ng website (Cloudflare, Imperva, Airi).

Ngayon ihambing natin ang mga tampok at uri ng CDN.

Pagkakataon
Uri 1
Uri 2
Uri 3
Uri 4
Uri 5

Pag-compress ng teksto
+–
-
+–
+–
+

Mga header ng cache
+
+
+
+
+

Mga larawan
-
+–
+–
-
+

TLS
-
-
-
+–
+

Mga pagkaantala
-
-
-
+
+

Nilalaman
-
-
-
-
+

Sa talahanayang ito, ang "+" ay ginagamit upang ipahiwatig ang buong suporta, "–" ay walang suporta, at "+–" ay bahagyang suporta. Siyempre, maaaring may mga paglihis mula sa talahanayang ito sa katotohanan (halimbawa, ang ilang pangkalahatang layunin na CDN ay magpapatupad ng mga tampok para sa pag-optimize ng mga larawan), ngunit para sa pangkalahatang ideya ito ay kapaki-pakinabang.

Mga resulta ng

Sana, pagkatapos basahin ang artikulong ito ay magkakaroon ka ng mas malinaw na larawan tungkol sa rekomendasyong "gumamit ng CDN" upang mapabilis ang iyong mga site.

Tulad ng sa anumang negosyo, hindi ka makapaniwala sa mga pangako sa marketing ng anumang serbisyo. Ang epekto ay kailangang masukat at masuri sa ilalim ng tunay na mga kondisyon. Kung gumagamit ka na ng CDN, suriin ito para sa pagiging epektibo gamit ang pamantayang inilarawan sa artikulo.

Posible na ang paggamit ng CDN sa ngayon ay nagpapabagal sa oras ng paglo-load ng iyong site.

Bilang pangkalahatang rekomendasyon, maaari tayong tumuon sa mga sumusunod: pag-aralan ang iyong madla, tukuyin ang heyograpikong saklaw nito. Kung ang iyong pangunahing madla ay puro sa loob ng radius na 1-2 libong kilometro, hindi mo kailangan ng CDN para sa pangunahing layunin nito - pagbabawas ng latency. Sa halip, maaari mong ilagay ang iyong server nang mas malapit sa iyong mga user at i-configure ito nang maayos, makuha ang karamihan sa mga pag-optimize na inilarawan sa artikulo (libre at permanente).

Kung sakaling ang iyong madla ay tunay na nahahati sa heograpiya (radius na higit sa 3000 kilometro), ang paggamit ng de-kalidad na CDN ay talagang magiging kapaki-pakinabang. Gayunpaman, kailangan mong maunawaan nang maaga kung ano ang eksaktong mapabilis ng iyong CDN (tingnan ang talahanayan ng mga kakayahan at ang kanilang paglalarawan). Gayunpaman, ang pagbilis ng website ay nananatiling isang kumplikadong gawain na hindi malulutas sa pamamagitan ng pagkonekta ng CDN. Bilang karagdagan sa mga pag-optimize sa itaas, ang pinakaepektibong paraan ng acceleration ay nananatili sa likod ng CDN: pag-optimize ng bahagi ng server, mga advanced na pagbabago sa bahagi ng kliyente (pag-aalis ng hindi nagamit na code, pag-optimize sa proseso ng pag-render, pagtatrabaho sa nilalaman, mga font, kakayahang umangkop, atbp. )

Pinagmulan: www.habr.com