ETag: यह क्या है, कैशिंग तंत्र और हेडर कॉन्फ़िगरेशन

ETag क्या है?

ETag (Entity Tag) एक HTTP प्रतिक्रिया हेडर है जिसमें संसाधन के एक विशिष्ट संस्करण के लिए एक अद्वितीय पहचानकर्ता होता है। सर्वर फ़ाइल सामग्री, उसके मेटाडेटा या संशोधन संख्या के आधार पर ETag की गणना करता है और GET अनुरोध के जवाब में इसे क्लाइंट को भेजता है। क्लाइंट इस पहचानकर्ता को सहेजता है और उसी संसाधन के बाद के अनुरोधों पर इसे If-None-Match हेडर में भेजता है। यदि संसाधन नहीं बदला है, तो सर्वर 304 Not Modified के साथ उत्तर देता है, और क्लाइंट अपनी कैश की गई प्रतिलिपि का उपयोग करता है।

ETag प्रारूप RFC 7232 में उद्धरण चिह्नों में एक स्ट्रिंग के रूप में परिभाषित किया गया है: "33a64df551425fcc55e4d42a148795d9f25f89d4"। मान फ़ाइल सामग्री का SHA-1 हैश, एक वृद्धिशील संस्करण संख्या, स्थिर फ़ाइलों के लिए inode-संख्या-समय का संयोजन, या सर्वर द्वारा उत्पन्न एक मनमाना टोकन हो सकता है। एकमात्र आवश्यकता यह है कि जब संसाधन बदलता है तो मान बदलना चाहिए और यदि संसाधन वही रहता है तो नहीं बदलना चाहिए।

ETag सशर्त अनुरोध तंत्र (conditional requests) से संबंधित है — HTTP प्रोटोकॉल के मूलभूत अनुकूलन में से एक। बिना शर्त अनुरोधों के विपरीत जहाँ सर्वर हमेशा पूर्ण प्रतिक्रिया लौटाता है, एक सशर्त अनुरोध क्लाइंट को डेटा को पुनः लोड किए बिना कैश प्रासंगिकता की जाँच करने की अनुमति देता है। HTTP Archive (2025) के अनुसार, सभी HTTP प्रतिक्रियाओं का लगभग 40% 304 Not Modified है, जो उचित ETag और Last-Modified कॉन्फ़िगरेशन के कारण है।

ETag का उपयोग कहाँ किया जाता है

ETag का उपयोग REST API में डेटा संग्रह के लोडिंग को अनुकूलित करने के लिए किया जाता है — यदि ऑब्जेक्ट सूची नहीं बदली है, तो क्लाइंट पूरे JSON को स्थानांतरित किए बिना 304 प्राप्त करता है। स्थिर फ़ाइलों (CSS, JS, इमेज) के लिए, ETag CDN और ब्राउज़रों को कैश ताज़गी को कुशलतापूर्वक जाँचने की अनुमति देता है। मोबाइल एप्लिकेशन में, ETag पृष्ठभूमि सिंक्रनाइज़ेशन के लिए महत्वपूर्ण है: ऐप जाँचता है कि सर्वर पर डेटा बदला है या नहीं और केवल आवश्यकता होने पर अपडेट डाउनलोड करता है। यह ट्रैफ़िक और डिवाइस की बैटरी बचाता है।

ETag कैसे काम करता है?

पूर्ण ETag जीवनचक्र चार चरणों से बना है। सर्वर पहले अनुरोध पर ETag उत्पन्न करता है और इसे प्रतिक्रिया हेडर में लौटाता है। क्लाइंट ETag को कैश किए गए संसाधन के साथ सहेजता है। बार-बार अनुरोध पर, क्लाइंट If-None-Match हेडर को सहेजे गए ETag मान के साथ भेजता है। सर्वर प्राप्त मान की तुलना वर्तमान संसाधन ETag से करता है: मिलान होने पर, यह खाली निकाय के साथ 304 Not Modified लौटाता है; मिलान न होने पर, यह नए संसाधन और नए ETag के साथ 200 OK लौटाता है।

// If-None-Match के साथ क्लाइंट अनुरोध
GET /api/users HTTP/1.1
Host: example.com
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

// सर्वर प्रतिक्रिया — संसाधन नहीं बदला
HTTP/1.1 304 Not Modified
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

मोबाइल एप्लिकेशन में, यह चक्र कैशिंग समर्थन वाले HTTP क्लाइंट के माध्यम से कार्यान्वित किया जा सकता है। OkHttp, उदाहरण के लिए, CacheInterceptor के माध्यम से स्वचालित रूप से ETag का प्रबंधन करता है: यह प्रतिक्रिया ETag को सहेजता है और बार-बार अनुरोधों पर If-None-Match जोड़ता है। 304 प्राप्त करने पर, OkHttp कैश किए गए डेटा को लौटाता है। OkHttp अतिरिक्त कॉन्फ़िगरेशन के बिना ETag का समर्थन करता है — बस OkHttpClient.Builder.cache() के माध्यम से कैश सक्षम करें।

सर्वर पर ETag जनरेशन

सर्वर ETags की गणना विभिन्न तरीकों से कर सकता है: सामग्री के MD5 या SHA हैश के माध्यम से, डेटाबेस से संशोधन संख्या के माध्यम से (जैसे MySQL से updated_at), स्थिर फ़ाइलों के लिए inode + mtime + आकार के संयोजन के माध्यम से (Nginx इसी तरह ETags उत्पन्न करता है)। गतिशील API के लिए, कंटेंट हैश सबसे विश्वसनीय है: यदि JSON प्रतिक्रिया में एक भी फ़ील्ड बदलती है, तो ETag बदल जाएगा। हालाँकि, प्रत्येक अनुरोध पर हैश की गणना करना CPU पर भार डालता है — उच्च-लोड सिस्टम के लिए, वृद्धिशील संस्करण संख्या का उपयोग करना बेहतर है।

मजबूत और कमजोर ETag

RFC 7232 दो प्रकार के ETags को परिभाषित करता है: मजबूत (strong) और कमजोर (weak)। एक मजबूत ETag का अर्थ है कि संसाधन के दो प्रतिनिधित्व बाइट-दर-बाइट समान हैं — एक भी बिट भिन्न नहीं है। एक कमजोर ETag (उपसर्ग W/) केवल शब्दार्थ समानता की गारंटी देता है: सामग्री क्रमांकन स्तर (रिक्त स्थान, JSON फ़ील्ड क्रम) पर भिन्न हो सकती है, लेकिन डेटा क्लाइंट के लिए समान माना जाता है। कमजोर ETags को W/ उपसर्ग से चिह्नित किया जाता है, उदाहरण के लिए W/"1a2b3c"।

ETag प्रकार का चुनाव तुलना सटीकता आवश्यकताओं पर निर्भर करता है। स्थिर फ़ाइलों (CSS, JS, इमेज) के लिए, मजबूत ETags बेहतर हैं — यदि फ़ाइल बदली है, तो क्लाइंट को नया संस्करण प्राप्त करना चाहिए। गतिशील API के लिए, जहाँ समान JSON को विभिन्न फ़ील्ड क्रम या स्वरूपण के साथ क्रमांकित किया जा सकता है, कमजोर ETags अधिक लचीलापन प्रदान करते हैं: सर्वर स्ट्रिंग प्रतिनिधित्व के बजाय व्यावसायिक डेटा के आधार पर ETag उत्पन्न करता है।

कमजोर ETags की एक सीमा: इनका उपयोग रेंज अनुरोधों (Range requests) के साथ नहीं किया जा सकता। यदि क्लाइंट फ़ाइल का एक भाग अनुरोध करता है, तो सर्वर को यह गारंटी देने के लिए एक मजबूत ETag वापस करना होगा कि खंड पूर्ण संसाधन के अनुरूप है। कमजोर ETags ऐसी गारंटी प्रदान नहीं करते। अन्य परिदृश्यों में, कमजोर ETags सुरक्षित हैं और API के लिए अनुशंसित हैं।

ETag बनाम Last-Modified

ETag और Last-Modified सशर्त अनुरोधों के लिए दो HTTP हेडर हैं जिनका उपयोग अक्सर एक साथ किया जाता है। Last-Modified संसाधन के अंतिम संशोधन की तारीख इंगित करता है और If-Modified-Since हेडर के साथ काम करता है। ETag एक अद्वितीय संस्करण पहचानकर्ता प्रदान करता है और If-None-Match के साथ काम करता है। प्रत्येक के अपने लाभ और सीमाएँ हैं, और उन्हें संयोजित करने से अधिकतम कैशिंग दक्षता मिलती है।

Last-Modified कार्यान्वयन में सरल है — सर्वर स्वचालित रूप से फ़ाइल सिस्टम से तारीख प्राप्त करता है या डेटाबेस में updated_at फ़ील्ड को अपडेट करता है। हालाँकि, तारीख में सेकंड-स्तरीय सटीकता है, जो उन संसाधनों के लिए अपर्याप्त है जो प्रति सेकंड कई बार बदलते हैं। इसके अलावा, Last-Modified विभिन्न अवस्थाओं के बीच अंतर नहीं करता: यदि किसी फ़ाइल को उसी संस्करण के साथ अधिलेखित किया जाता है, तो तारीख बदलती है लेकिन सामग्री नहीं बदलती, इसलिए क्लाइंट समान डेटा को पुनः लोड करेगा।

ETag अधिक सटीक है: यह केवल तभी बदलता है जब सामग्री वास्तव में बदलती है। यदि सर्वर बैकअप से पिछला संस्करण पुनर्स्थापित करता है, तो ETag बदलता है। यदि किसी फ़ाइल को उसी डेटा के साथ अधिलेखित किया जाता है, तो ETag वही रहता है, और क्लाइंट पुनः लोड नहीं करता। संयुक्त उपयोग HTTP विशिष्टता द्वारा अनुशंसित है: सर्वर दोनों हेडर लौटाता है, क्लाइंट If-None-Match और If-Modified-Since एक साथ भेजता है। यदि कम से कम एक हेडर परिवर्तन इंगित करता है, तो सर्वर एक नया संसाधन लौटाता है।

हेडर प्राथमिकता

विशिष्टता के अनुसार, ETag की Last-Modified पर प्राथमिकता है। यदि सर्वर को If-None-Match प्राप्त होता है, तो उसे केवल ETag की जाँच करनी चाहिए, If-Modified-Since को अनदेखा करते हुए। यह दौड़ की स्थिति (race condition) को रोकता है: यदि क्लाइंट द्वारा Last-Modified भेजने और सर्वर पर जाँच के बीच संसाधन बदल गया, तो ETag ताज़ा संकेतक होगा। व्यवहार में, सर्वर आमतौर पर दोनों हेडर की जाँच करते हैं, लेकिन जब परिणाम बेमेल होते हैं, तो ETag जीतता है।

सर्वर पर ETag कार्यान्वयन

ETag कॉन्फ़िगरेशन सर्वर प्रकार पर निर्भर करता है। Nginx स्थिर फ़ाइलों के लिए स्वचालित रूप से inode, mtime और आकार के आधार पर ETags उत्पन्न करता है। Apache FileETag तंत्र का उपयोग करता है। Node.js, PHP, Python, Ruby पर गतिशील एप्लिकेशन के लिए, ETags को प्रोग्रामेटिक रूप से उत्पन्न करने की आवश्यकता होती है — प्रतिक्रिया हैश, डेटा संस्करण संख्या, या अनुरोध पैरामीटर के संयोजन के माध्यम से।

func etagMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter,
        r *http.Request) {
        // डेटा के आधार पर ETag जनरेशन
        etag := generateETag(r.URL.Path)
        w.Header().Set("ETag", etag)

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

Go में Middleware अनुरोध को रोकता है, अनुरोधित URL के लिए ETag उत्पन्न करता है (उदाहरण के लिए, कैश या DB से डेटा हैश की गणना करता है) और प्रतिक्रिया हेडर सेट करता है। यदि क्लाइंट ने If-None-Match भेजा और यह वर्तमान ETag से मेल खाता है, तो सर्वर मुख्य हैंडलर को कॉल किए बिना तुरंत 304 Not Modified लौटाता है। उत्पादन में, सर्वर लोड को कम करने के लिए URL और पैरामीटर द्वारा गणना किए गए ETags की कैशिंग जोड़नी चाहिए।

समस्याएँ और नुकसान

मल्टी-सर्वर कॉन्फ़िगरेशन (round-robin या anycast) में, ETag एक ही संसाधन के लिए सभी नोड्स पर समान होना चाहिए। यदि ETag फ़ाइल inode के आधार पर उत्पन्न होता है और साइट कई सर्वरों पर तैनात है, तो मान भिन्न होंगे। समाधान कंटेंट हैश या केंद्रीकृत संस्करण भंडारण (Redis, etcd) का उपयोग करना है। दूसरी समस्या gzip संपीड़न है: जब संपीड़न सक्षम होता है तो Nginx ETag बदलता है, जो अनावश्यक 304 प्रतिक्रियाओं का कारण बन सकता है। संपीड़ित सामग्री के साथ ETag को सिंक्रनाइज़ करने के लिए gzip_vary on कॉन्फ़िगर करना आवश्यक है।