Cache-Control — यह क्या है, निर्देश और कैश प्रबंधन

Cache-Control क्या है?

Cache-Control एक HTTP हेडर है, जो HTTP/1.1 (RFC 7234) में मानकीकृत है, जो सर्वर को यह निर्दिष्ट करने की अनुमति देता है कि क्लाइंट, प्रॉक्सी और CDN प्रतिक्रिया को कैसे और कितने समय तक कैश कर सकते हैं। Expires (HTTP/1.0) के विपरीत, Cache-Control निर्देशों का उपयोग करता है — अल्पविराम से संयुक्त टेक्स्ट कमांड: Cache-Control: public, max-age=3600, must-revalidate। हेडर कैशिंग श्रृंखला में प्रत्येक लिंक पर सूक्ष्म नियंत्रण प्रदान करता है।

कैशिंग वेब और मोबाइल एप्लिकेशन प्रदर्शन के मूलभूत तंत्रों में से एक है। इसके बिना, प्रत्येक उपयोगकर्ता अनुरोध सीधे सर्वर पर जाएगा, जिससे अत्यधिक लोड और विलंबता होगी। Cache-Control तीन कैशिंग स्तरों को परिभाषित करता है: ब्राउज़र/एप्लिकेशन (निजी कैश), प्रॉक्सी सर्वर (साझा कैश), और CDN (वितरित कैश)। प्रत्येक स्तर निर्देशों की अलग-अलग व्याख्या करता है।

गलत Cache-Control कॉन्फ़िगरेशन प्रदर्शन समस्याओं के सबसे सामान्य कारणों में से एक है। बहुत आक्रामक कैशिंग से उपयोगकर्ता पुराना डेटा देखते हैं। बहुत कमज़ोर कैशिंग से सर्वर पर अत्यधिक अनुरोध और धीमी लोडिंग होती है। Akamai (2025) के अनुसार, स्थैतिक सामग्री के लिए Cache-Control को अनुकूलित करने से सर्वर लोड 70-90% कम हो जाता है और मोबाइल उपयोगकर्ताओं के लिए लोड समय 40-60% में सुधार होता है।

हेडर का इतिहास

Cache-Control HTTP/1.1 (RFC 2616, 1999) में Expires के प्रतिस्थापन के रूप में दिखाई दिया। Expires में एक मूलभूत समस्या थी: यह एक पूर्ण तिथि का उपयोग करता था जो सर्वर और क्लाइंट समय क्षेत्रों पर निर्भर करती थी। Cache-Control ने सापेक्ष समय (प्रतिक्रिया प्राप्त होने के क्षण से सेकंड में max-age) पर स्विच करके इस समस्या को हल किया। बाद में, RFC 7234 (2014) में, नए निर्देश जोड़े गए: स्थैतिक संपत्तियों के लिए immutable, विलंबित सत्यापन के लिए stale-while-revalidate और stale-if-error।

Cache-Control निर्देश

Cache-Control में तीन समूहों में विभाजित 10 से अधिक निर्देश शामिल हैं: अनुरोध निर्देश (क्लाइंट → सर्वर), प्रतिक्रिया निर्देश (सर्वर → क्लाइंट), और एक्सटेंशन। व्यवहार में, मोबाइल विकास 6-7 मुख्य प्रतिक्रिया निर्देशों का उपयोग करता है जो 95% कैशिंग परिदृश्यों को कवर करते हैं। आइए प्रत्येक को उदाहरणों और अनुशंसाओं के साथ देखें।

max-age सबसे महत्वपूर्ण निर्देश है। यह क्लाइंट को निर्दिष्ट समय के लिए सर्वर पर अनुरोध करने से रोकता है। स्थैतिक संपत्तियों (CSS, JS, इमेज) के लिए, max-age आमतौर पर 1 दिन से 1 वर्ष तक निर्धारित किया जाता है। API प्रतिक्रियाओं के लिए — 0 सेकंड (हमेशा ताज़ा डेटा) से 5-10 मिनट (संदर्भ डेटा) तक। s-maxage CDN और ब्राउज़र के लिए अलग-अलग जीवनकाल निर्धारित करने की अनुमति देता है: CDN 1 दिन के लिए एक प्रतिलिपि संग्रहीत करता है, ब्राउज़र 1 घंटे के लिए।

no-cache बनाम no-store

ये दो निर्देश अक्सर भ्रमित होते हैं। no-cache कैशिंग को प्रतिबंधित नहीं करता है — इसे प्रत्येक उपयोग पर सशर्त अनुरोध (If-Modified-Since या If-None-Match) के माध्यम से कैश की गई प्रतिलिपि को सत्यापित करने की आवश्यकता है। यदि सर्वर 304 के साथ प्रतिक्रिया करता है — क्लाइंट कैश का उपयोग करता है। यदि 200 — यह अपडेट करता है। दूसरी ओर, no-store, डिस्क और मेमोरी सहित किसी भी कैश में प्रतिक्रिया को सहेजने से पूरी तरह से प्रतिबंधित करता है। केवल संवेदनशील डेटा के लिए no-store का उपयोग करें — टोकन, भुगतान डेटा, व्यक्तिगत दस्तावेज़।

Cache-Control बनाम Expires

Expires हेडर (HTTP/1.0) भी संसाधन के जीवनकाल को निर्दिष्ट करता है लेकिन एक पूर्ण तिथि का उपयोग करता है: Expires: Thu, 03 Jul 2026 12:00:00 GMT. Cache-Control max-age प्रतिक्रिया के क्षण से सापेक्ष समय का उपयोग करता है। अंतर वितरित सिस्टम के लिए महत्वपूर्ण है: यदि सर्वर और क्लाइंट अलग-अलग समय क्षेत्रों में हैं, तो Expires की गलत व्याख्या की जा सकती है। Cache-Control में यह समस्या नहीं है — 3600 सेकंड हमेशा 3600 सेकंड होते हैं।

जब दोनों हेडर मौजूद होते हैं, Cache-Control की प्राथमिकता Expires पर होती है। यह RFC 7234 में परिभाषित है: “यदि प्रतिक्रिया में max-age निर्देश के साथ Cache-Control फ़ील्ड शामिल है, तो प्राप्तकर्ता को Expires फ़ील्ड को अनदेखा करना चाहिए।” व्यवहार में, आधुनिक क्लाइंट के लिए Expires को बिल्कुल भी वापस न करने की अनुशंसा की जाती है, क्योंकि Cache-Control सभी Expires परिदृश्यों को कवर करता है। हालांकि, पुराने प्रॉक्सी और ब्राउज़र के साथ पिछड़ी संगतता के लिए, दोनों हेडर वापस किए जा सकते हैं।

Expires मुख्य रूप से Nginx और Apache पर स्थैतिक सामग्री के लिए बचा है — ये सर्वर स्वचालित रूप से दोनों हेडर जोड़ते हैं। यदि आपका प्रोजेक्ट Cache-Control के बिना Expires का सामना करता है, तो इसे max-age के साथ Cache-Control से बदलें: कैश नियंत्रण सटीकता में सुधार होता है, और समय क्षेत्र पर निर्भरता समाप्त हो जाती है। माइग्रेशन के लिए, सर्वर को Expires के बजाय Cache-Control जोड़ने के लिए कॉन्फ़िगर करना पर्याप्त है।

# Nginx: स्थैतिक फ़ाइलों के लिए Cache-Control
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
    expires 30d;
    add_header Cache-Control "public, immutable, max-age=2592000";
}

# बिभिन्न प्रकार की सामग्री के लिए भिन्न नीतियाँ
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 कॉन्फ़िगरेशन में, स्थैतिक फ़ाइलों (CSS, JS, इमेज) को immutable विशेषता के साथ 30 दिनों के लिए Cache-Control पर सेट किया जाता है — यह विशेषता ब्राउज़र को बताती है कि संसाधन इस URL पर कभी नहीं बदलता है (फ़ाइल नाम में हैश के माध्यम से संस्करणीकरण)। API एंडपॉइंट गतिशील डेटा के लिए no-cache और संदर्भ डेटा के लिए छोटे max-age के साथ public का उपयोग करते हैं — अक्सर अनुरोधित और शायद ही कभी बदलने वाली सूचियाँ।

मोबाइल एप्लिकेशन में कैशिंग

मोबाइल एप्लिकेशन में, Cache-Control मोबाइल नेटवर्क की सीमाओं के कारण एक विशेष भूमिका निभाता है: उच्च विलंबता, अस्थिर कनेक्शन, ट्रैफ़िक सीमाएँ। उचित कैशिंग उपयोगकर्ता को तुरंत डेटा प्रदर्शित करने की अनुमति देती है, ऑफ़लाइन भी, और इसे पृष्ठभूमि में अपडेट करती है। Android पर OkHttp और iOS पर URLSession में अंतर्निहित कैशिंग सिस्टम हैं जो Cache-Control का सम्मान करते हैं।

OkHttp CacheInterceptor का उपयोग करता है, जो प्रतिक्रिया से Cache-Control पढ़ता है और स्वचालित रूप से कैशिंग प्रबंधित करता है। यदि सर्वर Cache-Control: max-age=3600 लौटाता है, तो OkHttp एक घंटे के लिए सर्वर पर अनुरोध नहीं करेगा। max-age समाप्त होने के बाद, OkHttp If-Modified-Since और If-None-Match के साथ एक सशर्त अनुरोध भेजता है। OkHttp में कैश कॉन्फ़िगरेशन: 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()
}

कोड 10 MB कैश के साथ एक OkHttpClient बनाता है और NetworkInterceptor के माध्यम से Cache-Control को ओवरराइड करता है। यदि सर्वर Cache-Control वापस नहीं करता है या Expires का उपयोग करता है, तो इंटरसेप्टर public, max-age=300 (5 मिनट) जोड़ता है। इंटरसेप्टर संगतता के लिए पुराने Pragma हेडर (HTTP/1.0) को हटा देता है। iOS पर कैशिंग memoryCapacity और diskCapacity सेटिंग्स के साथ URLCache.shared के माध्यम से समान रूप से काम करती है।

ऑफ़लाइन मोड और stale-while-revalidate

stale-while-revalidate निर्देश उपयोगकर्ता को पुराना कैश दिखाने की अनुमति देता है जबकि एप्लिकेशन पृष्ठभूमि में ताज़ा डेटा लाता है। यह तत्काल प्रतिक्रिया प्रभाव प्रदान करता है: उपयोगकर्ता तुरंत सामग्री देखता है, और एक सेकंड के बाद यह वर्तमान संस्करण में अपडेट हो जाता है। OkHttp संस्करण 3.10 और iOS 14+ पर URLCache द्वारा समर्थित। उदाहरण: Cache-Control: max-age=3600, stale-while-revalidate=300 — 1 घंटा ताज़ा कैश, फिर पृष्ठभूमि रीफ़्रेश के साथ 5 मिनट पुराना डेटा दिखाना।

Cache-Control कॉन्फ़िगरेशन उदाहरण

विभिन्न संसाधन प्रकारों को विभिन्न कैशिंग रणनीतियों की आवश्यकता होती है। आइए मोबाइल विकास में विशिष्ट परिदृश्यों के लिए इष्टतम कॉन्फ़िगरेशन देखें। फ़ाइल नाम में हैश वाली स्थैतिक सामग्री (bundle.abc123.js) के लिए, आप immutable के साथ max-age को 1 वर्ष तक सेट कर सकते हैं। शायद ही कभी अपडेट होने वाली API सूचियों (निर्देशिकाएँ, श्रेणियाँ) के लिए — stale-while-revalidate के साथ 5 मिनट से 1 घंटे तक max-age।

सुरक्षा याद रखना महत्वपूर्ण है: व्यक्तिगत उपयोगकर्ता डेटा वाली प्रतिक्रियाओं के लिए, हमेशा private सेट करें। इस निर्देश के बिना, एक सार्वजनिक प्रॉक्सी (उदा., कॉर्पोरेट) प्रतिक्रिया को कैश कर सकता है और इसे किसी अन्य उपयोगकर्ता को दे सकता है। प्रमाणीकरण टोकन और भुगतान जानकारी के लिए, no-store का उपयोग करें — निजी कैश को भी इस डेटा को डिस्क पर संग्रहीत नहीं करना चाहिए।

कैशिंग डिबगिंग

Cache-Control सहीता सत्यापित करने के लिए, Age हेडर (कैश कितने सेकंड से संग्रहीत है) और X-Cache (CDN पर hit/miss) का उपयोग करें। ब्राउज़र में — Network टैब, Size कॉलम “from disk cache” या “304 Not Modified” दिखाता है। यदि किसी संसाधन को कैश किया जाना चाहिए लेकिन हर बार लोड होता है, तो जांचें कि क्या सर्वर आपके निर्देशों के साथ Cache-Control: no-cache या Pragma: no-cache जोड़ रहा है।