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

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

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

खास जानकारी

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

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

संसाधन की डिलीवरी

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

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

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

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

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

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

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

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

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

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

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

• पर्जिंग

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

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

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

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

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

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

• निजी संसाधन

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

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

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

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

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

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

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

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

सीडीएन चुनना

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

परफ़ॉर्मेंस

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

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

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

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

सबसे बड़े कॉन्टेंटफ़ुल पेंट (एलसीपी) पर असर

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

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

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

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

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

सीडीएन को सेट अप और कॉन्फ़िगर करने का तरीका

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

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

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

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

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

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

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 से जुड़ी सहायता को ट्रैक करती है. इस समस्या पर स्टार का निशान लगाने से, आपको इस सुविधा के लिए मदद मिल सकती है.

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

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

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

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

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

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

  डिफ़ॉल्ट रूप से, सीडीएन, 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 से अलग कैश मेमोरी में सेव करेगा. ज़्यादातर साइटों के लिए, क्वेरी पैरामीटर के क्रम से कोई फ़र्क़ नहीं पड़ता. इसलिए, क्वेरी पैरामीटर को क्रम से लगाने के लिए, सीडीएन को कॉन्फ़िगर करने से (सर्वर रिस्पॉन्स को कैश मेमोरी में सेव करने के लिए इस्तेमाल किए जाने वाले यूआरएल को सामान्य बनाना) सीएचआर बढ़ जाएगा.

विविध

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

हालांकि, 'वैरी हेडर' एक मददगार टूल हो सकता है, लेकिन गलत इस्तेमाल से सीएचआर को नुकसान पहुंचता है. इसके अलावा, 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 कंप्रेस करने के लिए दो तरह के सीडीएन सपोर्ट हैं: "ऑरिजिन से Bratli" और "ऑटोमैटिक ब्रॉटली कंप्रेशन".

ऑरिजिन से ब्रॉटली

ऑरिजिन से ब्रॉटली तब इस्तेमाल किया जाता है, जब सीडीएन ऐसे संसाधन उपलब्ध कराता है जिन्हें ऑरिजिन के हिसाब से Brotli से कंप्रेस किया गया था. हालांकि, यह एक ऐसी सुविधा की तरह लग सकती है जिसका इस्तेमाल सभी सीडीएन अलग से कर पाएंगे, लेकिन इसके लिए ज़रूरी है कि सीडीएन, दिए गए यूआरएल से जुड़े संसाधन के कई वर्शन (दूसरे शब्दों में, gzip-कंप्रेस्ड और 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.2 की तुलना में, TLS 1.3 बेहतर निजता और परफ़ॉर्मेंस देता है.

TLS 1.3, TLS हैंडशेक को दो राउंडट्रिप से एक तक छोटा करता है. HTTP/1 या HTTP/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 के लिए प्रयोग के तौर पर सहायता उपलब्ध है और कुछ सीडीएन इस सुविधा के साथ काम करते हैं. परफ़ॉर्मेंस, एचटीटीपी/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 जैसी सुविधाएं इस्तेमाल करने से परफ़ॉर्मेंस को बेहतर बनाने में मदद मिलती है.