Cache-Control — bu nədir, direktivlər və keş idarəetməsi

Cache-Control nədir?

Cache-Control — HTTP/1.1 (RFC 7234) çərçivəsində standartlaşdırılmış HTTP başlığıdır, serverə müşterilərin, proksilərin və CDN-lərin cavabı necə və nə qədər keşləyə biləcəyini göstərməyə imkan verir. Expires-dən (HTTP/1.0) fərqli olaraq, Cache-Control direktivlərdən — vergüllə birləşdirilən mətn əmrlərindən istifadə edir: Cache-Control: public, max-age=3600, must-revalidate. Başlıq keşlənmə zəncirinin hər bir halqası üzərində dəqiq nəzarət verir.

Keşlənmə veb və mobil tətbiqlərin performansının əsas mexanizmlərindən biridir. O olmadan, hər bir istifadəçi sorğusu birbaşa serverə gedərək həddindən artıq yük və gecikmələrə səbəb olardı. Cache-Control üç keşlənmə səviyyəsini müəyyənləşdirir: brauzer/tətbiq (private cache), proksi-serverlər (shared cache) və CDN (distributed cache). Hər səviyyə direktivləri özünə məxsus şəkildə şərh edir.

Cache-Control-un səhv qurulması performans problemlərinin ən geniş yayılmış səbəblərindən biridir. Həddindən artıq aqressiv keşlənmə istifadəçilərin köhnəlmiş məlumatları görməsinə səbəb olur. Çox zəif keşlənmə isə serverə həddindən artıq sorğu və yavaş yükləməyə gətirir. Akamai (2025) məlumatlarına görə, statik məzmun üçün Cache-Control optimallaşdırılması server yükünü 70-90% azaldır və mobil istifadəçilər üçün yükləmə müddətini 40-60% yaxşılaşdırır.

Başlığın tarixi

Cache-Control HTTP/1.1 (RFC 2616, 1999) çərçivəsində Expires-in əvəzi kimi ortaya çıxdı. Expires əsas problemə malik idi: server və müşterinin saat qurşağından asılı olan mütləq tarixdən istifadə edirdi. Cache-Control bu problemi nisbi vaxta keçməklə həll etdi (cavabın alınması anından saniyələrlə max-age). Daha sonra RFC 7234 (2014) əlavə olaraq yeni direktivlər əlavə edildi: statik üçün immutable, təxirə salınmış yoxlama üçün stale-while-revalidate və stale-if-error.

Cache-Control direktivləri

Cache-Control üç qrupa bölünmüş 10-dan çox direktivi əhatə edir: sorğu direktivləri (müşteri → server), cavab direktivləri (server → müşteri) və genişləndirmələr. Təcrübədə mobil inkişafda keşlənmə ssenarilərinin 95%-ni əhatə edən 6-7 əsas cavab direktivindən istifadə olunur. Hər birini nümunələr və tövsiyələrlə nəzərdən keçirək.

max-age — ən vacib direktiv. Müəyyən edilmiş müddət ərzində müşteriyə serverə sorğu göndərməyi qadağan edir. Statik üçün (CSS, JS, şəkillər) max-age adətən 1 gündən 1 ilə qədər qurulur. API cavabları üçün — 0 saniyədən (həmişə təzə məlumatlar) 5-10 dəqiqəyə qədər (istinad məlumatları). s-maxage CDN və brauzer üçün fərqli ömür müddəti təyin etməyə imkan verir: CDN 1 gün, brauzer 1 saat saxlayır.

no-cache vs no-store

Bu iki direktiv çox vaxt qarışdırılır. no-cache keşlənməni qadağan etmir — o, hər istifadədə şərti sorğu vasitəsilə (If-Modified-Since və ya If-None-Match) keşlənmiş nüsxənin yoxlanmasını tələb edir. Server 304 cavabı verərsə — müşteri keşdən istifadə edir. 200 verərsə — yeniləyir. no-store isə cavabın hər hansı keşdə (disk və operativ daxil olmaqla) saxlanmasını tamamilə qadağan edir. no-store-dan yalnız həssas məlumatlar üçün istifadə edin — tokenlər, ödəniş məlumatları, şəxsi sənədlər.

Cache-Control vs Expires

Expires başlığı (HTTP/1.0) da resursun ömür müddətini göstərir, lakin mütləq tarixdən istifadə edir: Expires: Thu, 03 Jul 2026 12:00:00 GMT. Cache-Control max-age — cavab anından nisbi vaxtdır. Fərq paylanmış sistemlər üçün kritikdir: server və müşteri müxtəlif saat qurşaqlarındadırsa, Expires səhv şərh edilə bilər. Cache-Control-un bu problemi yoxdur — 3600 saniyə həmişə 3600 saniyədir.

Hər iki başlıq mövcud olduqda, Cache-Control Expires-dən üstünlükə malikdir. Bu, RFC 7234-də müəyyən edilmişdir: “Cavabda max-age direktivi ilə Cache-Control varsa, alıcı Expires-i NİZAMMALIDIR”. Təcrübədə müasir müşterilər üçün Expires-in qaytarılmaması tövsiyə olunur, çünki Cache-Control Expires-in bütün ssenarilərini əhatə edir. Lakin köhnə proksi və brauzerlərlə geriyə uyğunluq üçün hər iki başlıq qaytarıla bilər.

Expires əsasən Nginx və Apache-də statik məzmun üçün qalıb — bu serverlər avtomatik olaraq hər iki başlığı əlavə edir. Layihənizdə Expires Cache-Control olmadan rast gəlirsə, onu max-age ilə Cache-Control ilə əvəz edin: keş idarəetməsinin dəqiqliyi artır və saat qurşağından asılılıq aradan qaldırılır. Miqrasiya üçün serveri Expires əvəzinə Cache-Control əlavə etmək üçün konfiqurasiya etmək kifayətdir.

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

# Müxtəlif məzmun növləri üçün fərqli siyasətlər
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 konfiqurasiyasında statik fayllar üçün (CSS, JS, şəkillər) immutable atributu ilə 30 günlük Cache-Control qurulur — bu atribut brauzerə resursun bu URL altında heç vaxt dəyişmədiyini bildirir (fayl adında hash vasitəsilə versiyalama). API endpointləri dinamik məlumatlar üçün no-cache, istinad məlumatları üçün isə qısa max-age ilə public istifadə edir — tez-tez tələb olunan və nadir dəyişən siyahılar.

Mobil tətbiqlərdə keşlənmə

Mobil tətbiqlərdə Cache-Control xüsusi rol oynayır, çünki mobil şəbəkələrin məhdudiyyətləri var: yüksək gecikmə, qeyri-sabit əlaqə, trafik məhdudiyyətləri. Düzgün keşlənmə istifadəçiyə məlumatları dərhal, hətta oflayn göstərməyə və onları fonda yeniləməyə imkan verir. Android-də OkHttp və iOS-da URLSession Cache-Control-u nəzərə alan daxili keşlənmə sistemlərinə malikdir.

OkHttp cavabdan Cache-Control-u oxuyan və avtomatik keşlənməni idarə edən CacheInterceptor-dan istifadə edir. Server Cache-Control: max-age=3600 qaytararsa, OkHttp bir saat ərzində serverə sorğu göndərməyəcək. Max-age bitdikdən sonra OkHttp If-Modified-Since və If-None-Match ilə şərti sorğu göndərir. OkHttp-də keşin qurulması: 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 keşlə OkHttpClient yaradır və NetworkInterceptor vasitəsilə Cache-Control-u ləğv edir. Server Cache-Control qaytarmazsa və ya Expires istifadə edərsə, interceptor public, max-age=300 (5 dəqiqə) əlavə edir. Interceptor uyğunluq üçün köhnəlmiş Pragma başlığını (HTTP/1.0) silir. Eyni sxem üzrə iOS-da URLCache.shared vasitəsilə memoryCapacity və diskCapacity parametrləri ilə keşlənmə işləyir.

Oflayn rejim və stale-while-revalidate

stale-while-revalidate direktivi tətbiq fonda təzə məlumatları yükləyərkən istifadəçiyə köhnəlmiş keşi (stale) göstərməyə imkan verir. Bu, ani cavab effekti yaradır: istifadəçi məzmunu dərhal görür və bir saniyə sonra yenilənmiş versiyanı alır. OkHttp 3.10 və iOS 14+ URLCache tərəfindən dəstəklənir. Nümunə: Cache-Control: max-age=3600, stale-while-revalidate=300 — 1 saat aktual keş, sonra fonda yenilənmə ilə 5 dəqiqə köhnəlmiş məlumatların göstərilməsi.

Cache-Control qurulması nümunələri

Müxtəlif resurs növləri müxtəlif keşlənmə strategiyaları tələb edir. Mobil inkişafda tipik ssenarilər üçün optimal konfiqurasiyaları nəzərdən keçirək. Fayl adında hash olan statik məzmun üçün (bundle.abc123.js) immutable ilə 1 ilə qədər max-age təyin etmək olar. Nadir yenilənən API siyahıları üçün (kataloqlar, kateqoriyalar) — stale-while-revalidate ilə 5 dəqiqədən 1 saata qədər max-age.

Təhlükəsizlik haqqında xatırlamaq vacibdir: istifadəçinin şəxsi məlumatlarını ehtiva edən cavablar üçün həmişə private təyin edin. Bu direktiv olmadan, ümumi proksi (məs. korporativ) cavabı keşləyib başqa istifadəçiyə ötürə bilər. Autentifikasiya tokenləri və ödəniş məlumatları üçün no-store istifadə edin — hətta private keş də bu məlumatları diskdə saxlamamalıdır.

Keşlənmənin sazlanması

Cache-Control-un düzgünlüyünü yoxlamaq üçün Age başlığından (keşin neçə saniyə saxlanıldığı) və X-Cache-dən (hit/miss CDN-də) istifadə edin. Brauzerdə — Network sekmesi, Size sütunu “from disk cache” və ya “304 Not Modified” göstərir. Resurs keşlənməli, lakin hər dəfə yüklənirsə — serverin direktivlərinizlə birlikdə Cache-Control: no-cache və ya Pragma: no-cache əlavə edib-etmədiyini yoxlayın.