ETag: bu nədir, keşləmə mexanizmi və başlığın konfiqurasiyası

ETag nədir?

ETag (Entity Tag) — resursun müəyyən versiyasının unikal identifikatorunu ehtiva edən HTTP cavab başlığıdır. Server faylın məzmununa, onun metadatanına və ya reviziya nömrəsinə əsasən ETag hesablayır və onu GET sorğusuna cavab olaraq müşteriyə ötürür. Müşteri bu identifikatoru saxlayır və eyni resursa növbəti sorğularda onu If-None-Match başlığında göndərir. Resurs dəyişməyibsə, server 304 Not Modified cavabı verir və müşteri öz keşlənmiş surətindən istifadə edir.

ETag formatı RFC 7232-də dırnıq içərisində sətir kimi müəyyən edilmişdir: "33a64df551425fcc55e4d42a148795d9f25f89d4". Qiymət faylın məzmununun SHA-1 heşi, artımlı versiya nömrəsi, statik fayllar üçün inode-nömrə-zaman kombinasiyası və ya server tərəfindən yaradılan ixtiyari token ola bilər. Yeganə tələb odur ki, qiymət resursun hər dəyişikliyində dəyişməli və resurs eyni qaldıqda dəyişməməlidir.

ETag şərti sorğular (conditional requests) mexanizminə aiddir — HTTP protokolunun əsas optimallaşdırmalarından biri. Serverin həmiş tam cavab qaytardığı qeyd-şərtsiz sorğulardan fərqli olaraq, şərti sorğu müşteriyə məlumatları yenidən endirmədən keşin aktuallığını yoxlamağa imkan verir. HTTP Archive (2025) məlumatlarına görə, bütün HTTP cavablarının təxminən 40%-ı ETag və Last-Modified-in düzgün konfiqurasiyası sayəsində 304 Not Modified-dir.

ETag harada tətbiq olunur

ETag REST API-də məlumat kolleksiyalarının yüklənməsini optimallaşdırmaq üçün istifadə olunur — obyektlərin siyahısı dəyişməyibsə, müşteri bütün JSON-u göndərmədən 304 alır. Statik fayllarda (CSS, JS, şəkillər) ETag CDN və brauzerlərə keşin aktuallığını effektiv yoxlamağa imkan verir. Mobil tətbiqlərdə ETag fon sinxronizasiyası üçün kritikdir: tətbiq serverdəki məlumatların dəyişilib-dəyişmədiyini yoxlayır və yeniləmələri yalnız zərurət olduqda endirir. Bu, trafikə və cihazın batareyasına qənaət edir.

ETag necə işləyir?

ETag-in tam işləmə dövri dörd addımdan ibarətdir. Server ilk sorğuda ETag yaradır və onu cavab başlığında qaytarır. Müşteri ETag-i keşlənmiş resursla birlikdə saxlayır. Təkrari sorğuda müşteri If-None-Match başlığında saxlanılmış ETag-in dəyərini göndərir. Server alınan dəyəri resursun cari ETag-i ilə müqayisə edir: uyğunluq halında boş gövdə ilə 304 Not Modified, uyğunsuzluq halında isə yeni resurs və yeni ETag ilə 200 OK qaytarır.

// Müşterinin If-None-Match ilə sorğusu
GET /api/users HTTP/1.1
Host: example.com
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

// Server cavabı — resurs dəyişməyib
HTTP/1.1 304 Not Modified
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Mobil tətbiqdə bu dövrü keşləmə dəstəyi olan HTTP müşterisi vasitəsilə həyata keçirmək olar. OkHttp, məsələn, CacheInterceptor vasitəsilə ETag-i avtomatik idarə edir: cavabın ETag-ini saxlayır və təkrari sorğuda If-None-Match əlavə edir. 304 aldıqda OkHttp keşlənmiş məlumatları qaytarır. OkHttp əlavə konfiqurasiya olmadan ETag-i dəstəkləyir — OkHttpClient.Builder.cache() vasitəsilə keşi aktivləşdirmək kifayətdir.

Serverdə ETag-in yaradılması

Server ETag-i müxtəlif üsullarla hesablaya bilər: məzmunun MD5 və ya SHA heşi ilə, verilənlər bazasından reviziya nömrəsi ilə (məsələn, MySQL-dən updated_at), statik fayllar üçün inode + mtime + size kombinasiyası ilə (Nginx ETag-i məhz belə yaradır). Dinamik API-lər üçün ən etibarlısı məzmun heşidir: JSON cavabı heç olmasa bir sahəni dəyişdirsə, ETag dəyişəcək. Lakin hər sorğuda heşin hesablanması CPU-nu yükləyir — yüksək yüklü sistemlər üçün artımlı versiya nömrəsindən istifadə etmək daha yaxşıdır.

Güclü və zəif ETag

RFC 7232 iki növ ETag müəyyən edir: güclü (strong) və zəif (weak). Güclü ETag o deməkdir ki, resursun iki təqdimatı bayt-bayta eynidir — heç bir bit fərqlənmir. Zəif ETag (W/ prefiksi) yalnız semantik ekvivalentliyi təmin edir: məzmun serializasiya səviyyəsində fərqlənə bilər (boşluqlar, JSON sahələrinin sırası), lakin müşteri üçün məlumatlar eyni sayılır. Zəif ETag W/ prefiksi ilə qeyd olunur, məsələn W/"1a2b3c".

ETag növünün seçimi müqayisənin dəqiqlik tələblərindən asılıdır. Statik fayllar üçün (CSS, JS, şəkillər) güclü ETag üstünlük təşkil edir — fayl dəyişdisə, müşteri yeni versiyanı almalıdır. Dinamik API-lər üçün, eyni JSON-un sahələrin müxtəlif sırası və ya formatlaşdırma ilə serializasiya oluna bildiyi hallarda, zəif ETag daha çox elastiklik verir: server ETag-i sətir təqdimatına deyil, biznes məlumatlarına əsasən yaradır.

Zəif ETag-lərin məhdudiyyəti: onlar diapozon sorğuları (Range requests) ilə istifadə edilə bilməz. Müşteri faylın bir hissəsini tələb edərsə, server fraqmentin tam resursa uyğun olduğuna zəmanət vermək üçün güclü ETag qaytarmalıdır. Zəif ETag belə bir zəmanət vermir. Digər ssenarilərdə zəif ETag təhlükəsizdir və API-lər üçün tövsiyə olunur.

ETag vs Last-Modified

ETag və Last-Modified şərti sorğular üçün tez-tez birlikdə istifadə olunan iki HTTP başlığıdır. Last-Modified resursun son dəyişiklik tarixini göstərir və If-Modified-Since başlığı ilə işləyir. ETag versiyanın unikal identifikatorunu təmin edir və If-None-Match ilə işləyir. Hər birinin öz üstünlükləri və məhdudiyyətləri var, kombinasiya isə maksimum keşləmə effektivliyi verir.

Last-Modified tətbiq etmək daha sadədir — server avtomatik olaraq tarixi fayl sistemindən alır və ya verilənlər bazasında updated_at sahəsini yeniləyir. Lakin tarixin dəqiqliyi saniyəyə qədərdir ki, bu da saniyədə bir neçə dəfə dəyişən resurslar üçün kifayət deyil. Bundan əlavə, Last-Modified müxtəlif vəziyyətləri fərqləndirmir: fayl eyni versiya ilə yenidən yazılarsa, tarix dəyişir, lakin məzmun dəyişmir — müşteri eyni məlumatları yenidən yükləyir.

ETag daha dəqiqdir: yalnız məzmunun real dəyişikliyində dəyişir. Server ehtiyyat nüsxəsindən əvvəlki versiyanı bərpa edərsə, ETag dəyişəcək. Fayl eyni məlumatlarla yenidən yazılarsa — ETag eyni qalacaq və müşteri yenidən yükləməyəcək. Birgə istifadə HTTP spesifikasiyası tərəfindən tövsiyə olunur: server hər iki başlığı qaytarır, müşteri If-None-Match və If-Modified-Since-i eyni anda göndərir. Heç olmasa bir başlıq dəyişiklik göstərərsə — server yeni resurs qaytarır.

Başlıqların prioriteti

Spesifikasiyaya görə, ETag Last-Modified-ə nəzərən prioritetə malikdir. Server If-None-Match alıbsa, If-Modified-Since-i nəzərə almadan yalnız ETag-i yoxlamalıdır. Bu, race condition-un qarşısını alır: resurs müşterinin Last-Modified göndərməsi ilə serverdə yoxlama arasında dəyişdisə, ETag daha təzə göstərici olacaq. Praktikada serverlər adətən hər iki başlığı yoxlayır, lakin nəticələr uyğunsuz olduqda ETag qalib gəlir.

Serverdə ETag-in tətbiqi

ETag konfiqurasiyası serverin növündən asılıdır. Nginx statik fayllar üçün ETag-i avtomatik olaraq inode, mtime və ölçüyə əsasən yaradır. Apache FileETag mexanizmindən istifadə edir. Node.js, PHP, Python, Ruby-də dinamik tətbiqlər üçün ETag proqram üsulu ilə — cavabın heşi, məlumat versiya nömrəsi və ya sorğu parametrlərinin kombinasiyası vasitəsilə yaradılmalıdır.

func etagMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter,
        r *http.Request) {
        // Məlumatlar əsasında ETag-in yaradılması
        etag := generateETag(r.URL.Path)
        w.Header().Set("ETag", etag)

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

Go middleware-i sorğunu tutur, tələb olunan URL üçün ETag yaradır (məsələn, keşdən və ya verilənlər bazasından məlumatların heşini hesablayır) və cavab başlığını təyin edir. Müşteri If-None-Match göndəribsə və o, cari ETag ilə uyğunlaşırsa, server dərhal 304 Not Modified qaytarır, əsas emalçını çağırmadan. İstehsal mühitində server yükünü azaltmaq üçün hesablanmış ETag-lərin URL və parametrlər üzrə keşlənməsi əlavə edilməlidir.

Problemlər və tələlər

Çoxserverli konfiqurasiyada (round-robin və ya anycast) ETag eyni resurs üçün bütün qovşaqlarda eyni olmalıdır. ETag faylın inode-na əsasən yaradılırsa və sayt bir neçə serverdə işləyirsə, qiymətlər fərqli olacaq. Həll — məzmun heşindən və ya mərkəzləşdirilmiş versiya saxlanmasından (Redis, etcd) istifadə etməkdir. İkinci problem — gzip sıxılması: Nginx sıxılma aktiv olduqda ETag-i dəyişdirir, bu da lazımsız 304-ə səbəb ola bilər. ETag-in sıxılmış məzmunla sinxronizasiyası üçün gzip_vary on konfiqurasiyası tələb olunur.