HTTP Caching

Foydalanuvchi sifatida biz videolarning buffering'idan, yuklanishi bir necha soniya oladigan rasmlardan va kontent yuklanayotgani sababli qotib qolgan sahifalardan tezda asabiylashamiz. Resurslarni biror keshdan yuklash ularni asl server'dan olishdan ancha tezroq. Bu latency'ni kamaytiradi, resurslar yuklanishini tezlashtiradi, server'dagi yuklamani pasaytiradi, bandwidth xarajatlarini qisqartiradi va hokazo.

Kirish

Veb kesh nima? Bu client va server o'rtasida biror joyda turadigan, so'rovlar va ularning javoblarini doimiy kuzatib, keshlash mumkin bo'lgan javoblarni qidiradigan narsa. Shunday qilib, xuddi shu so'rov qayta yuborilganda kamroq vaqt sarflanadi.

E'tibor bering, bu rasm sizga shunchaki umumiy tasavvur berish uchun. Kesh turiga qarab, u implement qilinadigan joy har xil bo'lishi mumkin. Bu haqda keyinroq batafsil gaplashamiz.

Tafsilotlarga o'tishdan oldin, maqolada keyinchalik ishlatiladigan atamalar bilan qisqacha tanishtirib o'tay:

• Client — brauzeringiz yoki server'dan biror resursni so'rayotgan istalgan ilova bo'lishi mumkin
• Origin Server — haqiqat manbai bo'lib, client'ga kerak bo'lgan barcha kontentni o'zida saqlaydi va client so'rovlarini bajarish uchun javobgar.
• Stale Content — keshlangan, lekin muddati o'tgan kontent
• Fresh Content — keshda mavjud bo'lgan va muddati hali o'tmagan kontent
• Cache Validation — keshlangan kontentning haqiqiyligini tekshirish va muddati tugash arafasida uni yangilab olish uchun server'ga murojaat qilish jarayoni
• Cache Invalidation — keshda mavjud bo'lgan har qanday stale kontentni olib tashlash jarayoni

Keshlash joylashuvlari

Veb kesh qayerda joylashganiga qarab shared yoki private bo'lishi mumkin. Turli keshlash joylashuvlari ro'yxati:

• Browser Cache
• Proxy Cache
• Reverse Proxy Cache

Browser Cache

Brauzeringizdagi orqaga tugmasini bosganingizda sahifa birinchi yuklanishdagiga qaraganda kamroq vaqtda yuklanishini payqagan bo'lsangiz kerak; bu brauzer keshining ishi. Brauzer keshi keshlash uchun eng keng tarqalgan joy bo'lib, brauzerlar odatda u uchun ma'lum joy ajratib qo'yadi.

Brauzer keshi faqat bitta foydalanuvchi bilan cheklangan va boshqa keshlardan farqli ravishda u "private" javoblarni saqlay oladi. Bu haqda keyinroq batafsil.

Proxy Cache

Bitta foydalanuvchiga xizmat qiladigan brauzer keshidan farqli ravishda, proxy keshlar bir xil kontentga murojaat qilayotgan yuzlab turli foydalanuvchilarga xizmat qilishi mumkin. Ular odatda kengroq miqyosda, masalan, ISP'lar yoki boshqa mustaqil tashkilotlar tomonidan implement qilinadi.

Reverse Proxy Cache

Reverse proxy kesh yoki surrogate kesh server'dagi yuklamani kamaytirish maqsadida origin server'larga yaqin joyda implement qilinadi. Tarmoqdagi bandwidth sarfini kamaytirish uchun ISP'lar va boshqalar tomonidan implement qilinadigan proxy keshlardan farqli ravishda, surrogate yoki reverse proxy keshlar server'dagi yuklamani kamaytirish uchun server administratorlari tomonidan origin server'lar yaqinida implement qilinadi.

Reverse proxy keshlarni boshqara olsangiz ham (chunki uni o'z server'ingizda o'zingiz implement qilasiz), brauzer va proxy keshlardan qochib qutula olmaysiz va ularni boshqara olmaysiz. Agar veb-saytingiz bu keshlardan to'g'ri foydalanadigan qilib sozlanmagan bo'lsa, u baribir shu keshlarda o'rnatilgan default sozlamalar asosida keshlanadi.

Keshlash header'lari

Xo'sh, veb keshni qanday boshqaramiz? Server har safar biror javob qaytarganida, unga keshlarga bu javobni keshlash kerakmi va qanday keshlash kerakligini ko'rsatadigan ba'zi HTTP header'lar qo'shib yuboriladi. Keshlarga kontentni qanday keshlashni majburan ko'rsatish uchun to'g'ri HTTP header'lar qaytarilishini ta'minlash kontent provayderining zimmasida.

• Kirish
• Keshlash joylashuvlari
  • Browser Cache
  • Proxy Cache
  • Reverse Proxy Cache
• Keshlash header'lari
  • Expires
  • Pragma
  • Cache-Control
    • private
    • public
    • no-store
    • no-cache
    • max-age: seconds
    • s-maxage: seconds
    • must-revalidate
    • proxy-revalidate
    • Qiymatlarni aralashtirish
• Validators
  • ETag
  • Last-Modified
• Nimadan boshlayman?
  • Server'dan foydalanish
  • Keshlash bo'yicha tavsiyalar

Expires

HTTP/1.1 va Cache-Control paydo bo'lishidan oldin Expires header'i bor edi; u shunchaki biror kontentni qancha vaqt davomida fresh deb hisoblash kerakligini keshlarga bildiradigan timestamp edi. Bu header'ning mumkin bo'lgan qiymati — mutlaq amal qilish muddati tugaydigan sana; bunda sana GMT bo'yicha bo'lishi shart. Quyida namunaviy header keltirilgan:

Expires: Mon, 13 Mar 2017 12:22:00 GMT

Shuni ta'kidlash kerakki, sana bir yildan ortiq bo'lishi mumkin emas va agar sana formati noto'g'ri bo'lsa, kontent stale deb hisoblanadi. Shuningdek, keshdagi soat server'dagi soat bilan sinxron bo'lishi kerak, aks holda kutilgan natijalarga erishilmasligi mumkin.

Expires header'i hali ham amal qilsa va keshlar tomonidan keng qo'llab-quvvatlansa ham, uning HTTP/1.1'dagi vorisi, ya'ni Cache-Control'ga ustunlik berish kerak.

Pragma

HTTP/1.1'dan oldingi eski davrlardan qolgan yana bir header — Pragma. U qila oladigan hamma narsani endi quyida keltirilgan cache-control header'i yordamida qilish mumkin. Biroq u haqida bir narsani ta'kidlab o'tmoqchiman: javob keshlanishining oldini olish umidida u yer-bu yerda Pragma: no-cache ishlatilayotganini ko'rishingiz mumkin. Bu har doim ham ishlamasligi mumkin, chunki HTTP spetsifikatsiyasi uni request header'lari doirasida ko'rib chiqadi, response header'larida esa u haqda hech narsa aytilmagan. Buning o'rniga keshlashni boshqarish uchun Cache-Control header'idan foydalanish kerak.

Cache-Control

Cache-Control kontent qancha vaqt va qanday tarzda keshlanishi kerakligini belgilaydi. Bu header'lar oilasi Expires header'ining cheklovlarini yengib o'tish uchun HTTP/1.1'da kiritilgan.

Cache-Control header'ining qiymati murakkab tarkibli, ya'ni u bir nechta directive/qiymatga ega bo'lishi mumkin. Keling, bu header o'z ichiga olishi mumkin bo'lgan qiymatlarni ko'rib chiqaylik.

private

Keshni private qilib belgilash kontent hech qaysi proxy'da keshlanmasligini va faqat client (ya'ni brauzer) tomonidan keshlanishini anglatadi:

Cache-Control: private

Shunday bo'lsa-da, bu header'ni o'rnatish ma'lumotlaringizni qandaydir xavfsiz qiladi, degan fikrga aldanib qolmang; buning uchun baribir SSL'dan foydalanishingiz kerak.

public

Agar public qilib belgilansa, kontent client tomonidan keshlanishidan tashqari, boshqa ko'plab foydalanuvchilarga xizmat qiladigan proxy'lar tomonidan ham keshlanishi mumkin:

Cache-Control: public

no-store

no-store kontent hech qaysi kesh tomonidan keshlanmasligi kerakligini belgilaydi:

Cache-Control: no-store

no-cache

no-cache keshni saqlash mumkinligini, lekin keshlangan kontent taqdim etilishidan oldin server'dan qayta validatsiya qilinishi (masalan, ETag yordamida) kerakligini bildiradi. Ya'ni server'ga baribir so'rov yuboriladi, ammo keshlangan kontentni yuklab olish uchun emas, balki validatsiya uchun.

Cache-Control: max-age=3600, no-cache, public

max-age: seconds

max-age kontent necha soniya davomida keshlanishini belgilaydi. Masalan, agar cache-control quyidagicha bo'lsa:

Cache-Control: max-age=3600, public

bu kontentni hamma uchun ochiq tarzda keshlash mumkinligini va u 60 daqiqadan so'ng stale deb hisoblanishini anglatadi.

s-maxage: seconds

s-maxage — bu yerdagi s- prefiksi shared (umumiy) degan ma'noni bildiradi. Bu directive aynan shared keshlarga mo'ljallangan. max-age kabi u ham biror narsa necha soniya davomida keshlanishi kerakligini qabul qiladi. Agar u mavjud bo'lsa, shared keshlash uchun max-age va expires header'larini override qiladi.

Cache-Control: s-maxage=3600, public

must-revalidate

must-revalidate — ba'zan shunday bo'lishi mumkinki, tarmoqda muammolar bo'lsa va kontentni server'dan olib bo'lmasa, brauzer stale kontentni validatsiyasiz taqdim etishi mumkin. must-revalidate buning oldini oladi. Agar bu directive mavjud bo'lsa, bu stale kontent hech qanday holatda taqdim etilmasligini va ma'lumotlar taqdim etilishidan oldin server'dan qayta validatsiya qilinishi shartligini anglatadi.

Cache-Control: max-age=3600, public, must-revalidate

proxy-revalidate

proxy-revalidate must-revalidate'ga o'xshaydi, lekin xuddi shu narsani shared yoki proxy keshlar uchun belgilaydi. Boshqacha aytganda, s-maxage max-age'ga qanday munosabatda bo'lsa, proxy-revalidate ham must-revalidate'ga shunday munosabatda. Lekin nega uni s-revalidate deb atashmagan? Buning sababini bilmayman, agar biror taxminingiz bo'lsa, iltimos, quyida izoh qoldiring.

Qiymatlarni aralashtirish

Turli keshlash xatti-harakatlariga erishish uchun bu directive'larni turli usullarda birlashtirishingiz mumkin, biroq no-cache/no-store va public/private bir-birini istisno qiladi.

Agar no-store va no-cache'ni birga ko'rsatsangiz, no-store no-cache'dan ustun hisoblanadi.

; If specified both Cache-Control: no-store, no-cache ; Below will be considered
Cache-Control: no-store

private/public masalasida esa, authentication'dan o'tmagan har qanday so'rov uchun kesh public, authentication'dan o'tgan so'rovlar uchun esa private deb hisoblanadi.

Validators

Hozirgacha biz faqat kontent qanday keshlanishi va keshlangan kontent qancha vaqt fresh deb hisoblanishini muhokama qildik, lekin client server'dan validatsiyani qanday amalga oshirishini muhokama qilmadik. Quyida shu maqsadda ishlatiladigan header'larni ko'rib chiqamiz.

ETag

Etag yoki "entity tag" HTTP/1.1 spetsifikatsiyalarida kiritilgan. Etag — server biror resursga biriktiradigan noyob identifikator. Keyinchalik bu ETag client tomonidan "give me this resource if ETag is not same as the ETag that I have" mazmunidagi shartli HTTP so'rovlarni yuborish uchun ishlatiladi va kontent faqat etag'lar mos kelmasagina yuklab olinadi.

ETag qanday generatsiya qilinishi HTTP hujjatlarida belgilanmagan va odatda resursning har bir versiyasiga etag biriktirish uchun biror collision-resistant hash funksiyasidan foydalaniladi. Etag'lar ikki xil bo'lishi mumkin: strong va weak.

ETag: "j82j8232ha7sdh0q2882" - Strong Etag ETag: W/"j82j8232ha7sdh0q2882" - Weak
Etag (prefixed with `W/`)

Strong validating ETag ikkita resurs aynan bir xil ekanligini va ular o'rtasida hech qanday farq yo'qligini anglatadi. Weak ETag esa ikkita resurs qat'iy ma'noda bir xil bo'lmasa ham, ularni bir xil deb hisoblash mumkinligini bildiradi. Weak etag'lar, masalan, dinamik kontent uchun foydali bo'lishi mumkin.

Endi siz etag'lar nima ekanligini bilasiz, lekin brauzer bu so'rovni qanday yuboradi? Server'ga so'rov yuborib, mavjud Etag'ni If-None-Match header'ida jo'natish orqali.

Quyidagi vaziyatni tasavvur qiling: siz veb-sahifani ochdingiz va u keshlash muddati 60 soniya, ETag'i esa abc123xyz bo'lgan logo rasmini yukladi. Taxminan 30 daqiqadan so'ng sahifani qayta yuklaysiz; brauzer 60 soniya davomida fresh bo'lgan logo endi stale ekanini payqaydi va server'ga so'rov yuboradi, bunda stale logo rasmining ETag'ini if-none-match header'ida jo'natadi:

If-None-Match: "abc123xyz"

So'ng server bu ETag'ni resursning joriy versiyasi ETag'i bilan solishtiradi. Agar ikkala etag mos kelsa, server 304 Not Modified javobini qaytaradi; bu client'ga undagi nusxa hali ham yaroqli ekanini va u yana 60 soniya davomida fresh deb hisoblanishini bildiradi. Agar ikkala etag mos kelmasa, ya'ni logo o'zgargan bo'lsa, client'ga yangi logo yuboriladi va client undan o'zidagi stale logo'ni almashtirish uchun foydalanadi.

Last-Modified

Server biror kontent oxirgi marta qachon o'zgartirilganini ko'rsatadigan Last-Modified header'ini qo'shishi mumkin.

Last-Modified: Wed, 15 Mar 2017 12:30:26 GMT

Kontent stale bo'lib qolganda, client yangilangan Last-Modified sanasini olish uchun server'ga shartli so'rov yuboradi va unda o'zidagi oxirgi o'zgartirilgan sanani If-Modified-Since deb ataladigan header ichida jo'natadi; agar u client'dagi sana bilan mos kelsa, kontentning Last-Modified sanasi yangilanadi va kontent yana n soniya davomida fresh deb hisoblanadi. Agar qabul qilingan Last-Modified sanasi client'dagi sana bilan mos kelmasa, kontent server'dan qayta yuklanadi va client'dagi kontent bilan almashtiriladi.

If-Modified-Since: Wed, 15 Mar 2017 12:30:26 GMT

Endi sizda savol tug'ilishi mumkin: agar keshlangan kontentga ham Last-Modified, ham ETag biriktirilgan bo'lsa-chi? Unday holda ikkalasidan ham foydalaniladi, ya'ni ETag yangi olingani bilan mos kelgan va Last-Modified sanasi ham mos kelgan taqdirdagina resurs qayta yuklab olinmaydi. Agar ETag mos kelmasa yoki Last-Modified server'dagidan katta bo'lsa, kontentni qayta yuklab olishga to'g'ri keladi.

Nimadan boshlayman?

Endi biz hamma narsani ko'rib chiqqanimizdan so'ng, keling, barchasini bir joyga jamlab, bu ma'lumotlardan qanday foydalanishingiz mumkinligini ko'rib chiqaylik.

Server'dan foydalanish

Mumkin bo'lgan keshlash strategiyalariga o'tishdan oldin shuni qo'shib qo'yay: Apache va Nginx kabi ko'pchilik serverlar keshlash siyosatingizni server orqali implement qilish imkonini beradi, shunda kodingizda header'lar bilan ovora bo'lishingizga hojat qolmaydi.

Masalan, agar siz Apache'dan foydalanayotgan bo'lsangiz va static kontentingiz /static papkasida joylashgan bo'lsa, undagi barcha kontent bir yil davomida keshlanishi uchun shu papkaga quyidagi .htaccess faylini joylashtirishingiz mumkin:

# Cache everything for an year Header set Cache-Control "max-age=31536000,
public"

Bundan tashqari, shartlar qo'shish va turli fayl turlari uchun turli keshlash strategiyalaridan foydalanish uchun filesMatch directive'ini ishlatishingiz mumkin, masalan:

# Cache any images for one year
<filesMatch ".(png|jpg|jpeg|gif)$">
    Header set Cache-Control "max-age=31536000, public"
</filesMatch>

# Cache any CSS and JS files for a month
<filesMatch ".(css|js)$">
    Header set Cache-Control "max-age=2628000, public"
</filesMatch>

Yoki .htaccess faylidan foydalanishni istamasangiz, Apache'ning http.conf konfiguratsiya faylini o'zgartirishingiz mumkin. Nginx uchun ham xuddi shunday: keshlash ma'lumotlarini location yoki server block'iga qo'shishingiz mumkin.

Keshlash bo'yicha tavsiyalar

Keshlash siyosatingiz qanday bo'lishi kerakligi haqida oltin qoida yoki belgilangan standartlar yo'q; har bir ilova o'ziga xos va ilovangizga eng mos keladigan narsani ko'rib chiqib, o'zingiz topishingiz kerak. Biroq sizga taxminiy tasavvur berish uchun:

• Har qanday static kontent uchun agressiv keshlashdan (masalan, bir yilga keshlash) foydalanishingiz va fingerprint qo'shilgan fayl nomlarini (masalan, style.ju2i90.css) ishlatishingiz mumkin, shunda fayllar yangilanganda kesh avtomatik ravishda rad etiladi. Shuni ham yodda tutish kerakki, bir yillik yuqori chegaradan oshmasligingiz kerak, chunki unga amal qilinmasligi mumkin
• Dinamik kontent uchun umuman keshlash kerakmi yoki yo'qligini ko'rib chiqib qaror qiling; agar kerak bo'lsa, qancha muddatga kerakligini aniqlang. Masalan, blogning RSS feed'i uchun bir necha soatlik keshlash bo'lishi mumkin, lekin ERP'dagi inventar elementlari uchun hech qanday keshlash bo'lmasligi kerak.
• Javobingizga har doim validator'larni (afzalroq ETag'larni) qo'shing.
• Keshlangan kontentning ko'rinish darajasini (private yoki public) tanlashda ehtiyot bo'ling. Foydalanuvchiga xos yoki maxfiy kontentni tasodifan biror public proxy'da keshlab qo'ymaganingizga ishonch hosil qiling. Shubhangiz bo'lsa, keshdan umuman foydalanmang.
• Tez-tez o'zgaradigan kontentni unchalik tez o'zgarmaydigan kontentdan ajrating (masalan, javascript bundle'larida), shunda u yangilanganda butun keshlangan kontentni stale qilishga to'g'ri kelmaydi.
• Saytingiz taqdim etayotgan keshlash header'larini testlang va monitoring qiling. Buning uchun brauzer konsolidan yoki curl -I http://some-url.com buyrug'idan foydalanishingiz mumkin.

Mana, taxminan shu bilan yakunlaymiz. Davomini kuting!