Сүүлийн жилүүдэд урд талын төслүүдийг оновчтой болгох олон платформууд гуравдагч этгээдийн нөөцийг өөрөө байршуулах эсвэл прокси хийх боломжийг санал болгож байна. Акамай танд тохируулах боломжийг олгодог өөрөө үүсгэсэн URL-д зориулсан. Cloudflare нь Edge Workers технологитой. Fasterzine чадна Хуудас дээрх URL-ууд нь сайтын үндсэн домайн дээр байрлах гуравдагч талын эх сурвалжуудыг заадаг.
Хэрэв таны төсөлд хэрэглэгдэж буй гуравдагч талын үйлчилгээнүүд тийм ч их өөрчлөгддөггүй бөгөөд тэдгээрийг үйлчлүүлэгчдэд хүргэх үйл явцыг сайжруулах боломжтой гэдгийг мэдэж байгаа бол ийм үйлчилгээг прокси хийх талаар бодож байгаа байх. Энэхүү аргын тусламжтайгаар та эдгээр нөөцийг хэрэглэгчдэдээ ойртуулж, үйлчлүүлэгчийн тал дээр тэдний кэшийг бүрэн хянах боломжтой болно. Үүнээс гадна, гуравдагч этгээдийн үйлчилгээний "уналт" эсвэл түүний гүйцэтгэлийн доройтлоос үүдэлтэй бэрхшээлээс хэрэглэгчдийг хамгаалах боломжийг танд олгоно.
Сайн: Гүйцэтгэл сайжирсан
Өөр хэн нэгний нөөцийг өөрөө байршуулах нь гүйцэтгэлийг маш тодорхой байдлаар сайжруулдаг. Хөтөч нь DNS-д дахин хандах шаардлагагүй, TCP холболт үүсгэж, гуравдагч этгээдийн домэйн дээр TLS гар барих шаардлагагүй. Өөр хэн нэгний нөөцийг өөрөө байршуулах нь гүйцэтгэлд хэрхэн нөлөөлж байгааг дараах хоёр тоогоор харьцуулан харж болно.
Гуравдагч талын эх сурвалжуудыг гадны эх сурвалжаас татаж авдаг ( )
Гуравдагч этгээдийн нөөцийг сайтын бусад материалтай ижил газар хадгалдаг ( )
Хөтөч нь үндсэн домэйнтэй аль хэдийн тогтоогдсон HTTP/2 холболтоос өгөгдлийг олон талт болгох, эрэмбэлэх чадварыг ашиглах болсноор нөхцөл байдал сайжирсан.
Хэрэв та гуравдагч талын нөөцийг байршуулаагүй бол тэдгээрийг үндсэн эх сурвалжаас өөр домэйноос ачаалах тул тэдгээрийг эрэмбэлэх боломжгүй. Энэ нь үйлчлүүлэгчийн зурвасын өргөнийг хооронд нь өрсөлдөхөд хүргэнэ. Энэ нь хуудас бүтээхэд чухал ач холбогдолтой контентыг ачаалах хугацааг хамгийн тохиромжтой нөхцөлд хүрэхээс хамаагүй урт болгож болзошгүй юм. Энэ бүхнийг маш сайн тайлбарласан HTTP/2-ын тэргүүлэх чиглэлийн талаар ярилц.
Гадны эх сурвалжтай холбоход шинж чанаруудыг ашигладаг гэж үзэж болно preconnect асуудлыг шийдвэрлэхэд туслах болно. Гэсэн хэдий ч, хэрэв эдгээр холбоосууд нь өөр өөр домэйн руу хэт олон байвал энэ нь хамгийн чухал мөчид харилцаа холбооны шугамыг хэт ачааллахад хүргэдэг.
Хэрэв та гуравдагч талын нөөцийг өөрөө байршуулж байгаа бол эдгээр нөөцийг үйлчлүүлэгчид яг хэрхэн өгч байгааг хянах боломжтой. Тухайлбал, бид дараахь зүйлийг ярьж байна.
- Та хөтөч бүрт хамгийн сайн тохирох өгөгдөл шахах алгоритмыг (Brotli/gzip) ашиглаж байгаа эсэхийг баталгаажуулж болно.
- Та хамгийн алдартай үйлчилгээ үзүүлэгчтэй байсан ч гэсэн ихэвчлэн тийм ч урт биш нөөцийг кэшлэх хугацааг нэмэгдүүлэх боломжтой (жишээлбэл, GA шошгоны харгалзах утгыг 30 минутаар тохируулсан).
Та холбогдох агуулгыг кэшийн удирдлагын стратегид (URL хэш, хувилбар гаргах гэх мэт) оруулснаар нөөцийн TTL-ийг нэг жилээр сунгаж болно. Энэ талаар бид доор ярих болно.
▍Гуравдагч этгээдийн үйлчилгээний үйл ажиллагааг тасалдуулах, эсвэл унтраахаас хамгаалах
Гуравдагч этгээдийн нөөцийг өөрөө байршуулах өөр нэг сонирхолтой тал бол энэ нь гуравдагч талын үйлчилгээний тасалдалтай холбоотой эрсдлийг бууруулах боломжийг олгодог явдал юм. Таны ашиглаж буй гуравдагч талын A/B тестийн шийдлийг хуудасны толгой хэсэгт ачаалах блоклох скрипт хэлбэрээр хэрэгжүүлсэн гэж бодъё. Энэ скрипт удаан ачаалагддаг. Хэрэв холбогдох скрипт ачаалагдахгүй бол хуудас хоосон болно. Хэрэв ачаалахад маш их хугацаа шаардагдах бол хуудас удаан саатал гарч ирнэ. Эсвэл уг төсөл нь гуравдагч талын CDN эх сурвалжаас татаж авсан номын санг ашигладаг гэж бодъё. Энэ нөөц бүтэлгүйтсэн эсвэл тодорхой улсад хаагдсан гэж төсөөлөөд үз дээ. Ийм нөхцөл байдал нь сайтын логикийг зөрчихөд хүргэнэ.
Зарим гадны үйлчилгээ байхгүй үед таны сайт хэрхэн ажилладагийг мэдэхийн тулд та SPOF хэсгийг ашиглаж болно .
webpagetest.org дээрх SPOF хэсэг
▍Хөтөч дээр материалыг кэшлэхтэй холбоотой асуудлуудыг яах вэ? (санамж: энэ бол домог)
Эдгээр үйлчилгээ нь нэлээд өндөр чанартай сүлжээтэй бөгөөд дэлхий даяар тархсан байдаг тул нийтийн CDN-г ашиглах нь нөөцийн гүйцэтгэлийг автоматаар сайжруулна гэж бодож магадгүй юм. Гэхдээ үнэндээ бүх зүйл арай илүү төвөгтэй байдаг.
Бидэнд вэбсайт1.com, website2.com, website3.com гэсэн хэд хэдэн өөр сайт байна гэж бодъё. Эдгээр бүх сайтууд jQuery номын санг ашигладаг. Бид үүнийг CDN ашиглан тэдэнтэй холбодог, жишээлбэл - googleapis.com. Та хөтчөөс номын санг нэг удаа татаж аваад кэш хийж, дараа нь бүх гурван сайтад ашиглах боломжтой. Энэ нь сүлжээн дэх ачааллыг бууруулж чадна. Магадгүй энэ нь танд мөнгө хэмнэх боломжийг олгож, нөөцийн гүйцэтгэлийг сайжруулахад туслах болно. Практик талаас нь харахад бүх зүйл өөр харагдаж байна. Жишээлбэл, Safari нь функцтэй байдаг : Кэш нь баримт бичгийн эх сурвалж болон гуравдагч талын нөөцийн эх сурвалж дээр тулгуурлан давхар түлхүүрүүдийг ашигладаг. энэ сэдвээр сайн нийтлэл.
хуучин судалгаа и , түүнчлэн сүүлийн үеийн Пол Кальвано, нөөцүүд нь бидний хүлээж байгаа шиг хөтчийн кэшэд хадгалагддаггүйг харуулж байна: "Төслийн өөрийн болон гуравдагч этгээдийн нөөцийг кэшлэх хугацааны хооронд ноцтой зөрүү байна. Бид CSS болон вэб фонтуудын тухай ярьж байна. Тухайлбал, уугуул фонтуудын 95% нь долоо хоногоос дээш кэш хадгалах хугацаатай байдаг бол гуравдагч талын фонтуудын 50% нь долоо хоногоос бага хугацаатай байдаг! Энэ нь вэб хөгжүүлэгчдэд фонтын файлуудыг өөрсдөө байршуулах үндэслэлийг өгдөг!"
Үүний үр дүнд, хэрэв та бусад хүмүүсийн агуулгыг байршуулах юм бол хөтчийн кэшээс үүссэн гүйцэтгэлийн ямар ч асуудал анзаарагдахгүй.
Одоо бид гуравдагч этгээдийн өөрийгөө байршуулах давуу талуудыг авч үзсэнийхээ дараа энэ хандлагыг сайн хэрэгжүүлэхийг муугаас хэрхэн ялгах талаар ярилцъя.
Муу: Чөтгөр нарийн ширийн зүйлд байдаг
Гуравдагч этгээдийн нөөцийг өөрийн домэйнд шилжүүлэх нь ийм нөөцийг зохих ёсоор хадгалсан эсэхийг баталгаажуулахгүйгээр автоматаар хийх боломжгүй юм.
Энд байгаа гол бэрхшээлүүдийн нэг бол кэш хийх хугацаа юм. Жишээлбэл, хувилбарын мэдээллийг гуравдагч этгээдийн скриптийн нэрэнд дараах байдлаар оруулсан болно: jquery-3.4.1.js. Ийм файл ирээдүйд өөрчлөгдөхгүй бөгөөд үүний үр дүнд энэ нь кэш хийхэд ямар ч асуудал үүсгэхгүй.
Гэхдээ файлтай ажиллахдаа зарим хувилбарын схемийг ашиглаагүй бол файлын нэр өөрчлөгдөөгүй байхад агуулга нь өөрчлөгддөг кэш скриптүүд хуучирч магадгүй юм. Энэ нь жишээлбэл, үйлчлүүлэгчид аль болох хурдан хүлээн авах шаардлагатай скриптүүдэд аюулгүй байдлын автомат засваруудыг нэмэхийг зөвшөөрдөггүй тул энэ нь ноцтой асуудал байж болох юм. Хөгжүүлэгч нь кэш дэх ийм скриптүүдийг шинэчлэхийн тулд хүчин чармайлт гаргах шаардлагатай болно. Нэмж дурдахад, энэ нь кэшээс клиент дээр ашигласан код нь төслийн серверийн хэсгийг боловсруулсан кодын хамгийн сүүлийн хувилбараас ялгаатай тул програмын доголдол үүсгэж болзошгүй юм.
Хэрэв бид байнга шинэчлэгддэг материалын талаар ярих юм бол (шошго менежерүүд, A / B тестийн шийдлүүд) CDN хэрэгслийг ашиглан кэш хийх нь шийдэж болох ажил боловч илүү төвөгтэй ажил юм. Тагийн удирдлагын шийдэл болох Commanders Act зэрэг үйлчилгээнүүд шинэ хувилбаруудыг нийтлэхдээ вэб дэгээг ашигладаг. Энэ нь танд CDN дээр кэшийг хүчээр зайлах, эсвэл илүү сайн нь хэш эсвэл URL шинэчлэлтийг хүчээр хийх боломжийг олгоно.
▍Материалыг үйлчлүүлэгчдэд тохируулан хүргэх
Нэмж дурдахад бид кэш хийх талаар ярихдаа CDN дээр ашигласан кэшийн тохиргоо нь зарим гуравдагч талын нөөцөд тохиромжгүй байж магадгүй гэдгийг анхаарч үзэх хэрэгтэй. Жишээлбэл, ийм нөөцүүд нь тухайн хөтчүүдэд тусгайлан тохируулсан агуулгын хувилбар бүхий тодорхой хөтчүүдэд үйлчлэхийн тулд хэрэглэгчийн агент үнэрлэх (дасан зохицох үйлчилгээ) технологийг ашиглаж болно. Эдгээр технологиуд нь хөтчийн чадавхийг тодорхойлохын тулд ердийн илэрхийлэл буюу HTTP толгойн мэдээллийн санд тулгуурладаг. User-Agent. Тэд аль хөтөчтэй харьцаж байгаагаа мэдсэний дараа түүнд зориулагдсан материалыг өгдөг.
Энд та хоёр үйлчилгээг санаж болно. Эхнийх нь googlefonts.com юм. Хоёр дахь нь polyfill.io юм. Google Fonts үйлчилгээ нь тодорхой нөөцөд зориулж хөтчийн чадвараас хамааран янз бүрийн CSS кодоор хангадаг (woff2 эх сурвалжийг ашиглан холбоосыг өгдөг. unicode-range).
Энд янз бүрийн хөтчөөс хийсэн Google Фонтын хэд хэдэн асуултын үр дүн байна.
Chrome-ын Google Fonts асуулгын үр дүн
IE10-с гүйцэтгэсэн Google Fonts асуулгын үр дүн
Polyfill.io нь хөтөчдөө зөвхөн шаардлагатай полифиллийг өгдөг. Үүнийг гүйцэтгэлийн шалтгаанаар хийдэг.
Жишээлбэл, хэрэв та өөр өөр хөтөчөөс дараах хүсэлтийг ажиллуулбал юу болохыг харцгаая.
IE10-аас гүйцэтгэсэн ийм хүсэлтийн хариуд 34 KB өгөгдлийг хүлээн авах болно. Chrome-ээс гаргасан хариулт нь хоосон байх болно.
Ууртай: Хувийн нууцад анхаарах зүйлс
Энэ цэг нь дарааллын сүүлчийнх боловч чухал биш юм. Гол санаа нь төслийн үндсэн домэйн эсвэл түүний дэд домайн дээр гуравдагч этгээдийн нөөцийг өөрөө байршуулах нь хэрэглэгчдийн нууцлалыг алдагдуулж, үндсэн вэб төсөлд сөргөөр нөлөөлж болзошгүй юм.
Хэрэв таны CDN систем зөв тохируулагдаагүй бол та өөрийн домэйны күүкиг гуравдагч талын үйлчилгээ рүү илгээж болзошгүй. Хэрэв CDN түвшинд зохих шүүлтүүрийг зохион байгуулаагүй бол JavaScript-д ихэвчлэн ашиглах боломжгүй сесс күүкиг ( httponly), гадаадын хост руу илгээж болно.
Eulerian эсвэл Criteo гэх мэт трекерүүдэд яг ийм зүйл тохиолдож болно. Гуравдагч талын мөрдөгчид күүкид өвөрмөц танигч тохируулсан байж болзошгүй. Хэрэв тэд сайтын материалын нэг хэсэг байсан бол хэрэглэгч өөр өөр вэб эх сурвалжтай ажиллаж байх үед танигчийг өөрийн үзэмжээр уншиж болно.
Өнөө үед ихэнх хөтчүүд энэ төрлийн трекерийн үйлдлээс хамгаалах хамгаалалтыг агуулдаг. Үүний үр дүнд одоо мөрдөгчид технологи ашигладаг , янз бүрийн төслүүдэд зориулж өөрийн гэсэн скрипт мэт далдлах. Тухайлбал, трекерүүд сайт эзэмшигчдэд тодорхой домэйны тохиргоондоо CNAME нэмэхийг санал болгодог бөгөөд хаяг нь ихэвчлэн санамсаргүй тэмдэгт шиг харагддаг.
Хэдийгээр вэбсайтын күүкиг бүх дэд домайнуудад ашиглахыг зөвлөдөггүй (жишээлбэл - *.website.com) олон сайтууд үүнийг хийдэг. Энэ тохиолдолд ийм күүки автоматаар далдлагдсан гуравдагч этгээдийн мөрдөгч рүү илгээгдэнэ. Үүний үр дүнд бид хувийн нууцын талаар ярих боломжгүй болсон.
Мөн HTTP толгой хэсэгт ижил зүйл тохиолддог , тэдгээрийг үүсгэхэд ашиглаж болох тул зөвхөн үндсэн домайн руу илгээгддэг хэрэглэгч. Таны ашигладаг CDN үйлчилгээ эдгээр толгойг зөв шүүж байгаа эсэхийг шалгаарай.
Үр дүн
Хэрэв та удахгүй гуравдагч талын нөөцийг өөрөө байршуулахаар төлөвлөж байгаа бол би танд хэдэн зөвлөгөө өгье:
- Өөрийн хамгийн чухал JS номын сан, фонт, CSS файлуудыг байршуулаарай. Энэ нь гуравдагч этгээдийн үйлчилгээний буруугаас болж сайтад чухал ач холбогдолтой нөөцийг ашиглах боломжгүй байгаа тул сайтын бүтэлгүйтэл, гүйцэтгэлийн доройтлын эрсдлийг бууруулна.
- CDN дээр гуравдагч талын нөөцүүдийг кэшлэхээсээ өмнө тэдгээрийн файлуудыг нэрлэхдээ ямар нэгэн хувилбарын системийг ашиглаж байгаа эсэх, эсвэл CDN-ийн шинэ хувилбарыг нийтлэхдээ CDN кэшийг гараар эсвэл автоматаар дахин тохируулах замаар эдгээр нөөцийн ашиглалтын хугацааг удирдах боломжтой эсэхийг шалгаарай. бичиг үсэг.
- CDN, прокси сервер болон кэш тохиргоондоо маш болгоомжтой байгаарай. Энэ нь таны төсөл эсвэл толгой хэсгийг күүки илгээхээс урьдчилан сэргийлэх боломжийг танд олгоно
Client-Hintsгуравдагч талын үйлчилгээ.
Эрхэм уншигчид! Та өөрийн төслийн үйл ажиллагаанд маш чухал ач холбогдолтой бусад хүмүүсийн материалыг сервер дээрээ байршуулдаг уу?
Эх сурвалж: www.habr.com