HTTP Caching-related headers
केसिंग से संबंधित हेडर सरवर भेजता है या क्लाइंट या दोनों? और यह कितने तरह का केसिंग हेडर हो सकता है?
HTTP/1.1 में कैशिंग से संबंधित हेडर क्लाइंट और सर्वर दोनों भेज सकते हैं, यह इस बात पर निर्भर करता है कि हेडर का उद्देश्य क्या है। कैशिंग हेडर का उपयोग यह नियंत्रित करने के लिए किया जाता है कि संसाधन (resources) को कैसे और कब कैश करना है, ताकि डेटा ट्रांसफर को अनुकूलित किया जा सके और प्रदर्शन बेहतर हो। नीचे इसे विस्तार से समझाया गया है:
कौन भेजता है: क्लाइंट, सर्वर, या दोनों?
सर्वर:
- सर्वर कैशिंग से संबंधित हेडर भेजता है ताकि क्लाइंट (या मध्यस्थ प्रॉक्सी) को यह बताया जा सके कि संसाधन को कैसे कैश करना है, कितने समय तक कैश रखना है, और क्या यह कैश योग्य है।
- उदाहरण:Cache-Control, ETag, Expires, Last-Modified।
क्लाइंट:
- क्लाइंट कैशिंग से संबंधित हेडर भेजता है ताकि सर्वर को यह बताया जा सके कि उसके पास पहले से कैश किया हुआ संसाधन है या नहीं, और वह संसाधन की वैधता (validity) की जांच करना चाहता है।
- उदाहरण:If-None-Match, If-Modified-Since, Cache-Control।
दोनों:
- कुछ हेडर, जैसेCache-Control, क्लाइंट और सर्वर दोनों भेज सकते हैं, लेकिन उनका उद्देश्य संदर्भ के आधार पर अलग होता है।
- क्लाइंट इसे रिक्वेस्ट में अपनी कैशिंग प्राथमिकताएं बताने के लिए उपयोग करता है (जैसे, केवल कैश से डेटा चाहिए)।
- सर्वर इसे रिस्पांस में कैशिंग नियम (policies) निर्दिष्ट करने के लिए उपयोग करता है।
कैशिंग से संबंधित हेडर के प्रकार
HTTP/1.1 में कैशिंग से संबंधित कई हेडर हैं, जिन्हें उनके उद्देश्य के आधार पर निम्नलिखित श्रेणियों में बांटा जा सकता है:
कैश नियंत्रण हेडर (Cache Control Headers):
हेडर: Cache-Control
कौन भेजता है: क्लाइंट और सर्वर दोनों।
उद्देश्य: कैशिंग के नियम और व्यवहार को नियंत्रित करता है।
मुख्य निर्देश (Directives):
- सर्वर द्वारा:
- public: संसाधन को कोई भी कैश (ब्राउज़र, प्रॉक्सी) स्टोर कर सकता है।
- private: केवल क्लाइंट (जैसे ब्राउज़र) कैश कर सकता है, प्रॉक्सी नहीं।
- no-cache: कैश तो हो सकता है, लेकिन हर बार सर्वर से वैधता की जांच करनी होगी।
- no-store: संसाधन को बिल्कुल कैश नहीं करना है।
- max-age=<seconds>: कैश कितने सेकंड तक वैध रहेगा।
- s-maxage=<seconds>: साझा (shared) प्रॉक्सी कैश के लिए वैधता समय।
- must-revalidate: कैश पुराना होने पर सर्वर से पुन: सत्यापन जरूरी।
- क्लाइंट द्वारा:
- max-age=<seconds>: क्लाइंट को कितना पुराना कैश स्वीकार्य है।
- no-cache: क्लाइंट केवल सर्वर-वैध डेटा चाहता है।
- no-store: क्लाइंट नहीं चाहता कि डेटा कैश हो।
- उदाहरण:
- सर्वर:Cache-Control: max-age=3600, public (संसाधन 1 घंटे तक कैश योग्य)।
- क्लाइंट:Cache-Control: no-cache (केवल ताज़ा डेटा चाहिए)।
संसाधन पहचान हेडर (Resource Identification Headers):
- हेडर: ETag
- कौन भेजता है:
- सर्वर: रिस्पांस मेंETag भेजता है।
- क्लाइंट: रिक्वेस्ट मेंIf-None-Match के साथ ETag भेजता है।
- उद्देश्य: संसाधन के विशिष्ट संस्करण की पहचान करता है, ताकि यह जांचा जा सके कि कैश किया हुआ संसाधन अभी भी वैध है।
- उदाहरण:
- सर्वर:ETag: "abc123"।
- क्लाइंट:If-None-Match: "abc123" → अगर मेल खाता है, तो 304 Not Modified।
टाइम-आधारित वैधता हेडर (Time-Based Validation Headers):
- हेडर: Last-Modified, If-Modified-Since
- कौन भेजता है:
- सर्वर: रिस्पांस मेंLast-Modified भेजता है (संसाधन की आखिरी बार संशोधन तारीख)।
- क्लाइंट: रिक्वेस्ट मेंIf-Modified-Since भेजता है।
- उद्देश्य: यह जांचता है कि संसाधन क्लाइंट के कैश के बाद बदला है या नहीं।
- उदाहरण:
- सर्वर:Last-Modified: Wed, 13 Apr 2025 10:00:00 GMT।
- क्लाइंट:If-Modified-Since: Wed, 13 Apr 2025 10:00:00 GMT → अगर नहीं बदला, तो 304 Not Modified।
समाप्ति हेडर (Expiration Headers):
- हेडर: Expires
कौन भेजता है: सर्वर।
उद्देश्य: यह बताता है कि संसाधन कब तक कैश में वैध रहेगा। यह एक निश्चित तारीख और समय देता है।
उदाहरण:
- सर्वर:Expires: Thu, 14 Apr 2025 10:00:00 GMT (संसाधन इस समय तक वैध)।
नोट: Cache-Control: max-ageको प्राथमिकता दी जाती है, क्योंकि यह अधिक लचीला है।
कंडीशनल रिक्वेस्ट हेडर (Conditional Request Headers):
हेडर: If-Match, If-None-Match, If-Range
कौन भेजता है: क्लाइंट।
उद्देश्य: कैश वैधता की जांच या रेंज रिक्वेस्ट के लिए शर्तें निर्धारित करता है।
उदाहरण:
- If-Match: "abc123": संसाधन का ETag मेल खाने पर ही रिक्वेस्ट प्रोसेस हो।
- If-Range: "abc123": रेंज रिक्वेस्ट के लिए ETag जांच।
अन्य संबंधित हेडर:
हेडर: Vary
कौन भेजता है: सर्वर।
उद्देश्य: यह बताता है कि कैश्ड संसाधन किन हेडर (जैसेAccept-Language) के आधार पर अलग-अलग हो सकता है।
उदाहरण:
- Vary: Accept-Encoding(कैश्ड संसाधन संपीड़न के आधार पर अलग होगा)।
हेडर: Pragma
कौन भेजता है: क्लाइंट (पुराना, HTTP/1.0 से)।
उद्देश्य: Pragma: no-cacheपुराने सिस्टम में Cache-Control: no-cache की तरह काम करता है।
कुल कितने प्रकार के कैशिंग हेडर?
कैशिंग से संबंधित हेडर को उनके कार्यों के आधार पर निम्नलिखित प्रकारों में बांटा जा सकता है:
- कैश नियंत्रण: Cache-Control, Pragma।
- संसाधन पहचान: ETag, If-None-Match, If-Match।
- टाइम-आधारित वैधता: Last-Modified, If-Modified-Since।
- समाप्ति: Expires।
- कंडीशनल रिक्वेस्ट: If-Range।
- वैरिएशन नियंत्रण: Vary।
कुल मिलाकर, ये6 श्रेणियां हैं, जिनमें कई हेडर शामिल हैं। प्रत्येक हेडर का विशिष्ट उपयोग होता है, और ये एक साथ मिलकर कैशिंग को लचीला और शक्तिशाली बनाते हैं।
उदाहरण:
सर्वर रिस्पांस:text
HTTP/1.1 200 OK
Cache-Control: max-age=3600, public
ETag: "xyz789"
Last-Modified: Wed, 13 Apr 2025 10:00:00 GMT
Expires: Thu, 14 Apr 2025 10:00:00 GMT
Vary: Accept-Encoding
- यह संसाधन 1 घंटे तक कैश योग्य है, ETag और Last-Modified के साथ वैधता जांच हो सकती है।
GET /resource
If-None-Match: "xyz789"
If-Modified-Since: Wed, 13 Apr 2025 10:00:00 GMT
Cache-Control: no-cache
- क्लाइंट पूछ रहा है कि क्या संसाधन बदला है, और वह ताज़ा डेटा चाहता है।
आधुनिक संदर्भ:
- HTTP/2 और HTTP/3 में भी यही कैशिंग हेडर उपयोग होते हैं, लेकिन HTTP/2 की मल्टीप्लेक्सिंग और HTTP/3 की QUIC-आधारित गति कैशिंग की कुछ जरूरतों को कम करती है।
- Cache-Controlसबसे ज्यादा उपयोग होने वाला हेडर है, क्योंकि यह सबसे लचीला और शक्तिशाली है।
संक्षेप में:
- कौन भेजता है? क्लाइंट और सर्वर दोनों कैशिंग हेडर भेजते हैं। सर्वर नियम बताता है (Cache-Control, ETag, Expires), और क्लाइंट वैधता जांचता है (If-None-Match, If-Modified-Since)।
- प्रकार: कैशिंग हेडर को 6 श्रेणियों में बांटा जा सकता है: कैश नियंत्रण, संसाधन पहचान, टाइम-आधारित वैधता, समाप्ति, कंडीशनल रिक्वेस्ट, और वैरिएशन नियंत्रण।
- ये हेडर मिलकर कैशिंग को कुशल बनाते हैं, जिससे बैंडविड्थ बचती है और वेब प्रदर्शन बेहतर होता है।
टिप्पणियाँ
एक टिप्पणी भेजें