Сайтын хурдыг оновчтой болгох бараг бүх нийтлэл эсвэл хэрэгсэлд "CDN ашиглах" гэсэн даруухан заалт байдаг. Ерөнхийдөө CDN нь контент хүргэх сүлжээ эсвэл контент хүргэх сүлжээ юм. Метод лабораторид бид үйлчлүүлэгчдээс энэ сэдвээр байнга асуултуудтай тулгардаг; тэдний зарим нь өөрийн CDN-ээ идэвхжүүлдэг. Энэ нийтлэлийн зорилго нь CDN нь сайтыг ачаалах хурдаар юу өгч чадах, ямар асуудал үүсч болох, ямар тохиолдолд CDN ашиглах үндэслэлтэй болохыг ойлгох явдал юм.
Зураг дээр дугуйлсан саатал нь CDN ашигласнаас үүдэлтэй.
Түүх бага
Олон технологийн нэгэн адил CDN нь зайлшгүй шаардлагаас үүдэн гарч ирсэн. Интернет хэрэглэгчдийн дунд интернет суваг хөгжихийн хэрээр онлайн видео үйлчилгээ гарч ирэв. Мэдээжийн хэрэг, видео контент нь ердийн вэбсайтын контенттой (зураг, текст, CSS эсвэл JS код) харьцуулахад илүү их зурвасын өргөнийг шаарддаг.
Нэг серверээс олон үйлчлүүлэгчидтэй зэрэгцэн видео цацахыг оролдох үед серверийн интернет суваг нь гацах магадлалтай. Дүрмээр бол ердийн серверийн сувгийг бөглөхөд хэдэн мянган утас хангалттай байдаг. Мэдээжийн хэрэг, бусад нөөцийн хязгаарлалт байж болох ч тэдгээр нь одоогоор чухал биш юм. Серверийн сувгийг өргөжүүлэх нь хэтэрхий үнэтэй (заримдаа боломжгүй), бас боломжгүй байх нь чухал юм. Нэвтрүүлгийн үед суваг дээрх ачаалал нь мөчлөгтэй байх болно.
Хувь хүний серверийн сувгийг хязгаарлах асуудлыг CDN төгс шийддэг. Үйлчлүүлэгчид серверт шууд холбогддоггүй, харин CDN сүлжээний зангилаатай холбогддог. Тохиромжтой нөхцөлд сервер нь CDN зангилаа руу нэг урсгалыг илгээдэг бөгөөд дараа нь сүлжээ нь энэ урсгалыг олон хэрэглэгчдэд хүргэхийн тулд өөрийн нөөцийг ашигладаг. Эдийн засгийн үүднээс авч үзвэл, бид зөвхөн бодит хэрэглэсэн нөөцийн төлбөрийг төлдөг (энэ нь зурвасын өргөн эсвэл урсгал байж болно) бөгөөд үйлчилгээнийхээ маш сайн өргөтгөх чадварыг олж авдаг. Хүнд контентыг хүргэхийн тулд CDN ашиглах нь бүрэн үндэслэлтэй бөгөөд логик юм. Хэдийгээр энэ орон зайн хамгийн том тоглогчид (жишээ нь Netflix) томоохон арилжааны CDN (Akamai, Cloudflare, Fastly гэх мэт) ашиглахын оронд өөрсдийн CDN-ийг бүтээж байгааг тэмдэглэх нь зүйтэй.
Вэб хөгжихийн хэрээр вэб програмууд нь өөрөө илүү төвөгтэй, төвөгтэй болсон. Ачаалах хурдны асуудал гарч ирэв. Вэб сайтын хурд сонирхогчид вэб сайтыг удаан ачаалахад хүргэсэн хэд хэдэн томоохон асуудлуудыг хурдан илрүүлсэн. Үүний нэг нь сүлжээний саатал (RTT - хоёр талын аялал эсвэл пинг цаг) байв. Саатал нь вэб сайтыг ачаалах олон процесст нөлөөлдөг: TCP холболт үүсгэх, TLS сесс эхлүүлэх, эх сурвалж бүрийг ачаалах (зураг, JS файл, HTML баримт гэх мэт).
HTTP/1.1 протоколыг (SPDY, QUIC болон HTTP/2 гарч ирэхээс өмнө энэ нь цорын ганц сонголт байсан) ашиглах үед хөтчүүд нэг хост руу 6-аас илүүгүй TCP холболт нээдэг байсан нь асуудлыг улам хүндрүүлсэн. Энэ бүхэн нь холболтын тасалдал, сувгийн зурвасын өргөнийг үр ашиггүй ашиглахад хүргэсэн. Домэйн хуваах замаар асуудлыг хэсэгчлэн шийдсэн - холболтын тооны хязгаарыг даван туулах нэмэлт хостуудыг бий болгох.
Эндээс CDN-ийн хоёр дахь чадвар гарч ирдэг - олон тооны цэгүүд болон зангилаанууд хэрэглэгчтэй ойрхон байдаг тул хоцролтыг (RTT) багасгах. Энд зай нь шийдвэрлэх үүрэг гүйцэтгэдэг: гэрлийн хурд хязгаарлагдмал (оптик шилэнд ойролцоогоор 200 км / сек). Энэ нь 000 км аялал тутамд RTT-д 1000 мс саатал буюу 5 мс нэмэгдэнэ гэсэн үг. Энэ нь завсрын тоног төхөөрөмжид саатал гардаг тул дамжуулахад шаардагдах хамгийн бага хугацаа юм. CDN нь ихэвчлэн сервер дээрээ объектуудыг хэрхэн кэш хийхийг мэддэг тул CDN-ээр дамжуулан ийм объектуудыг ачаалах нь бидэнд ашигтай байдаг. Үүнд шаардлагатай нөхцөлүүд: кэш дэх объект байгаа эсэх, CDN нь вэб програмын сервертэй (эх сервер) харьцуулахад хэрэглэгчтэй ойр байх явдал юм. CDN зангилааны газарзүйн ойролцоо байгаа нь хоцролт бага байх баталгаа биш гэдгийг ойлгох нь чухал юм. Үйлчлүүлэгч болон CDN хоорондын чиглүүлэлт нь үйлчлүүлэгч өөр улс, магадгүй өөр тив дэх хосттой холбогдох байдлаар бүтээгдэж болно. Энд харилцаа холбооны операторууд болон CDN үйлчилгээний хоорондын харилцаа (peering, холболт, IX-д оролцох гэх мэт) болон CDN-ийн замын хөдөлгөөний чиглүүлэлтийн бодлого өөрөө гарч ирдэг. Жишээлбэл, Cloudflare нь хоёр анхны төлөвлөгөөг (үнэгүй, хямд) ашиглахдаа хамгийн ойрын хостоос контент хүргэх баталгаа өгөхгүй - хамгийн бага зардалд хүрэхийн тулд хостыг сонгох болно.
Олон тэргүүлэх интернет компаниуд ачаалах хурд, вэбсайтын гүйцэтгэлийн сэдвээр олон нийтийн сонирхлыг (вэб хөгжүүлэгчид болон үйлчилгээний эзэд) татдаг. Эдгээр компаниудын дунд Yahoo (Yslow хэрэгсэл), AOL (WebPageTest) болон Google (Page Speed Insights үйлчилгээ) нар сайтуудыг хурдасгах талаар өөрсдийн зөвлөмжийг боловсруулж байна (ялангуяа үйлчлүүлэгчийн оновчлолтой холбоотой). Дараа нь вэбсайтын хурдыг шалгах шинэ хэрэгслүүд гарч ирэх бөгөөд энэ нь вэбсайтын хурдыг нэмэгдүүлэх зөвлөмжийг өгдөг. Эдгээр үйлчилгээ эсвэл залгаас бүр нь "CDN ашиглах" гэсэн байнгын зөвлөмжтэй байдаг. Сүлжээний хоцрогдлын бууралтыг ихэвчлэн CDN-ийн нөлөөг тайлбарладаг. Харамсалтай нь, CDN-ийн хурдатгалын үр нөлөөг хэрхэн олж авах, түүнийг хэрхэн хэмжихийг ойлгоход хүн бүр бэлэн байдаггүй тул зөвлөмжийг итгэл үнэмшлээр авч, постулат болгон ашигладаг. Үнэн хэрэгтээ бүх CDN-үүд адилхан бүтээгддэггүй.
Өнөөдөр 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)
- үр ашигтай brotli шахалтыг дэмждэггүй (gzip-тэй харьцуулахад 20 орчим хувийг хэмнэдэг).
Хэрэв та CDN ашигладаг бол дараах хэдэн зүйлийг шалгах нь зүйтэй: CDN-ээс ирсэн файлыг авч, шахсан хэмжээг нь бичиж, харьцуулахын тулд гараар шахаарай (жишээлбэл, та brotli дэмжлэг бүхий онлайн үйлчилгээг ашиглаж болно. ).
2. Үйлчлүүлэгчийн кэшийн толгой хэсгийг тохируулах
Мөн энгийн хурдасгах функц: үйлчлүүлэгч (хөтөч) -ээр агуулгыг кэшлэхийн тулд толгой хэсгийг нэмнэ үү. Хамгийн сүүлийн гарчиг бол кэш-хяналт, хуучирсан нь хугацаа нь дууссан. Үүнээс гадна, Etag ашиглаж болно. Хамгийн гол нь кэш-хяналтын дээд нас нь хангалттай том (нэг сар ба түүнээс дээш) Хэрэв та нөөцийг аль болох хатуу кэш хийхэд бэлэн байгаа бол өөрчлөгддөггүй сонголтыг нэмж болно.
CDN нь хамгийн дээд насны утгыг бууруулж, хэрэглэгчийг статик контентыг илүү олон удаа дахин ачаалахад хүргэдэг. Энэ нь юутай холбоотой нь тодорхойгүй байна: сүлжээн дэх траффикийг нэмэгдүүлэх эсвэл кэшийг хэрхэн шинэчлэхээ мэдэхгүй сайтуудтай нийцтэй байдлыг нэмэгдүүлэх хүсэл. Жишээлбэл, 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 хост болон хэрэглэгчийн хоорондох хоцролт бага (бага зай). Газарзүйн хувьд тархсан сүлжээний архитектурыг бий болгосноор хостууд нь хэрэглэгчдийн төвлөрсөн цэгүүдэд (хот, замын хөдөлгөөн солилцох цэг гэх мэт) байрладаг.
Практикт өөр өөр сүлжээнүүдийн тэргүүлэх чиглэлүүд нь тодорхой бүс нутагт байж болно. Жишээлбэл, ОХУ-ын CDN-үүд Орост илүү олон байх болно. Америкчууд хамгийн түрүүнд АНУ-д сүлжээгээ хөгжүүлнэ. Жишээлбэл, хамгийн том CDN Cloudflare-ийн нэг нь ОХУ-д ердөө 2 оноотой байдаг - Москва, Санкт-Петербург. Өөрөөр хэлбэл, бид Москвад шууд байрлуулахтай харьцуулахад хамгийн ихдээ 10 мс хоцролтыг хэмнэж чадна.
Барууны ихэнх CDN-д Орост огт оноо байдаггүй. Тэдэнтэй холбогдсоноор та зөвхөн Оросын үзэгчдэд зориулсан саатлыг нэмэгдүүлэх боломжтой.
6. Агуулгыг оновчтой болгох (багасгах, бүтцийн өөрчлөлт)
Хамгийн төвөгтэй, технологийн дэвшилтэт цэг. Хүргэлтийн явцад агуулгыг өөрчлөх нь маш эрсдэлтэй байж болно. Хэдийгээр бид багасгахыг авч үзвэл: эх кодыг багасгах (нэмэлт зай, чухал бус бүтэц гэх мэт) нь түүний гүйцэтгэлд нөлөөлж болно. Хэрэв бид илүү ноцтой өөрчлөлтүүдийн талаар ярих юм бол - JS кодыг HTML-ийн төгсгөлд шилжүүлэх, файлуудыг нэгтгэх гэх мэт - сайтын үйл ажиллагааг тасалдуулах эрсдэл бүр ч өндөр байна.
Тиймээс зөвхөн зарим төрлийн 5 CDN үүнийг хийдэг. Мэдээжийн хэрэг, ажлыг хурдасгахад шаардлагатай бүх өөрчлөлтийг автоматжуулах боломжгүй - гар аргаар дүн шинжилгээ хийх, оновчтой болгох шаардлагатай. Жишээлбэл, ашиглагдаагүй эсвэл давхардсан кодыг устгах нь гарын авлагын ажил юм.
Дүрмээр бол ийм бүх оновчлолыг тохиргоогоор удирддаг бөгөөд хамгийн аюултай нь анхдагчаар идэвхгүй байдаг.
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 гэж бичнэ үү
2 гэж бичнэ үү
3 гэж бичнэ үү
4 гэж бичнэ үү
5 гэж бичнэ үү
Текст шахалт
+–
-
+–
+–
+
Кэш толгой
+
+
+
+
+
Зураг
-
+–
+–
-
+
TLS
-
-
-
+–
+
Саатал
-
-
-
+
+
Агуулга
-
-
-
-
+
Энэ хүснэгтэд "+" нь бүрэн дэмжлэгийг, "-" нь дэмжлэггүй, "+-" нь хэсэгчилсэн дэмжлэгийг илэрхийлэхэд ашиглагддаг. Мэдээжийн хэрэг, бодит байдал дээр энэ хүснэгтээс хазайлт байж болох юм (жишээлбэл, зарим ерөнхий зориулалтын CDN нь зургийг оновчтой болгох функцийг хэрэгжүүлэх болно), гэхдээ ерөнхий санааны хувьд энэ нь ашигтай байдаг.
Үр дүн
Энэ нийтлэлийг уншсаны дараа та сайтаа хурдасгах "CDN ашиглах" зөвлөмжийн талаар илүү тодорхой дүр зургийг олж авна гэж найдаж байна.
Аливаа бизнесийн нэгэн адил та ямар ч үйлчилгээний маркетингийн амлалтад итгэж чадахгүй. Үр нөлөөг бодит нөхцөлд хэмжиж, турших шаардлагатай. Хэрэв та аль хэдийн CDN ашиглаж байгаа бол нийтлэлд дурдсан шалгуурыг ашиглан үр дүнтэй эсэхийг шалгана уу.
Яг одоо CDN ашиглах нь таны сайтыг ачаалах хугацааг удаашруулж магадгүй юм.
Ерөнхий зөвлөмжийн хувьд бид дараахь зүйлд анхаарлаа хандуулж болно: үзэгчдийг судалж, газарзүйн хамрах хүрээг нь тодорхойлох. Хэрэв таны үндсэн үзэгчид 1-2 мянган км-ийн радиуст төвлөрч байгаа бол танд CDN гол зорилго нь хоцролтыг багасгах шаардлагагүй болно. Үүний оронд та серверээ хэрэглэгчиддээ ойртуулж, зөв тохируулж, нийтлэлд тайлбарласан ихэнх оновчлолыг (үнэгүй бөгөөд байнгын) авах боломжтой.
Хэрэв таны үзэгчид үнэхээр газарзүйн хувьд (3000 гаруй километрийн радиус) тархсан бол чанарын CDN ашиглах нь үнэхээр ашигтай байх болно. Гэсэн хэдий ч та CDN яг юу хурдасгаж болохыг урьдчилан ойлгох хэрэгтэй (чадваруудын хүснэгт, тэдгээрийн тайлбарыг үзнэ үү). Гэсэн хэдий ч вэбсайтыг хурдасгах нь CDN-ийг холбох замаар шийдвэрлэх боломжгүй төвөгтэй ажил хэвээр байна. Дээрх оновчлолуудаас гадна CDN-ийн ард хурдатгалын хамгийн үр дүнтэй хэрэгсэл хэвээр байна: серверийн хэсгийг оновчлох, үйлчлүүлэгчийн хэсэгт нэмэлт өөрчлөлт оруулах (ашиглагдаагүй кодыг устгах, үзүүлэх процессыг оновчтой болгох, агуулга, фонт, дасан зохицох чадвар гэх мэт). )
Эх сурвалж: www.habr.com