ETag: bu nima, keshlash mexanizmi va sarlavhani sozlash

ETag nima?

ETag (Entity Tag) — resursning muayyan versiyasining noyob identifikatorini o‘z ichiga olgan HTTP javob sarlavhasi. Server fayl tarkibi, uning metama’lumotlari yoki qayta ko‘rib chiqish raqami asosida ETag-ni hisoblaydi va GET so‘roviga javoban mijozga uzatadi. Mijoz ushbu identifikatorni saqlaydi va keyingi so‘rovlarda xuddi shu resursga If-None-Match sarlavhasida yuboradi. Agar resurs o‘zgarmagan bo‘lsa, server 304 Not Modified javobini qaytaradi va mijoz o‘zining keshlangan nusxasidan foydalanadi.

ETag formati RFC 7232 da qo‘shtirnoq ichidagi qator sifatida belgilangan: "33a64df551425fcc55e4d42a148795d9f25f89d4". Qiymat fayl tarkibining SHA-1 xeshi, o‘sib boruvchi versiya raqami, statik fayllar uchun inode-raqam-vaqt kombinatsiyasi yoki server tomonidan yaratilgan ixtiyoriy token bo‘lishi mumkin. Yagona talab — qiymat resursning har qanday o‘zgarishida o‘zgarishi va resurs bir xil qolsa o‘zgarmasligidir.

ETag shartli so‘rovlar (conditional requests) mexanizmiga kiradi — HTTP protokolining asosiy optimallashtirishlaridan biri. Server har doim to‘liq javob qaytaradigan shartsiz so‘rovlardan farqli o‘laroq, shartli so‘rov mijozga ma’lumotlarni qayta yuklamasdan keshing dolzarbligini tekshirish imkonini beradi. HTTP Archive (2025) ma’lumotlariga ko‘ra, barcha HTTP javoblarining taxminan 40% i ETag va Last-Modified ni to‘g‘ri sozlash tufayli 304 Not Modified dir.

ETag qayerda qo‘llaniladi

ETag REST API da ma’lumotlar to‘plamlarini yuklashni optimallashtirish uchun ishlatiladi — obyektlar ro‘yxati o‘zgarmagan bo‘lsa, mijoz butun JSONni yubormasdan 304 oladi. Statik fayllarda (CSS, JS, rasmlar) ETag CDN va brauzerlarga keshing dolzarbligini samarali tekshirish imkonini beradi. Mobil ilovalarda ETag fon sinxronizatsiyasi uchun muhim: ilova serverdagi ma’lumotlar o‘zgarganligini tekshiradi va yangilanishlarni faqat kerak bo‘lganda yuklab oladi. Bu trafik va qurilma batareyasini tejaydi.

ETag qanday ishlaydi?

ETagning to‘liq ishlash sikli to‘rt bosqichdan iborat. Server birinchi so‘rovda ETag yaratadi va uni javob sarlavhasida qaytaradi. Mijoz ETag-ni keshlangan resurs bilan birga saqlaydi. Qayta so‘rovda mijoz If-None-Match sarlavhasida saqlangan ETag qiymatini yuboradi. Server olingan qiymatni resursning joriy ETag-i bilan solishtiradi: mos kelganda bo‘sh tana bilan 304 Not Modified, mos kelmaganda — yangi resurs va yangi ETag bilan 200 OK qaytaradi.

// Mijozning If-None-Match bilan so‘rovi
GET /api/users HTTP/1.1
Host: example.com
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

// Server javobi — resurs o‘zgarmagan
HTTP/1.1 304 Not Modified
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Mobil ilovada bu sikl keshlashni qo‘llab-quvvatlovchi HTTP mijoz orqali amalga oshirilishi mumkin. OkHttp, masalan, CacheInterceptor orqali ETag-ni avtomatik boshqaradi: javobning ETagini saqlaydi va qayta so‘rovda If-None-Match qo‘shadi. 304 olgandan so‘ng OkHttp keshlangan ma’lumotlarni qaytaradi. OkHttp qo‘shimcha sozlamasiz ETag-ni qo‘llab-quvvatlaydi — OkHttpClient.Builder.cache() orqali keshni yoqish kifoya.

Serverda ETag yaratish

Server ETag-ni turli usullar bilan hisoblashi mumkin: kontentning MD5 yoki SHA xeshi orqali, ma’lumotlar bazasidan qayta ko‘rib chiqish raqami orqali (masalan, MySQL dan updated_at), statik fayllar uchun inode + mtime + size kombinatsiyasi orqali (Nginx ETag-ni aynan shunday yaratadi). Dinamik API lar uchun eng ishonchlisi kontent xeshidir: agar JSON javobi hech bo‘lmaganda bitta maydonni o‘zgartirsa, ETag o‘zgaradi. Biroq har bir so‘rovda xeshni hisoblash protsessorni yuklaydi — yuqori yuklangan tizimlar uchun o‘sib boruvchi versiya raqamidan foydalanish yaxshiroqdir.

Kuchli va zaif ETag

RFC 7232 ETagning ikki turini belgilaydi: kuchli (strong) va zaif (weak). Kuchli ETag resursning ikki ko‘rinishi bayt-bayta bir xil ekanligini anglatadi — hech qanday bit farq qilmaydi. Zaif ETag (W/ prefiksi) faqat semantik ekvivalentlikni kafolatlaydi: tarkib seriyalashtirish darajasida farq qilishi mumkin (bo‘shliqlar, JSON maydonlarining tartibi), ammo mijoz uchun ma’lumotlar bir xil hisoblanadi. Zaif ETag lar W/ prefiksi bilan belgilanadi, masalan W/"1a2b3c".

ETag turini tanlash taqqoslash aniqligi talablariga bog‘liq. Statik fayllar (CSS, JS, rasmlar) uchun kuchli ETag afzal — agar fayl o‘zgargan bo‘lsa, mijoz yangi versiyani olishi kerak. Dinamik API lar uchun, bir xil JSON turli maydon tartibi yoki formatlash bilan seriyalashtirilishi mumkin bo‘lgan hollarda, zaif ETag lar ko‘proq moslashuvchanlik beradi: server ETag-ni matn ko‘rinishiga emas, balki biznes ma‘lumotlariga asoslanib yaratadi.

Zaif ETag larning cheklovi: ular diapazon so‘rovlari (Range requests) bilan ishlatilmaydi. Agar mijoz faylning bir qismini so‘rasa, server fragment to‘liq resursga mos kelishini kafolatlash uchun kuchli ETag qaytarishi kerak. Zaif ETag lar bunday kafolatni bermaydi. Boshqa stsenariylarda zaif ETag lar xavfsiz va API lar uchun tavsiya etiladi.

ETag vs Last-Modified

ETag va Last-Modified — shartli so‘rovlar uchun tez-tez birgalikda ishlatiladigan ikkita HTTP sarlavhasi. Last-Modified resursning oxirgi o‘zgarish sanasini ko‘rsatadi va If-Modified-Since sarlavhasi bilan ishlaydi. ETag versiyaning noyob identifikatorini ta’minlaydi va If-None-Match bilan ishlaydi. Har birining o‘z afzalliklari va cheklovlari bor, kombinatsiya esa maksimal keshlash samaradorligini beradi.

Last-Modified joriy qilish osonroq — server avtomatik ravishda sanani fayl tizimidan oladi yoki ma’lumotlar bazasida updated_at maydonini yangilaydi. Biroq sananing aniqligi soniyagacha, bu soniyada bir necha marta o‘zgaradigan resurslar uchun yetarli emas. Bundan tashqari, Last-Modified turli holatlarni farqlamaydi: agar fayl bir xil versiya bilan qayta yozilsa, sana o‘zgaradi, ammo tarkib o‘zgarmaydi — mijoz bir xil ma’lumotlarni qayta yuklaydi.

ETag aniqroq: faqat tarkibning haqiqiy o‘zgarishida o‘zgaradi. Agar server zaxira nusxadan oldingi versiyani tiklasa, ETag o‘zgaradi. Agar fayl bir xil ma’lumotlar bilan qayta yozilsa — ETag bir xil qoladi va mijoz qayta yuklamaydi. Birgalikda foydalanish HTTP spetsifikatsiyasi tomonidan tavsiya etiladi: server ikkala sarlavhani qaytaradi, mijoz If-None-Match va If-Modified-Since ni bir vaqtda yuboradi. Agar hech bo‘lmaganda bitta sarlavha o‘zgarishni ko‘rsatsa — server yangi resursni qaytaradi.

Sarlavhalarning ustuvorligi

Spetsifikatsiyaga ko‘ra, ETag Last-Modified dan ustunlikka ega. Agar server If-None-Match olgan bo‘lsa, If-Modified-Since ni e’tiborsiz qoldirib, faqat ETag ni tekshirishi kerak. Bu race condition oldini oladi: agar resurs mijozning Last-Modified yuborishi va serverda tekshirish o‘rtasida o‘zgargan bo‘lsa, ETag yangiroq ko‘rsatkich bo‘ladi. Amalda serverlar odatda ikkala sarlavhani tekshiradi, ammo natijalar nomuvofiq bo‘lganda ETag g‘alaba qozonadi.

Serverda ETag-ni joriy qilish

ETag sozlamasi server turiga bog‘liq. Nginx statik fayllar uchun ETag-ni avtomatik ravishda inode, mtime va o‘lcham asosida yaratadi. Apache FileETag mexanizmidan foydalanadi. Node.js, PHP, Python, Ruby da dinamik ilovalar uchun ETag dasturiy ravishda — javob xeshi, ma’lumotlar versiya raqami yoki so‘rov parametrlari kombinatsiyasi orqali yaratilishi kerak.

func etagMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter,
        r *http.Request) {
        // Ma’lumotlar asosida ETag yaratish
        etag := generateETag(r.URL.Path)
        w.Header().Set("ETag", etag)

        // If-None-Match ni tekshirish
        if r.Header.Get("If-None-Match") == etag {
            w.WriteHeader(http.StatusNotModified)
            return
        }
        next.ServeHTTP(w, r)
    })
}

Go middleware so‘rovni tutadi, so‘ralgan URL uchun ETag yaratadi (masalan, kesh yoki ma’lumotlar bazasidan ma’lumotlar xeshini hisoblaydi) va javob sarlavhasini o‘rnatadi. Agar mijoz If-None-Match yuborgan bo‘lsa va u joriy ETag bilan mos kelsa, server asosiy handlerni chaqirmasdan darhol 304 Not Modified qaytaradi. Ishlab chiqarish muhitida server yukini kamaytirish uchun hisoblangan ETag larni URL va parametrlar bo‘yicha keshlash qo‘shilishi kerak.

Muammolar va tuzoqlar

Ko‘p serverli konfiguratsiyada (round-robin yoki anycast) ETag bir xil resurs uchun barcha tugunlarda bir xil bo‘lishi kerak. Agar ETag faylning inode asosida yaratilsa va sayt bir nechta serverda ishlasa, qiymatlar farq qiladi. Yechim — kontent xeshidan yoki markazlashtirilgan versiyalarni saqlashdan (Redis, etcd) foydalanish. Ikkinchi muammo — gzip siqish: Nginx siqish yoqilganda ETag-ni o‘zgartiradi, bu ortiqcha 300 larga olib kelishi mumkin. ETag-ni siqilgan kontent bilan sinxronlash uchun gzip_vary on sozlamasi talab qilinadi.