कॉन्टेंट डिलीवरी नेटवर्क (सीडीएन)

कॉन्टेंट डिलीवरी नेटवर्क का इस्तेमाल करके परफ़ॉर्मेंस को बेहतर बनाएं.

Katie Hempenius

कॉन्टेंट डिलीवरी नेटवर्क (सीडीएन) से उपयोगकर्ताओं को संसाधन उपलब्ध कराने के लिए, सर्वर के डिस्ट्रिब्यूटेड नेटवर्क का इस्तेमाल करके, साइट की परफ़ॉर्मेंस बेहतर होती है. सीडीएन से सर्वर का लोड कम होता है, इसलिए वे सर्वर के खर्च को कम करते हैं. साथ ही, ये ट्रैफ़िक में होने वाली बढ़ोतरी को मैनेज करने में भी मदद करते हैं. इस लेख में बताया गया है कि सीडीएन कैसे काम करते हैं. साथ ही, इसमें सीडीएन सेटअप को चुनने, कॉन्फ़िगर करने, और ऑप्टिमाइज़ करने के लिए प्लैटफ़ॉर्म-एग्नेटिक निर्देश दिए गए हैं.

खास जानकारी

कॉन्टेंट डिलीवरी नेटवर्क (सीडीएन) में सर्वर का एक नेटवर्क होता है. इसे उपयोगकर्ताओं को कॉन्टेंट जल्दी डिलीवर करने के लिए ऑप्टिमाइज़ किया जाता है. हालांकि, सीडीएन, कैश मेमोरी में सेव किया गया कॉन्टेंट दिखाने के लिए सबसे ज़्यादा जाने जाते हैं. हालांकि, सीडीएन, कैश न किए जा सकने वाले कॉन्टेंट की डिलीवरी को बेहतर बना सकते हैं. आम तौर पर, आपकी साइट जितनी ज़्यादा सीडीएन से डिलीवर की जाएगी उतना ही बेहतर है.

सीडीएन के परफ़ॉर्मेंस से जुड़े कई सिद्धांत हैं: सीडीएन सर्वर, ऑरिजिन सर्वर के बजाय उपयोगकर्ताओं के आस-पास होते हैं. इसलिए, उनका राउंड ट्रिप समय (आरटीटी) कम होता है. नेटवर्किंग ऑप्टिमाइज़ेशन से सीडीएन को ऑरिजिन सर्वर से कॉन्टेंट "सीधे लोड करने" की तुलना में ज़्यादा जल्दी कॉन्टेंट डिलीवर करने में मदद मिलती है. सीडीएन सर्वर, कैश मेमोरी में सेव करने के अनुरोध की ज़रूरत को खत्म कर देते हैं.

मुख्य शब्द: ऑरिजिन सर्वर वह सर्वर होता है जिससे सीडीएन कॉन्टेंट फ़ेच करता है.

संसाधन वितरण

हालांकि, यह समझने में आसान नहीं लगता है, फिर भी उपयोगकर्ता को आपके सर्वर से "सीधे" संसाधन लोड करने के मुकाबले, आम तौर पर संसाधनों को डिलीवर करने के लिए सीडीएन का इस्तेमाल करना चाहिए (यहां तक कि कैश न किए जा सकने वाले भी).

जब ऑरिजिन से संसाधन डिलीवर करने के लिए सीडीएन का इस्तेमाल किया जाता है, तो क्लाइंट और आस-पास के सीडीएन सर्वर के बीच एक नया कनेक्शन बन जाता है. बाकी का हिस्सा (दूसरे शब्दों में, सीडीएन सर्वर और ऑरिजिन के बीच डेटा ट्रांसफ़र), सीडीएन के नेटवर्क से होता है. इसमें अक्सर ऑरिजिन के साथ पहले से मौजूद और स्थायी कनेक्शन शामिल होते हैं. इसके दो फ़ायदे हैं: उपयोगकर्ता से नए कनेक्शन को जितना संभव हो सके खत्म करने पर, कनेक्शन सेटअप करने में आने वाले ग़ैर-ज़रूरी खर्च नहीं होते हैं (नया कनेक्शन बनाना महंगा होता है और इसके लिए कई राउंडट्रिप की ज़रूरत होती है); पहले से गर्म कनेक्शन का इस्तेमाल करने से डेटा को तुरंत ट्रांसफ़र किया जा सकता है.

कुछ सीडीएन, ट्रैफ़िक को कई सीडीएन सर्वर के ज़रिए ऑरिजिन पर रूट करके और भी बेहतर बना देते हैं. सीडीएन सर्वर के बीच कनेक्शन, बॉर्डर गेटवे प्रोटोकॉल (बीजीपी) के तय किए गए रूट के बजाय, भरोसेमंद और बेहतर ऑप्टिमाइज़ किए गए रूट पर होते हैं. हालांकि, BGP इंटरनेट का असल रूटिंग प्रोटोकॉल है, लेकिन इसके रूटिंग से जुड़े फ़ैसले हमेशा परफ़ॉर्मेंस पर आधारित नहीं होते. इसलिए, सीडीएन सर्वर के बीच बेहतर बनाए गए रूट की तुलना में, बीजीपी के तय किए गए रूट की परफ़ॉर्मेंस कम हो सकती है.

कैश मेमोरी में सेव करना

किसी सीडीएन के सर्वर पर संसाधन को कैश मेमोरी में सेव करने से, सेवा पाने के लिए ऑरिजिन तक जाने के अनुरोध की ज़रूरत नहीं होती. इस वजह से, संसाधन ज़्यादा तेज़ी से डिलीवर होता है. इससे ऑरिजिन सर्वर पर लोड कम होता है.

कैश मेमोरी में संसाधन जोड़ना

सीडीएन कैश मेमोरी को पॉप्युलेट करने का सबसे ज़्यादा इस्तेमाल किया जाने वाला तरीका यह है कि ज़रूरत के हिसाब से सीडीएन "पुल" वाले रिसॉर्स का इस्तेमाल किया जाए - इसे "ऑरिजिन पुल" कहा जाता है. जब पहली बार किसी खास रिसॉर्स को कैश मेमोरी से अनुरोध किया जाता है, तो सीडीएन, ऑरिजिन सर्वर से उस रिसॉर्स का अनुरोध करेगा और रिस्पॉन्स को कैश मेमोरी में सेव करेगा. इस प्रकार से, समय के साथ-साथ कैश मेमोरी का कॉन्टेंट बनाया जाता है, क्योंकि कैश मेमोरी में सेव नहीं किए गए अतिरिक्त संसाधनों का अनुरोध किया जाता है.

कैश मेमोरी से संसाधनों को हटाना

सीडीएन, समय-समय पर कैश मेमोरी से ऐसे रिसॉर्स को हटाने के लिए कैश मेमोरी का इस्तेमाल करते हैं जो काम के नहीं हैं. इसके अलावा, साइट के मालिक संसाधनों को साफ़ तौर पर हटाने के लिए पर्जिंग का इस्तेमाल कर सकते हैं.

• कैश मेमोरी हटाना

  कैश मेमोरी में सेव होने की क्षमता सीमित होती है. जब कोई कैश मेमोरी अपनी क्षमता के आस-पास हो जाती है, तो यह ऐसे रिसॉर्स को हटा देता है जिन्हें हाल ही में ऐक्सेस नहीं किया गया है या जो बहुत ज़्यादा जगह लेते हैं. इससे नए रिसॉर्स के लिए जगह बन जाती है. इस प्रोसेस को कैश मेमोरी से डेटा मिटाना कहा जाता है. किसी संसाधन को एक कैश मेमोरी से हटाए जाने का मतलब यह नहीं होता कि उसे सीडीएन नेटवर्क में सभी कैश मेमोरी से हटा दिया गया है.

• पर्ज करना

  पर्ज करना (इसे "कैश अमान्य करना" भी कहा जाता है) किसी संसाधन को सीडीएन के कैश से हटाने या उसके खत्म होने का इंतज़ार किए बिना उसे हटाने का एक तरीका है. आम तौर पर, इसे एपीआई की मदद से एक्ज़ीक्यूट किया जाता है. पर्जिंग उन स्थितियों में महत्वपूर्ण होती है, जहां सामग्री को वापस लेने की आवश्यकता होती है (उदाहरण के लिए, टाइपिंग की गलतियां ठीक करना, कीमत संबंधी गड़बड़ियां या गलत समाचार लेख). इतना ही नहीं, यह किसी साइट को कैश मेमोरी में सेव करने की रणनीति में भी अहम भूमिका निभा सकता है.

  अगर किसी सीडीएन के आस-पास तुरंत पर्जिंग की सुविधा काम करती है, तो पर्जिंग का इस्तेमाल डाइनैमिक कॉन्टेंट को कैश मेमोरी में सेव करने के तरीके के तौर पर किया जा सकता है: एक लंबे टीटीएल का इस्तेमाल करके, डाइनैमिक कॉन्टेंट को कैश मेमोरी में सेव करें. इसके बाद, जब भी संसाधन को अपडेट किया जाए, तो उसे पूरी तरह मिटा दें. इस तरह, किसी डाइनैमिक रिसॉर्स के कैश मेमोरी में समय को ज़्यादा से ज़्यादा बढ़ाया जा सकता है. भले ही, यह पहले से पता न हो कि संसाधन कब बदलेगा. इस तकनीक को कभी-कभी "होल्ड-टू-टोल्ड कैश मेमोरी" भी कहा जाता है.

  जब बड़े पैमाने पर पर्जिंग का इस्तेमाल किया जाता है, तो आम तौर पर इसे "कैश टैग" या "सरोगेट कैश कीज़" नाम के कॉन्सेप्ट के साथ मिलाकर इस्तेमाल किया जाता है. इस तरीके की मदद से साइट के मालिक, कैश मेमोरी में सेव किए गए किसी संसाधन के साथ एक या उससे ज़्यादा अतिरिक्त आइडेंटिफ़ायर जोड़ सकते हैं. कभी-कभी, इन्हें "टैग" भी कहा जाता है. इन टैग का इस्तेमाल, डेटा को पूरी तरह से मिटाने के लिए किया जा सकता है. उदाहरण के लिए, उन सभी संसाधनों (उदाहरण के लिए, /about, /blog) में "फ़ुटर" टैग जोड़ा जा सकता है जिनमें आपकी साइट का फ़ुटर है. फ़ुटर अपडेट होने पर, अपने सीडीएन को "फ़ुटर" टैग से जुड़े सभी संसाधनों को पूरी तरह मिटाने का निर्देश दें.

कैश मेमोरी में सेव किए जा सकने वाले संसाधन

किसी संसाधन को कैश मेमोरी में सेव किया जाए या नहीं, यह इस बात पर निर्भर करता है कि वह सार्वजनिक है या निजी, स्टैटिक या डाइनैमिक है.

निजी और सार्वजनिक संसाधन

• निजी संसाधन

  निजी संसाधनों में एक उपयोगकर्ता के लिए लक्षित डेटा होता है और इसलिए किसी सीडीएन के ज़रिए कैश मेमोरी में सेव नहीं किया जाना चाहिए. निजी संसाधनों को Cache-Control: private हेडर से दिखाया जाता है.

• सार्वजनिक संसाधन

  सार्वजनिक संसाधनों में उपयोगकर्ता से जुड़ी कोई खास जानकारी नहीं होती. इसलिए, इन्हें सीडीएन के ज़रिए कैश मेमोरी में सेव किया जा सकता है. किसी संसाधन को सीडीएन के ज़रिए कैश मेमोरी में सेव किया जा सकने वाला तब माना जा सकता है, जब उसमें Cache-Control: no-store या Cache-Control: private हेडर न हो. सार्वजनिक संसाधन को कैश मेमोरी में सेव किए जाने में लगने वाला समय, इस बात पर निर्भर करता है कि ऐसेट कितनी बार बदलती है.

डाइनैमिक और स्टैटिक कॉन्टेंट

• डाइनैमिक कॉन्टेंट

  डाइनैमिक कॉन्टेंट ऐसा कॉन्टेंट होता है जो बार-बार बदलता है. एपीआई से मिला रिस्पॉन्स और स्टोर का होम पेज, इस तरह के कॉन्टेंट के उदाहरण हैं. हालांकि, इस कॉन्टेंट में बार-बार बदलाव होने की वजह से, यह ज़रूरी नहीं है कि इसे कैश मेमोरी में सेव किया जाए. ज़्यादा ट्रैफ़िक वाले समय के दौरान, इन रिस्पॉन्स को बहुत कम समय (उदाहरण के लिए, पांच सेकंड) के लिए कैश मेमोरी में सेव करने से, ऑरिजिन सर्वर पर लोड कम हो सकता है. इससे डेटा अपडेट होने की फ़्रीक्वेंसी पर कम असर पड़ता है.

• स्टैटिक कॉन्टेंट

  अगर स्टैटिक कॉन्टेंट कभी-कभी बदलता है, तो यह कभी-कभी ही बदलता है. इमेज, वीडियो, और वर्शन वाली लाइब्रेरी आम तौर पर इस तरह के कॉन्टेंट के उदाहरण हैं. स्टैटिक कॉन्टेंट में बदलाव नहीं होता, इसलिए इसे लंबे समय तक लाइव रहने (टीटीएल) के साथ कैश मेमोरी में सेव किया जाना चाहिए. उदाहरण के लिए, छह महीने या एक साल.

सीडीएन चुनना

आम तौर पर, सीडीएन चुनते समय परफ़ॉर्मेंस पर सबसे ज़्यादा ध्यान दिया जाता है. हालांकि, सीडीएन चुनते समय इन बातों का ध्यान रखना ज़रूरी है: सीडीएन से मिलने वाली अन्य सुविधाएं (जैसे कि सुरक्षा और विश्लेषण से जुड़ी सुविधाएं), साथ ही सीडीएन की कीमत, सहायता, और ऑनबोर्डिंग.

परफ़ॉर्मेंस

हाई-लेवल पर, सीडीएन की परफ़ॉर्मेंस रणनीति को इंतज़ार के समय को कम करने और कैश हिट अनुपात को बढ़ाने के बीच के तालमेल को समझा जा सकता है. कई पॉइंट (पीओपी) वाले सीडीएन, इंतज़ार का समय कम कर सकते हैं. हालांकि, ज़्यादा कैश मेमोरी में ट्रैफ़िक के बंटवारे की वजह से, कैश मेमोरी के हिट का अनुपात कम हो सकता है. इसके उलट, कम पीओपी वाले सीडीएन, भौगोलिक रूप से उपयोगकर्ताओं से दूर हो सकते हैं, लेकिन वे ज़्यादा कैश हिट अनुपात पा सकते हैं.

इस बदलाव की वजह से, कुछ सीडीएन कैश मेमोरी में अलग-अलग टीयर वाला तरीका इस्तेमाल करते हैं: उपयोगकर्ताओं के नज़दीक मौजूद पीओपी (जिन्हें "एज कैश" भी कहा जाता है) को मुख्य पीओपी के साथ जोड़ दिया जाता है. इन पीओपी का कैश हिट रेशियो ज़्यादा होता है. जब किसी एज कैश को कोई संसाधन नहीं मिलता, तो वह संसाधन के लिए एक केंद्रीय PoP की तरह खोज करता है. यह तरीका, डेटा को प्रोसेस करने में लगने वाले समय को थोड़ा बढ़ा देता है. इससे उस रिसॉर्स को सीडीएन कैश मेमोरी से उपलब्ध कराने की संभावना बढ़ जाती है. हालांकि, यह ज़रूरी नहीं है कि कैश मेमोरी का ऐक्सेस हो.

इंतज़ार का समय कम करने और कैश हिट का अनुपात बढ़ाने के बीच का अंतर, स्पेक्ट्रम है. कोई भी खास तरीका सार्वभौमिक तौर पर बेहतर नहीं होता है. हालांकि, आपकी साइट के टाइप और उसके उपयोगकर्ता आधार के आधार पर, आपको ऐसा लग सकता है कि इनमें से कोई एक तरीका दूसरे के मुकाबले काफ़ी बेहतर परफ़ॉर्म करता है.

ध्यान दें कि सीडीएन की परफ़ॉर्मेंस देश/इलाके, दिन के समय, और यहां तक कि मौजूदा इवेंट के हिसाब से भी अलग-अलग हो सकती है. किसी सीडीएन की परफ़ॉर्मेंस के बारे में खुद रिसर्च करना हमेशा अच्छा होता है, लेकिन किसी सीडीएन से मिलने वाले सटीक परफ़ॉर्मेंस का अनुमान लगाना मुश्किल हो सकता है.

सबसे बड़े एलिमेंट को रेंडर करने में लगने वाले समय (एलसीपी) पर असर

जैसा कि इस लेख में पहले बताया गया है, सीडीएन का मुख्य मकसद उन सर्वर पर रिसॉर्स डिस्ट्रिब्यूट करना है जो उपयोगकर्ताओं के आस-पास मौजूद हैं. इससे, इंतज़ार के समय को कम किया जा सकता है. इस वजह से, सीडीएन का मुख्य फ़ायदा यह है कि इससे लोड होने की परफ़ॉर्मेंस बेहतर होती है. खास तौर पर, अपनी वेबसाइट के सर्वर साइड आर्किटेक्चर में सीडीएन लागू करते समय, किसी रिसॉर्स के टाइम टू फ़र्स्ट बाइट (टीटीएफ़बी) में काफ़ी सुधार हो सकता है.

टीटीएफ़बी, उपयोगकर्ताओं को ध्यान में रखकर बनाई गई परफ़ॉर्मेंस मेट्रिक नहीं है. हालांकि, यह सबसे बड़े एलिमेंट को रेंडर करने में लगने वाले समय (एलसीपी) से जुड़ी समस्याओं का पता लगाने के लिए एक अहम मेट्रिक है. यह उपयोगकर्ताओं पर फ़ोकस करने वाली मेट्रिक है.

सीडीएन खास तौर पर एलसीपी को बेहतर बनाने में मदद करते हैं, क्योंकि वे दस्तावेज़ की डिलीवरी (कनेक्शन सेटअप में टीटीएफ़बी को कम करके और दस्तावेज़ को कैश मेमोरी में सेव करके) और एलसीपी एलिमेंट को रेंडर करने के लिए ज़रूरी, स्टैटिक संसाधनों की डिलीवरी को बेहतर बनाते हैं.

अतिरिक्त सुविधाएं

सीडीएन में आम तौर पर, मुख्य सीडीएन के साथ-साथ कई और सुविधाएं भी मिलती हैं. आम तौर पर, ये सुविधाएं उपलब्ध कराई जाती हैं: लोड बैलेंसिंग, इमेज ऑप्टिमाइज़ेशन, वीडियो स्ट्रीमिंग, एज कंप्यूटिंग, और सुरक्षा से जुड़े प्रॉडक्ट.

सीडीएन सेटअप और कॉन्फ़िगर कैसे करें

आम तौर पर, आपको अपनी पूरी साइट को विज्ञापन दिखाने के लिए सीडीएन का इस्तेमाल करना चाहिए. इसके लिए सेट अप की प्रोसेस में सीडीएन प्रोवाइडर के साथ साइन अप करना और फिर सीडीएन प्रोवाइडर की साइट को सीडीएन सर्वर से लिंक करने के लिए, अपने CNAME डीएनएस रिकॉर्ड को अपडेट करना शामिल है. उदाहरण के लिए, www.example.com का CNAME रिकॉर्ड example.my-cdn.com की ओर इशारा कर सकता है. इस डीएनएस बदलाव की वजह से, आपकी साइट पर आने वाले ट्रैफ़िक को सीडीएन के ज़रिए रूट किया जाएगा.

अगर सभी संसाधनों को दिखाने के लिए सीडीएन का इस्तेमाल करना है, तो सीडीएन को सिर्फ़ संसाधनों के सबसेट को दिखाने के लिए कॉन्फ़िगर किया जा सकता है. जैसे, सिर्फ़ स्टैटिक रिसॉर्स को. ऐसा करने के लिए, एक अलग CNAME रिकॉर्ड बनाएं. इसका इस्तेमाल सिर्फ़ उन संसाधनों के लिए किया जाएगा जिन्हें सीडीएन के ज़रिए डिलीवर किया जाना चाहिए. उदाहरण के लिए, आप ऐसा static.example.com CNAME रिकॉर्ड बना सकते हैं जो example.my-cdn.com पर ले जाता हो. आपको उन संसाधनों के यूआरएल भी फिर से लिखने होंगे जो सीडीएन के ज़रिए उपलब्ध कराए जा रहे हैं, ताकि आपका बनाया गया static.example.com सबडोमेन खुले.

हालांकि, इस समय आपका सीडीएन सेट अप हो जाएगा, लेकिन हो सकता है कि आपके कॉन्फ़िगरेशन में कुछ गड़बड़ियां हों. इस लेख के अगले दो सेक्शन में बताया गया है कि कैश मेमोरी के हिट अनुपात को बढ़ाकर और परफ़ॉर्मेंस सुविधाओं को चालू करके, सीडीएन से ज़्यादा से ज़्यादा फ़ायदा कैसे लिया जा सकता है.

कैश मेमोरी का हिट अनुपात बेहतर बनाना

एक असरदार सीडीएन सेटअप, कैश मेमोरी से ज़्यादा से ज़्यादा संसाधन उपलब्ध कराएगा. आम तौर पर, इसे कैश मेमोरी के हिट रेशियो (सीएचआर) से मेज़र किया जाता है. कैश मेमोरी का हिट अनुपात, कैश मेमोरी हिट की संख्या को किसी तय समयावधि के दौरान मिले कुल अनुरोधों की संख्या से भाग देकर निकाला जाता है.

हाल ही में शुरू की गई कैश मेमोरी का सीएचआर 0 होगा. हालांकि, कैश मेमोरी में रिसॉर्स अपने-आप भरे जाने पर यह बढ़ जाएगा. ज़्यादातर साइटों के लिए, 90% सीएचआर का इस्तेमाल अच्छा लक्ष्य होता है. आपको सीडीएन सेवा देने वाली कंपनी को, अपने सीएचआर से जुड़े आंकड़े और रिपोर्ट उपलब्ध करानी चाहिए.

CHR को ऑप्टिमाइज़ करते समय, सबसे पहले यह पुष्टि करें कि कैश किए जा सकने वाले सभी रिसॉर्स को सही समयसीमा के लिए कैश और कैश मेमोरी में सेव किया जा रहा है. यह एक आसान आकलन है, जिसे सभी साइटों को पूरा करना चाहिए.

मोटे तौर पर, CHR ऑप्टिमाइज़ेशन का अगला लेवल यह है कि अपनी सीडीएन सेटिंग को ठीक करें, ताकि यह पक्का हो सके कि सही तरीके से एक जैसे सर्वर वाले रिस्पॉन्स अलग से कैश मेमोरी में सेव न किए जा रहे हों. कैश मेमोरी में सेव किए गए क्वेरी पैरामीटर, कुकी, और अनुरोध हेडर जैसे फ़ैक्टर के असर की वजह से यह आम तौर पर होने वाली गड़बड़ी है.

शुरुआती ऑडिट

ज़्यादातर सीडीएन, कैश मेमोरी के आंकड़े देंगे. इसके अलावा, WebPageTest और Lighthouse जैसे टूल का इस्तेमाल करके भी, यह पुष्टि की जा सकती है कि किसी पेज के सभी स्टैटिक रिसॉर्स सही समय के लिए कैश मेमोरी में सेव किए जा रहे हैं. ऐसा करने के लिए, हर रिसॉर्स के एचटीटीपी कैश हेडर की जांच करें. ज़्यादा से ज़्यादा टाइम टू लाइव (टीटीएल) का इस्तेमाल करके, संसाधन को कैश मेमोरी में सेव करने से, आने वाले समय में ऑरिजिन फ़ेच को रोका जाएगा. इससे सीएचआर बढ़ जाएगा.

किसी संसाधन को सीडीएन से कैश मेमोरी में सेव करने के लिए, कम से कम इनमें से किसी एक हेडर को सेट करने की ज़रूरत होती है:

• Cache-Control: max-age=
• Cache-Control: s-maxage=
• Expires

इसके अलावा, हालांकि इससे इस बात पर कोई असर नहीं पड़ता कि किसी संसाधन को सीडीएन के ज़रिए कैश मेमोरी में सेव किया जाता है या नहीं, लेकिन Cache-Control: immutable डायरेक्टिव को सेट करना भी एक अच्छा तरीका है.Cache-Control: immutable यह बताता है कि "रिसॉर्स को अपडेट होने के लाइफ़टाइम में अपडेट नहीं किया जाएगा". नतीजे के तौर पर, ब्राउज़र कैश से संसाधन उपलब्ध कराते समय, ब्राउज़र उसे दोबारा सत्यापित नहीं करेगा, जिससे सर्वर का एक गैर-ज़रूरी अनुरोध खत्म हो जाएगा. माफ़ करें, यह डायरेक्टिव सिर्फ़ Firefox और Safari पर काम करता है. यह Chromium पर काम करने वाले ब्राउज़र पर काम नहीं करता. यह समस्या, Cache-Control: immutable के लिए Chromium पर काम करने की सुविधा को ट्रैक करती है. इस समस्या पर स्टार का निशान लगाने से, इस सुविधा को बेहतर तरीके से इस्तेमाल करने में मदद मिल सकती है.

एचटीटीपी कैश मेमोरी में डेटा सेव करने के बारे में ज़्यादा जानने के लिए, एचटीटीपी कैश मेमोरी की मदद से, ग़ैर-ज़रूरी नेटवर्क अनुरोधों को रोकें वाला लेख पढ़ें.

फ़ाइन ट्यूनिंग

सीडीएन कैशे कैसे काम करता है, इसके बारे में कम शब्दों में यह बताया जा सकता है कि किसी रिसॉर्स के यूआरएल का इस्तेमाल, कैश मेमोरी में सेव किए गए रिसॉर्स को कैश मेमोरी में सेव करने और पाने के लिए, कुंजी के तौर पर किया जाता है. व्यावहारिक तौर पर यह अब भी काफ़ी हद तक सही है, लेकिन अनुरोध हेडर और क्वेरी पैरामीटर जैसी चीज़ों के असर की वजह से यह थोड़ा मुश्किल हो जाता है. इस वजह से, अनुरोध यूआरएल को फिर से लिखना, सीएचआर को बढ़ाने और यह पक्का करने, दोनों के लिए एक अहम तकनीक है कि उपयोगकर्ताओं को सही कॉन्टेंट दिखाया जा रहा है. अच्छी तरह से कॉन्फ़िगर किया गया सीडीएन इंस्टेंस, बहुत ज़्यादा जानकारी वाली कैश मेमोरी (इससे सीएचआर को नुकसान होता है) और ज़रूरत के हिसाब से ज़्यादा जानकारी वाली कैश मेमोरी (इससे उपयोगकर्ताओं को गलत जवाब मिलते हैं) के बीच सही संतुलन होता है.

क्वेरी पैरामीटर

डिफ़ॉल्ट रूप से, किसी संसाधन को कैश मेमोरी में सेव करते समय, सीडीएन क्वेरी पैरामीटर को ध्यान में रखते हैं. हालांकि, क्वेरी पैरामीटर हैंडलिंग में छोटे-मोटे बदलाव करने से सीएचआर पर काफ़ी असर पड़ सकता है. उदाहरण के लिए:

• ग़ैर-ज़रूरी क्वेरी पैरामीटर

  डिफ़ॉल्ट रूप से, सीडीएन example.com/blog और example.com/blog?referral_id=2zjk को अलग-अलग कैश मेमोरी में सेव करता है. भले ही, वे एक ही संसाधन के तौर पर हों. referral\_id क्वेरी पैरामीटर को अनदेखा करने के लिए, सीडीएन के कॉन्फ़िगरेशन में बदलाव करके इसे ठीक किया जाता है.

• क्वेरी पैरामीटर का क्रम

  सीडीएन, example.com/blog?id=123&query=dogs को example.com/blog?query=dogs&id=123 से अलग कैश मेमोरी में सेव करेगा. ज़्यादातर साइटों के लिए, क्वेरी पैरामीटर के क्रम से कोई फ़र्क़ नहीं पड़ता. इसलिए, क्वेरी पैरामीटर को क्रम से लगाने के लिए सीडीएन को कॉन्फ़िगर करने से सीएचआर बढ़ जाएगा. इससे, सर्वर के रिस्पॉन्स को कैश मेमोरी में सेव करने के लिए इस्तेमाल होने वाले यूआरएल को नॉर्मलाइज़ किया जा सकेगा.

विविध

Vary रिस्पॉन्स हेडर, कैश मेमोरी को यह जानकारी देता है कि किसी यूआरएल से जुड़े सर्वर के रिस्पॉन्स, अनुरोध पर सेट किए गए हेडर के आधार पर अलग-अलग हो सकते हैं. उदाहरण के लिए, स्वीकार-भाषा या स्वीकार-इनकोडिंग के अनुरोध हेडर, इस आधार पर अलग-अलग हो सकते हैं. इस वजह से, यह सीडीएन को इन जवाबों को अलग-अलग कैश मेमोरी में सेव करने का निर्देश देता है. Vary हेडर, सीडीएन के साथ पूरी तरह से काम नहीं करता है. इस वजह से, हो सकता है कि कैश मेमोरी में सेव किया गया कोई ऐसा रिसॉर्स न दिखे जिसे कैश मेमोरी में सेव किया जा सके.

हालांकि, 'Vary हेडर' एक मददगार टूल हो सकता है, लेकिन गलत इस्तेमाल से CHR को नुकसान पहुंचता है. इसके अलावा, Vary का इस्तेमाल करने पर, रिक्वेस्ट हेडर को नॉर्मलाइज़ करने से सीएचआर को बेहतर बनाने में मदद मिलेगी. उदाहरण के लिए, नॉर्मलाइज़ेशन के बिना अनुरोध हेडर Accept-Language: en-US और Accept-Language: en-US,en;q=0.9 दो अलग-अलग कैश एंट्री जनरेट करेंगे. भले ही, उनका कॉन्टेंट एक जैसा हो.

कुकी

कुकी, Cookie हेडर के ज़रिए अनुरोधों पर सेट की जाती हैं; उन्हें Set-Cookie हेडर के ज़रिए जवाबों के लिए सेट किया जाता है. Set-Cookie हेडर के ग़ैर-ज़रूरी इस्तेमाल से बचना चाहिए. इसकी वजह यह है कि कैश मेमोरी, आम तौर पर इस हेडर वाले सर्वर के जवाबों को कैश मेमोरी में नहीं सेव करती.

परफ़ॉर्मेंस से जुड़ी सुविधाएं

इस सेक्शन में, परफ़ॉर्मेंस से जुड़ी उन सुविधाओं के बारे में बताया गया है जो आम तौर पर सीडीएन से अपने मुख्य प्रॉडक्ट के तहत दी जाती हैं. कई साइटें इन सुविधाओं को चालू करना भूल जाती हैं. इस वजह से, साइट की परफ़ॉर्मेंस आसान नहीं होती.

संपीड़न

टेक्स्ट पर आधारित सभी जवाब gzip या Brotli के साथ कंप्रेस किए जाने चाहिए. अगर आपके पास विकल्प है, तो gzip की जगह Brotli चुनें. Brotli एक नया कंप्रेशन एल्गोरिदम है. gzip की तुलना में, यह ज़्यादा कंप्रेशन रेशियो पा सकता है.

Brotli कंप्रेशन के लिए दो तरह के सीडीएन समर्थन करते हैं: "ऑरिजिन से ब्रोटली" और "ऑटोमैटिक ब्रॉटली कंप्रेशन".

मूल रूप से ब्रॉटली

ऑरिजिन से Brotli तब कहते हैं, जब सीडीएन ऐसे रिसॉर्स दिखाता है जिन्हें ऑरिजिन से Brotli कंप्रेस किया गया था. हालांकि, यह एक ऐसी सुविधा लग सकती है जो सभी सीडीएन, बॉक्स के हिसाब से काम करें. हालांकि, इसके लिए ज़रूरी है कि सीडीएन, दिए गए यूआरएल से जुड़े संसाधन के एक से ज़्यादा वर्शन (दूसरे शब्दों में, gzip-कंप्रेस्ड और Brotli-कंप्रेस्ड वर्शन) को कैश मेमोरी में सेव कर पाए.

अपने-आप ब्रॉटली कंप्रेस करने की सुविधा

अपने-आप Brotli कंप्रेशन तब होता है, जब संसाधनों को सीडीएन से Brotli कंप्रेस किया जाता है. सीडीएन, कैश मेमोरी और कैश मेमोरी में सेव न किए जा सकने वाले, दोनों तरह के रिसॉर्स को कंप्रेस कर सकते हैं.

जब पहली बार किसी संसाधन का अनुरोध किया जाता है, तो उसे "अच्छा" कंप्रेशन का इस्तेमाल करके दिखाया जाता है - उदाहरण के लिए, Brotli-5. इस तरह का कंप्रेशन, कैश करने लायक और कैश न किए जा सकने वाले, दोनों तरह के रिसॉर्स पर लागू होता है.

हालांकि, अगर किसी संसाधन को कैश मेमोरी में सेव किया जा सकता है, तो सीडीएन ऑफ़लाइन प्रोसेस का इस्तेमाल करके रिसॉर्स को ज़्यादा असरदार, लेकिन बहुत धीमे कंप्रेशन लेवल पर कंप्रेस करेगा. उदाहरण के लिए, Brotli-11. इस कंप्रेशन के पूरा होने के बाद, कंप्रेस किए गए वर्शन को कैश मेमोरी में सेव किया जाएगा. साथ ही, उसका इस्तेमाल बाद के अनुरोधों के लिए किया जाएगा.

कंप्रेस करने के सबसे सही तरीके

जो साइटें परफ़ॉर्मेंस को बेहतर बनाना चाहती हैं उन्हें अपने ऑरिजिन सर्वर और सीडीएन, दोनों पर Brotli कंप्रेशन लागू करनी चाहिए. ऑरिजिन पर Brotli कंप्रेस करने से, उन संसाधनों का ट्रांसफ़र साइज़ कम हो जाता है जिन्हें कैश मेमोरी से नहीं दिखाया जा सकता. अनुरोध दिखाने में होने वाली देरी से बचने के लिए, ऑरिजिन को काफ़ी पुराने कंप्रेशन लेवल का इस्तेमाल करके डाइनैमिक रिसॉर्स को कंप्रेस करना चाहिए. उदाहरण के लिए, Brotli-4. स्टैटिक रिसॉर्स को Brotli-11 का इस्तेमाल करके कंप्रेस किया जा सकता है. अगर कोई ऑरिजिन, Brotli के साथ काम नहीं करता, तो डाइनैमिक रिसॉर्स को कंप्रेस करने के लिए, gzip-6 का इस्तेमाल किया जा सकता है. साथ ही, gzip-9 का इस्तेमाल, स्टैटिक रिसॉर्स को कंप्रेस करने के लिए किया जा सकता है.

टीएलएस 1.3

TLS 1.3, ट्रांसपोर्ट लेयर सिक्योरिटी (TLS) का सबसे नया वर्शन है. यह एक क्रिप्टोग्राफ़िक प्रोटोकॉल है, जिसे एचटीटीपीएस इस्तेमाल करता है. TLS 1.3 के मुकाबले, TLS 1.3 में बेहतर निजता और परफ़ॉर्मेंस मिलती है.

TLS 1.3, TLS हैंडशेक को दो राउंडट्रिप से छोटा करके एक कर देता है. एचटीटीपी/1 या एचटीटीपी/2 का इस्तेमाल करने वाले कनेक्शन के लिए, TLS हैंडशेक को एक राउंडट्रिप तक छोटा करके, कनेक्शन सेटअप करने में लगने वाला समय 33% कम हो जाता है.

एचटीटीपी/2 और एचटीटीपी/3

एचटीटीपी/2 और एचटीटीपी/3, दोनों ही एचटीटीपी/1 के मुकाबले बेहतर परफ़ॉर्मेंस देते हैं. दोनों में से, एचटीटीपी/3 परफ़ॉर्मेंस से जुड़े संभावित फ़ायदे देता है. एचटीटीपी/3 अभी तक पूरी तरह से स्टैंडर्ड के मुताबिक नहीं है. हालांकि, ऐसा होने के बाद यह बड़े पैमाने पर काम करता होगा.

एचटीटीपी/2

अगर आपके सीडीएन ने डिफ़ॉल्ट रूप से HTTP/2 को पहले से चालू नहीं किया है, तो इसे चालू करें. एचटीटीपी/2, एचटीटीपी/1 की तुलना में परफ़ॉर्मेंस से जुड़े कई फ़ायदे देता है. साथ ही, यह सभी मुख्य ब्राउज़र पर काम करता है. एचटीटीपी/2 की परफ़ॉर्मेंस की सुविधाओं में ये शामिल हैं: मल्टीप्लेक्सिंग, स्ट्रीम की प्राथमिकता, और हेडर कंप्रेस करना.

• मल्टीप्लेक्सिंग

  मल्टीप्लेक्सिंग, एचटीटीपी/2 की सबसे अहम सुविधा है. मल्टीप्लेक्सिंग, एक टीसीपी कनेक्शन को चालू करता है. इससे एक ही समय में, कई अनुरोध-रिस्पॉन्स पेयर पेश किए जा सकते हैं. इससे कनेक्शन के गै़र-ज़रूरी सेटअप की ज़रूरत नहीं पड़ती. यह देखते हुए कि किसी तय समय में ब्राउज़र, सीमित संख्या में कनेक्शन खोल सकता है, इसका मतलब यह भी है कि ब्राउज़र अब किसी पेज के ज़्यादा संसाधनों का अनुरोध साथ-साथ कर सकता है. मल्टीप्लेक्सिंग के हिसाब से, एचटीटीपी/1 ऑप्टिमाइज़ेशन की ज़रूरत नहीं पड़ती. जैसे, कंकैटेनेशन और स्प्राइट शीट. हालांकि, बड़ी फ़ाइलें बेहतर तरीके से कंप्रेस होने की वजह से ये तकनीकें काम की होती हैं.

• स्ट्रीम की प्राथमिकता तय करना

  मल्टीप्लेक्सिंग की मदद से, एक साथ कई स्ट्रीम चालू की जा सकती हैं. स्ट्रीम की प्राथमिकता से इनमें से हर स्ट्रीम की प्राथमिकता के बारे में बताने के लिए इंटरफ़ेस मिलता है. इससे सर्वर को सबसे ज़रूरी संसाधन पहले भेजने में मदद मिलती है, भले ही उनके लिए पहले अनुरोध न किया गया हो.

स्ट्रीम की प्राथमिकता तय करने के लिए ब्राउज़र, डिपेंडेंसी ट्री के ज़रिए दिखाता है और यह सिर्फ़ प्राथमिकता का एक स्टेटमेंट है: दूसरे शब्दों में, सर्वर की यह ज़िम्मेदारी नहीं होती कि वह ब्राउज़र की दी गई प्राथमिकताओं को पूरा करे या उन पर विचार करे. जब किसी साइट को सीडीएन के ज़रिए ज़्यादा दिखाया जाता है, तो स्ट्रीम की प्राथमिकता तय करने की प्रोसेस ज़्यादा असरदार हो जाती है.

एचटीटीपी/2 रिसॉर्स की प्राथमिकता के लिए सीडीएन लागू करने की प्रोसेस बहुत अलग-अलग होती है. यह पता लगाने के लिए कि आपका सीडीएन पूरी तरह से और सही तरीके से एचटीटीपी/2 संसाधन की प्राथमिकता के साथ काम करता है या नहीं, क्या एचटीटीपी/2 अब भी तेज़ है? देखें.

हालांकि, अपने सीडीएन इंस्टेंस को एचटीटीपी/2 पर स्विच करना काफ़ी हद तक स्विच को फ़्लिप करने जैसा होता है. हालांकि, प्रोडक्शन में इसे चालू करने से पहले, इस बदलाव को अच्छी तरह से टेस्ट कर लेना चाहिए. एचटीटीपी/1 और एचटीटीपी/2, अनुरोध और रिस्पॉन्स हेडर के लिए एक जैसे तरीकों का इस्तेमाल करते हैं. हालांकि, इन शर्तों का पालन न करने पर एचटीटीपी/2 को बहुत कम अनदेखा किया जाता है. इस वजह से, एचटीटीपी/2 के चालू होने के बाद, हेडर में बिना ASCII या बड़े अक्षरों वाले वर्ण शामिल करने जैसे गैर-खास तरीकों से गड़बड़ियां हो सकती हैं. अगर ऐसा होता है, तो ब्राउज़र, संसाधन को डाउनलोड करने की कोशिश नहीं कर पाएगा. डाउनलोड न हो पाने की कोशिश, DevTools के "नेटवर्क" टैब में दिखेगी. इसके अलावा, कंसोल में गड़बड़ी का मैसेज "ERR_HTTP2_PROTOCOL_ERROR" दिखेगा.

एचटीटीपी/3

HTTP/3, HTTP/2 का सक्सेसर है. सितंबर 2020 से, सभी मुख्य ब्राउज़र में एचटीटीपी/3 के लिए support एक्सपेरिमेंट के तौर पर उपलब्ध है और कुछ सीडीएन इस पर काम करते हैं. एचटीटीपी/2 के बजाय एचटीटीपी/3 का मुख्य फ़ायदा परफ़ॉर्मेंस है. खास तौर पर, एचटीटीपी/3 कनेक्शन के लेवल पर हेड-ऑफ़-लाइन ब्लॉक करने की सुविधा को हटा देता है और कनेक्शन को सेटअप करने में लगने वाला समय कम करता है.

• हेड-ऑफ़-लाइन ब्लॉकिंग को हटाना

  एचटीटीपी/2 ने मल्टीप्लेक्सिंग की सुविधा लॉन्च की है. यह एक ऐसी सुविधा है जिसकी मदद से, डेटा की कई स्ट्रीम को एक साथ ट्रांसमिट करने के लिए, एक कनेक्शन का इस्तेमाल किया जा सकता है. हालांकि, एचटीटीपी/2 का इस्तेमाल करने पर एक ड्रॉप-डाउन पैकेट की वजह से, कनेक्शन पर सभी स्ट्रीम ब्लॉक हो जाती हैं. इस घटना को हेड-ऑफ़-लाइन ब्लॉकिंग भी कहा जाता है. एचटीटीपी/3 के मामले में, छोड़ा गया पैकेट सिर्फ़ एक स्ट्रीम को ब्लॉक करता है. आम तौर पर, यह सुधार तब होता है, जब एचटीटीपी/3 के तहत टीसीपी के बजाय यूडीपी (एचटीटीपी/3, QUIC के ज़रिए यूडीपी का इस्तेमाल किया जाता है) का इस्तेमाल किया जाता है. इससे एचटीटीपी/3 को खास तौर पर उन नेटवर्क पर डेटा ट्रांसफ़र करने में मदद मिलती है जो बहुत ज़्यादा संख्या में या खराब नेटवर्क होते हैं.

• कनेक्शन के सेटअप में लगने वाला समय कम हुआ

  एचटीटीपी/3, TLS 1.3 का इस्तेमाल करता है. इसलिए, इसकी परफ़ॉर्मेंस से जुड़े फ़ायदे शेयर किए जाते हैं: नया कनेक्शन बनाने के लिए, सिर्फ़ एक दोतरफ़ा यात्रा की ज़रूरत होती है. साथ ही, किसी मौजूदा कनेक्शन को फिर से शुरू करने के लिए, अलग से दो चरणों की ज़रूरत नहीं होती.

एचटीटीपी/3 का खराब नेटवर्क कनेक्शन वाले लोगों पर सबसे ज़्यादा असर होगा: न सिर्फ़ एचटीटीपी/3, अपने पहले वाले नेटवर्क की तुलना में पैकेट लॉस को बेहतर तरीके से हैंडल करता है, बल्कि इसलिए भी कि 0-आरटीटी या 1-आरटीटी कनेक्शन सेटअप करने से होने वाले समय की कुल बचत, इंतज़ार का समय ज़्यादा करने वाले नेटवर्क पर ज़्यादा होगी.

इमेज ऑप्टिमाइज़ेशन

सीडीएन इमेज ऑप्टिमाइज़ेशन सेवाएं आम तौर पर, इमेज को बेहतर बनाने पर फ़ोकस करती हैं. यह अपने-आप लागू हो सकती है, ताकि इमेज का ट्रांसफ़र साइज़ कम किया जा सके. उदाहरण के लिए: EXIF डेटा को हटाना, लॉसलेस कंप्रेस करना, और इमेज को नए फ़ाइल फ़ॉर्मैट (जैसे कि WebP) में बदलना. मीडियन वेब पेज पर, इमेज ट्रांसफ़र बाइट का ~50% हिस्सा होती हैं. इसलिए, इमेज को ऑप्टिमाइज़ करने से पेज का साइज़ काफ़ी कम हो सकता है.

छोटा करना

छोटा करने की सुविधा: JavaScript, सीएसएस, और एचटीएमएल से गै़र-ज़रूरी वर्ण हटा देता है. सीडीएन के बजाय, ऑरिजिन सर्वर पर काट-छांट करना बेहतर होता है. साइट के मालिकों के पास कम से कम किए जाने वाले कोड के बारे में ज़्यादा जानकारी होती है. इसलिए, वे सीडीएन में इस्तेमाल की जाने वाली तकनीक के मुकाबले, अक्सर कम करने की ज़्यादा असरदार तकनीकों का इस्तेमाल कर सकते हैं. हालांकि, अगर शुरुआत की जगह पर कोड को छोटा करने का विकल्प नहीं है, तो सीडीएन के हिसाब से कोड को छोटा करना एक अच्छा विकल्प है.

नतीजा

• सीडीएन का इस्तेमाल करें: सीडीएन, संसाधनों को तेज़ी से डिलीवर करते हैं. साथ ही, ये ऑरिजिन सर्वर पर लोड को कम करते हैं और ट्रैफ़िक में होने वाली बढ़ोतरी से निपटने में मदद करते हैं.
• कॉन्टेंट को ज़्यादा से ज़्यादा कैश मेमोरी में सेव करें: स्टैटिक और डाइनैमिक, दोनों तरह के कॉन्टेंट को कैश मेमोरी में सेव किया जा सकता है और ऐसा किया भी जाना चाहिए. हालांकि, यह अलग-अलग अवधि के लिए हो सकता है. समय-समय पर अपनी साइट का ऑडिट करते रहें, ताकि यह पक्का किया जा सके कि कॉन्टेंट को बेहतर तरीके से कैश मेमोरी में सेव किया जा रहा है.
• सीडीएन की परफ़ॉर्मेंस से जुड़ी सुविधाएं चालू करें: Brotli, TLS 1.3, एचटीटीपी/2, और एचटीटीपी/3 जैसी सुविधाएं, परफ़ॉर्मेंस को और बेहतर बनाती हैं.