Cache-Control — bu nima, direktivalar va keshlashni boshqarish

Cache-Control nima?

Cache-Control — bu HTTP/1.1 (RFC 7234) da standartlashtirilgan HTTP sarlavhasi bo‘lib, serverga mijozlar, proksilar va CDN lar javobni qanday va qancha vaqt keshlashi mumkinligini ko‘rsatishga imkon beradi. Expires (HTTP/1.0) dan farqli o‘laroq, Cache-Control direktivalardan — vergul bilan birlashtiriladigan matnli buyruqlardan foydalanadi: Cache-Control: public, max-age=3600, must-revalidate. Sarlavha keshlash zanjirining har bir bo‘g‘ini aniq nazorat qilish imkonini beradi.

Keshlash veb va mobil ilovalar samaradorligining asosiy mexanizmlaridan biridir. Usiz, har bir foydalanuvchi so‘rovi to‘g‘ridan-to‘g‘ri serverga borib, ortiqcha yuk va kechikishlarga sabab bo‘ladi. Cache-Control uchta keshlash darajasini belgilaydi: brauzer/ilova (private cache), proksi-serverlar (shared cache) va CDN (distributed cache). Har bir daraja direktivalarni o‘zicha talqin qiladi.

Cache-Control ni noto‘g‘ri sozlash samaradorlik muammolarining eng keng tarqalgan sabablaridan biridir. Haddan tashqari agressiv keshlash foydalanuvchilarning eskirgan ma’lumotlarni ko‘rishiga olib keladi. Juda zaif keshlash esa serverga ortiqcha so‘rovlar va sekin yuklashga olib keladi. Akamai (2025) ma’lumotlariga ko‘ra, statik kontent uchun Cache-Control optimallashtirish server yukini 70-90% ga kamaytiradi va mobil foydalanuvchilar uchun yuklash vaqtini 40-60% ga yaxshilaydi.

Sarlavha tarixi

Cache-Control HTTP/1.1 (RFC 2616, 1999) da Expires o‘rnini bosuvchi sifatida paydo bo‘ldi. Expires asosiy muammoga ega edi: server va mijozning vaqt mintaqasiga bog‘liq bo‘lgan mutlaq sanadan foydalanardi. Cache-Control bu muammoni nisbiy vaqtga o‘tish orqali hal qildi (javob olingan paytdan boshlab soniyalarda max-age). Keyinchalik RFC 7234 (2014) da yangi direktivalar qo‘shildi: statikalar uchun immutable, kechiktirilgan tekshirish uchun stale-while-revalidate va stale-if-error.

Cache-Control direktivalari

Cache-Control uch guruhga bo‘lingan 10 dan ortiq direktivani o‘z ichiga oladi: so‘rov direktivalari (mijoz → server), javob direktivalari (server → mijoz) va kengaytmalar. Amalda mobil ishlanmada keshlash stsenariylarining 95% ini qamrab oluvchi 6-7 ta asosiy javob direktivasidan foydalaniladi. Har birini misollar va tavsiyalar bilan ko‘rib chiqamiz.

max-age — eng muhim direktiva. Belgilangan vaqt davomida mijozning serverga so‘rov yuborishini taqiqlaydi. Statikalar (CSS, JS, rasmlar) uchun max-age odatda 1 kundan 1 yilgacha belgilanadi. API javoblari uchun — 0 soniyadan (har doim yangi ma’lumotlar) 5-10 daqiqagacha (ma’lumotnoma ma’lumotlari). s-maxage CDN va brauzer uchun turli hayot vaqtini belgilash imkonini beradi: CDN 1 kun, brauzer 1 soat saqlaydi.

no-cache vs no-store

Ushbu ikki direktiva ko‘pincha chalkashtiriladi. no-cache keshlashni taqiqlamaydi — u har foydalanishda shartli so‘rov (If-Modified-Since yoki If-None-Match) orqali keshlangan nusxani tekshirishni talab qiladi. Server 304 javobini qaytarsa — mijoz keshdan foydalanadi. Agar 200 bo‘lsa — yangilaydi. no-store esa javobni har qanday keshda (disk va operativ xotira ham) saqlashni butunlay taqiqlaydi. no-store dan faqat maxfiy ma’lumotlar uchun foydalaning — tokenlar, to‘lov ma’lumotlari, shaxsiy hujjatlar.

Cache-Control vs Expires

Expires sarlavhasi (HTTP/1.0) ham resursning hayot vaqtini ko‘rsatadi, lekin mutlaq sanadan foydalanadi: Expires: Thu, 03 Jul 2026 12:00:00 GMT. Cache-Control max-age — javob paytidan boshlab nisbiy vaqt. Farq taqsimlangan tizimlar uchun muhim: server va mijoz turli vaqt mintaqalarida bo‘lsa, Expires noto‘g‘ri talqin qilinishi mumkin. Cache-Control da bu muammo yo‘q — 3600 soniya har doim 3600 soniya.

Ikkala sarlavha mavjud bo‘lganda, Cache-Control Expires dan ustun turadi. Bu RFC 7234 da belgilangan: “Agar javobda max-age direktivasi bilan Cache-Control bo‘lsa, qabul qiluvchi Expires ni INOBOTGA OLMASLIGI KERAK”. Amalda zamonaviy mijozlar uchun Expires ni qaytarmaslik tavsiya etiladi, chunki Cache-Control Expires ning barcha stsenariylarini qamrab oladi. Biroq, eski proksi va brauzerlar bilan teskari muvofiqlik uchun ikkala sarlavha ham qaytarilishi mumkin.

Expires asosan Nginx va Apache da statik kontent uchun saqlanib qolgan — bu serverlar avtomatik ravishda ikkala sarlavhani qo‘shadi. Loyihangizda Expires Cache-Controlsiz uchrasa, uni max-age bilan Cache-Control ga almashtiring: kesh boshqaruvi aniqligi oshadi va vaqt mintaqasiga bog‘liqlik bartaraf etiladi. Migratsiya uchun serverni Expires o‘rniga Cache-Control qo‘shadigan qilib sozlash kifoya.

# Nginx: Statik fayllar uchun Cache-Control
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
    expires 30d;
    add_header Cache-Control "public, immutable, max-age=2592000";
}

# Turli kontent turlari uchun turli siyosatlar
location /api/config {
    expires -1;
    add_header Cache-Control "no-cache, must-revalidate";
}

location /api/static-data {
    expires 5m;
    add_header Cache-Control "public, max-age=300";
}

Nginx konfiguratsiyasida statik fayllar (CSS, JS, rasmlar) uchun immutable atributi bilan 30 kunlik Cache-Control o‘rnatiladi — bu atribut brauzerga resursning bu URL ostida hech qachon o‘zgarmasligini bildiradi (fayl nomidagi hash orqali versiyalash). API endpoyntlari dinamik ma’lumotlar uchun no-cache, ma’lumotnoma ma’lumotlari uchun esa qisqa max-age bilan public ishlatadi — tez-tez so‘raladigan va kam o‘zgaradigan ro‘yxatlar.

Mobil ilovalarda keshlash

Mobil ilovalarda Cache-Control mobil tarmoqlarning cheklovlari tufayli alohida rol o‘ynaydi: yuqori kechikish, beqaror aloqa, trafik cheklovlari. To‘g‘ri keshlash foydalanuvchiga ma’lumotlarni bir zumda, hatto offlayn ko‘rish va ularni fonda yangilash imkonini beradi. Android da OkHttp va iOS da URLSession Cache-Control ni hisobga oluvchi o‘rnatilgan keshlash tizimlariga ega.

OkHttp javobdan Cache-Control ni o‘qib, avtomatik ravishda keshlashni boshqaruvchi CacheInterceptor dan foydalanadi. Agar server Cache-Control: max-age=3600 qaytarsa, OkHttp bir soat davomida serverga so‘rov yubormaydi. Max-age tugagandan so‘ng, OkHttp If-Modified-Since va If-None-Match bilan shartli so‘rov yuboradi. OkHttp da keshni sozlash: OkHttpClient.Builder().cache(Cache(directory, maxSize)).

fun createCachedClient(cacheDir: File): OkHttpClient {
    return OkHttpClient.Builder()
        .cache(Cache(cacheDir, 10L * 1024 * 1024))
        .addNetworkInterceptor { chain ->
            val response = chain.proceed(chain.request())
            response.newBuilder()
                .header("Cache-Control",
                    "public, max-age=300")
                .removeHeader("Pragma")
                .build()
        }
        .build()
}

Kod 10 MB kesh bilan OkHttpClient yaratadi va NetworkInterceptor orqali Cache-Control ni bekor qiladi. Agar server Cache-Control qaytarmasa yoki Expires ishlatsa, interceptor public, max-age=300 (5 daqiqa) qo‘shadi. Interceptor muvofiqlik uchun eskirgan Pragma sarlavhasini (HTTP/1.0) olib tashlaydi. Xuddi shu sxema bo‘yicha iOS da URLCache.shared orqali memoryCapacity va diskCapacity sozlamalari bilan keshlash ishlaydi.

Offlayn rejim va stale-while-revalidate

stale-while-revalidate direktivi ilova fonda yangi ma’lumotlarni yuklayotganda foydalanuvchiga eskirgan keshni (stale) ko‘rish imkonini beradi. Bu bir zumda javob effektini yaratadi: foydalanuvchi kontentni darhol ko‘radi va bir soniyadan so‘ng u yangilanadi. OkHttp 3.10 versiyasidan va iOS 14+ da URLCache tomonidan qo‘llab-quvvatlanadi. Misol: Cache-Control: max-age=3600, stale-while-revalidate=300 — 1 soat amaldagi kesh, so‘ngra fonda yangilanish bilan 5 daqiqa eskirgan kesh ko‘rinishi.

Cache-Control sozlash misollari

Turli resurs turlari turli keshlash strategiyalarini talab qiladi. Mobil ishlanmada odatiy stsenariylar uchun optimal konfiguratsiyalarni ko‘rib chiqamiz. Fayl nomida hash bo‘lgan statik kontent uchun (bundle.abc123.js) immutable bilan 1 yilgacha max-age belgilash mumkin. Kam yangilanadigan API ro‘yxatlari (kataloglar, kategoriyalar) uchun — stale-while-revalidate bilan 5 daqiqadan 1 soatgacha max-age.

Xavfsizlik haqida esda tutish muhim: foydalanuvchining shaxsiy ma’lumotlarini o‘z ichiga olgan javoblar uchun har doim private belgilang. Ushbu direktivasiz, umumiy proksi (masalan, korporativ) javobni keshlab, uni boshqa foydalanuvchiga berishi mumkin. Autentifikatsiya tokenlari va to‘lov ma’lumotlari uchun no-store dan foydalaning — hatto private kesh ham bu ma’lumotlarni diskda saqlamasligi kerak.

Keshlashni nosozliklarini tuzatish

Cache-Control to‘g‘riligini tekshirish uchun Age sarlavhasidan (kesh necha soniya saqlangan) va X-Cache dan (CDN da hit/miss) foydalaning. Brauzerda — Network yorlig‘i, Size ustuni “from disk cache” yoki “304 Not Modified” ni ko‘rsatadi. Agar resurs keshlanishi kerak bo‘lsa, lekin har safar yuklansa — server sizning direktivalaringiz bilan birga Cache-Control: no-cache yoki Pragma: no-cache qo‘shmayotganligini tekshiring.