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

Scrapeless प्रॉक्सी अनुप्रयोगों को क्षेत्रीय वेब अनुरोधों के लिए समर्थित एग्ज़िट स्थानों का चयन करने की अनुमति देते हैं।

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

एक डेटा संग्राहक के लिए, व्यावहारिक परिणाम यह है कि वही URL आवश्यक रूप से एक नई ओरिजिन प्रतिक्रिया का संकेत नहीं देता। किसी अनुरोध को संग्रहीत प्रतिनिधित्व, नए सिरे से प्राप्त किया गया प्रतिनिधित्व, या ऐसा उत्तर मिल सकता है जो क्षेत्र और अनुरोध हैडर के अनुसार बदलता है। इन मार्गों को समझना यह समझाने में मदद करता है कि अवलोकन क्यों भिन्न होते हैं।

उद्गम और किनारा क्या हैं?

मूल सर्वर (origin) CDN के पीछे स्थित स्रोत सेवा होता है, जबकि एज लोकेशन CDN के डिलीवरी नेटवर्क के भीतर अनुरोधों को संभालती है। सामग्री वितरण नेटवर्क मॉडल प्रत्येक क्लाइंट से एक ही मूल स्थान के साथ संचार की आवश्यकता करने के बजाय विभिन्न स्थानों पर वितरण डिलीवरी करता है।

एज संग्रह से प्रतिक्रिया प्रदान कर सकता है, अनुरोध अग्रेषित कर सकता है, TLS समाप्त कर सकता है, या कॉन्फ़िगर की गई लॉजिक लागू कर सकता है। हर CDN हर अनुरोध के लिए हर फ़ंक्शन निष्पादित नहीं करता। इसलिए एक उपयोगी व्याख्या नेटवर्क की क्षमताओं को किसी विशेष होस्टनेम पर सक्षम नीति से अलग करती है।

उद्गम एक वेब अनुप्रयोग, ऑब्जेक्ट स्टोर, या किसी अन्य सेवा एंडपॉइंट हो सकता है। यह स्वयं भी लोड बैलेंसिंग और कई सर्वरों का उपयोग कर सकता है। CDN और उद्गम डिलीवरी पथ में तार्किक भूमिकाएँ हैं; वे यह संकेत नहीं देते कि पूरी वेबसाइट के लिए केवल एक ही स्रोत मशीन और एक ही कैश है।

किस प्रकार एक अनुरोध CDN तक पहुँचता है?

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

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

एक बार जब एज अनुरोध प्राप्त कर लेता है, तो यह होस्ट, पथ, विधि, हेडर और लागू कॉन्फ़िगरेशन का मूल्यांकन करता है। एक स्थिर एसेट और एक प्रमाणित खाता पृष्ठ समान वेबसाइट से संबंधित होने पर भी अलग-अलग हैंडलिंग नियमों का पालन कर सकते हैं। केवल CDN की उपस्थिति ही यह स्थापित नहीं करती कि कोई विशिष्ट प्रतिक्रिया कैश की जा सकती है या नहीं।

कैश हिट या मिस होने पर क्या होता है?

जब कैश के पास उपयुक्त संग्रहीत प्रतिक्रिया होती है जिसे उसके नियम उसे प्रदान करने की अनुमति देते हैं, तो उसे कैश हिट कहा जाता है। मिस तब होती है जब अनुरोध को ऐसे कॉन्टेंट की आवश्यकता होती है जिसे किसी पात्र संग्रहीत प्रतिक्रिया से पूरा नहीं किया जा सकता। तब आमतौर पर एज, अपस्ट्रीम सेवा से कॉन्टेंट प्राप्त करता है, जो ओरिजिन या किसी अन्य कैश लेयर हो सकती है।

1. एज अनुरोध और कॉन्फ़िगर किए गए नियमों से एक कैश कुंजी प्राप्त करता है।
2. यह उस कुंजी और प्रासंगिक भिन्नता से मेल खाता हुआ संग्रहीत प्रतिक्रिया खोजता है।
3. यह ताजगी और किसी अपस्ट्रीम सेवा से संपर्क करने की आवश्यकताओं का मूल्यांकन करता है।
4. यह एक पात्र प्रतिक्रिया प्रदान करता है या एक उपयुक्त अपस्ट्रीम प्रतिक्रिया प्राप्त करता है।
5. यह नए प्रतिक्रिया को केवल तब संग्रहीत करता है जब प्रतिक्रिया और कैश नीति भंडारण की अनुमति देते हैं।

एक मिस का अर्थ आवश्यक रूप से एक खराब CDN नहीं होता। नई सामग्री, समाप्त हो चुकी प्रविष्टियाँ, जानबूझकर अनकैश की गई पेज, और असामान्य वेरिएंट सभी को अपस्ट्रीम कार्य की आवश्यकता हो सकती है। उच्च हिट अनुपात तभी उपयोगी होता है जब परोसी जा रही सामग्री संबंधित उपयोगकर्ताओं और अनुरोधों के लिए सही हो।

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

कैश कुंजी को क्या निर्धारित करता है?

एक कैश कुंजी यह निर्धारित करती है कि कौन-से अनुरोध एक ही संग्रहीत प्रतिनिधित्व को पुनः उपयोग कर सकते हैं। इसमें आमतौर पर लक्ष्य संसाधन की पहचान शामिल होती है और यह मानक सिमैंटिक्स और साइट-विशिष्ट विन्यास के माध्यम से अतिरिक्त अनुरोध विशेषताओं को भी सम्मिलित कर सकती है।

The HTTP Vary फ़ील्ड उन अनुरोध फ़ील्ड्स की पहचान करता है जिन्होंने किसी प्रतिनिधित्व के चयन को प्रभावित किया। यदि सामग्री किसी स्वीकृत एन्कोडिंग या भाषा के आधार पर बदलती है, तो कोई स्टोर की गई प्रतिक्रिया चुनते समय वे आयाम महत्वपूर्ण हो सकते हैं। कोई कैश जो किसी महत्वपूर्ण विविधता को नज़रअंदाज़ करता है, वह गलत प्रतिनिधित्व लौटा सकता है।

क्वेरी स्ट्रिंग्स को एक स्पष्ट नीति की आवश्यकता होती है। कुछ अनुप्रयोग उन्हें विभिन्न संसाधनों की पहचान करने के लिए उपयोग करते हैं, जबकि अन्य उन्हें ट्रैकिंग के लिए उपयोग करते हैं। हर क्वेरी पैरामीटर को अप्रासंगिक मानना अलग-अलग सामग्री को मिला सकता है। हर पैरामीटर को एक अद्वितीय कुंजी मानना कैश को खंडित कर सकता है और पुन: उपयोग को कम कर सकता है।

एक काल्पनिक क्षेत्रीय उत्पाद पृष्ठ के लिए, यह तय करें कि मुद्रा और बाज़ार URL में, किसी हेडर में, या किसी कुकी में व्यक्त किए गए हैं। यह निर्णय आवेदन और कैश कॉन्फ़िगरेशन दोनों को प्रभावित करता है। कैश कुंजी को केवल उसके पथ के आधार पर अनुमान लगाने के बजाय, प्रतिरूप की वास्तविक पहचान को प्रतिबिंबित करना चाहिए।

ताज़गी, मान्यकरण, और संग्रह अलग-अलग हैं

ताज़गी यह निर्धारित करती है कि किसी संग्रहीत प्रतिक्रिया को बिना अपस्ट्रीम जाँच किए दोबारा उपयोग किया जा सकता है या नहीं, जबकि सत्यापन यह जाँचता है कि वह संग्रहीत प्रतिक्रिया अब भी लागू है या नहीं। भंडारण नीति यह निर्धारित करती है कि प्रतिक्रिया को बिल्कुल भी रखा जा सकता है या नहीं। HTTP कैशिंग नियम इन निर्णयों को अलग-अलग पहचानें।

no-cache वाला कोई जवाब अभी भी स्टोर किया जा सकता है, लेकिन उसे दोबारा उपयोग करने के लिए लागू नियमों के तहत सफल वैधता जाँच की आवश्यकता होती है। no-store वाला जवाब कैश को इसे स्टोर न करने का निर्देश देता है। एक private जवाब साधारण, बिना किसी अतिरिक्त योग्यता वाले मामले में shared-cache स्टोरेज से प्रतिबंधित होता है। ये निदेश (directives) हर कैश को निष्क्रिय करने के लिए आपस में अदला-बदली करके इस्तेमाल किए जाने वाले वर्तनी (spellings) के रूप में नहीं माने जाने चाहिए।

एंटिटी टैग्स जैसे वैलिडेटर किसी अपस्ट्रीम सर्वर को यह पुष्टि करने दे सकते हैं कि संग्रहीत रिप्रेज़ेंटेशन अभी भी उपयोग के योग्य है। जब रिप्रेज़ेंटेशन में कोई बदलाव नहीं हुआ हो तो एक कंडीशनल रिक्वेस्ट फिर से पूरा बॉडी ट्रांसफर करने से बचा सकती है। वैलिडेशन में फिर भी अपस्ट्रीम जांच शामिल होती है; यह तुरंत नया संग्रहीत रिस्पॉन्स सर्व करने से अलग है।

Age फ़ील्ड यह बताती है कि कोई रिस्पॉन्स लगभग कितने समय से कैश और संबंधित ट्रांज़िट में मौजूद है। यह मूल बिज़नेस तथ्य की उम्र नहीं होती। किसी उत्पाद की कीमत कई दिनों तक बदली न हो सकती है, भले ही रिस्पॉन्स हाल ही में जेनरेट किया गया हो, या फिर स्रोत पर बदल चुकी हो जबकि कैश्ड रिस्पॉन्स पहले ही बना लिया गया हो।

कॉन्टेंट अपडेट Edge तक कैसे पहुँचते हैं?

कॉन्टेंट अपडेट एक्सपायरी, वैलिडेशन, स्पष्ट इनवैलिडेशन, या नए रिसोर्स आइडेंटिटी के ज़रिए यूज़र्स तक पहुँचते हैं। कौन‑सा मैकेनिज़्म लागू होगा यह वेबसाइट की डिप्लॉयमेंट और कैश नीतियों पर निर्भर करता है। ओरिजिन पर किया गया पब्लिश्ड बदलाव अपने‑आप यह नहीं बताता कि हर संग्रहीत एज रिस्पॉन्स पहले ही हटा दिया गया है।

वर्ज़न की गई एसेट URLs बदली हुई फ़ाइल के लिए स्पष्ट आइडेंटिटी देती हैं। जब कोई डिप्लॉयमेंट नए फ़ाइलनाम की ओर इशारा करता है, तो कैश पुराने ऑब्जेक्ट को नए के साथ गड़बड़ किए बिना रख सकते हैं। यह तरीका उन एसेट्स के लिए उपयोगी है जिनकी सामग्री एक URL के तहत स्थिर रहनी चाहिए।

बार‑बार बदलने वाले डॉक्युमेंट्स को अलग फ़्रेशनेस पॉलिसी की ज़रूरत होती है। एक पब्लिक अनाउंसमेंट पेज और एक अकाउंट बैलेंस पेज की ज़रूरतें अलग होती हैं, भले ही दोनों HTML के रूप में डिलीवर हों। कैश लाइफ़टाइम को कंटेंट की स्वीकार्य स्टेलनैस और रिप्रेज़ेंटेशन की प्राइवेसी विशेषताओं के अनुसार होना चाहिए।

किसी अपडेट की जांच करते समय URL, रिस्पॉन्स हेडर और बॉडी वर्ज़न को साथ‑साथ तुलना करें। cache-status हेडर उपयोगी सबूत हो सकता है, लेकिन उसका फ़ील्ड नाम और व्याख्या प्रोवाइडर‑विशिष्ट होती है। किसी एक वेंडर की हेडर शब्दावली को सार्वभौमिक HTTP मानक मानने से बचें।

TLS टर्मिनेशन क्या बदलता है?

जो CDN TLS टर्मिनेट करता है वह क्लाइंट कनेक्शन को डिक्रिप्ट करता है और ओरिजिन के लिए अलग सुरक्षित कनेक्शन बना सकता है। TLS connection model हर सुरक्षित कनेक्शन पर अलग‑अलग लागू होता है।

एज को कंटेंट‑अवेयर राउटिंग और कैशिंग लागू करने के लिए HTTP रिक्वेस्ट तक पहुँच की ज़रूरत होती है। ओरिजिन के साथ उसका कनेक्शन अलग भरोसा और ट्रांसपोर्ट सेटिंग्स रखता है। पब्लिक होस्टनेम पर वैध सर्टिफिकेट अपने‑आप ओरिजिन‑फेसिंग कनेक्शन के कॉन्फ़िगरेशन को सत्यापित नहीं करता।

किसी कलेक्टर के लिए पब्लिक सर्टिफिकेट क्लाइंट के ट्रस्ट नियमों के तहत अपेक्षित एंडपॉइंट को ऑथेंटिकेट करता है। यह यह स्थापित नहीं करता कि बॉडी कैश से आई है या किस आंतरिक सेवा ने उसे जेनरेट किया, या पेज में इच्छित रिकॉर्ड हैं या नहीं। इन सवालों के लिए रिस्पॉन्स और कंटेंट निरीक्षण की ज़रूरत होती है।

रीजनल चेक अलग‑अलग कंटेंट क्यों दे सकते हैं

रीजनल चेक अलग हो सकते हैं क्योंकि वेबसाइट और डिलीवरी सिस्टम को अलग‑अलग रिक्वेस्ट कॉन्टेक्स्ट मिलते हैं। एग्ज़िट लोकेशन, रिज़ॉल्वर व्यवहार, भाषा हेडर, और संग्रहीत सेशन प्रेफ़रेंसेज़ सभी देखे गए रिप्रेज़ेंटेशन को प्रभावित कर सकते हैं। किसी अंतर को CDN असंगति कहने से पहले उसकी जांच होनी चाहिए।

The Scrapeless proxy location settings उपलब्ध एग्ज़िट लोकेशन चुनने का समर्थन करती हैं। तुलना के दौरान चुने गए भू‑क्षेत्र को स्थिर रखें और ऑब्ज़र्वेशन के साथ‑साथ लक्षित बाज़ार को दर्ज करें। किसी गेटवे का रीजन अपने‑आप वह एग्ज़िट रीजन नहीं होता जिसे डेस्टिनेशन उपयोग करता है।

Scrapeless Proxy Solutions आपके एप्लिकेशन के कंटेंट वैलिडेशन के स्वामित्व के साथ‑साथ इन चेक्स के लिए नेटवर्क व्यू‑पॉइंट दे सकती हैं। संबंधित cloud proxy architecture लेख मध्यस्थ की भूमिका समझाता है। रीजनल एसेट और पेज चेक्स की बैंडविड्थ का अनुमान लगाते समय Scrapeless pricing देखें।

एक उपयोगी ऑब्ज़र्वेशन रिकॉर्ड में अनुरोधित URL, अंतिम URL, कलेक्शन कॉन्टेक्स्ट, रिस्पॉन्स समय, और जहाँ उपयुक्त हो वहाँ कंटेंट आइडेंटिफ़ायर या हैश शामिल होता है। हैश उन बाइट्स की समानता साबित करता है जिनकी तुलना की जा रही है, न कि यूज़र अनुभव की समानता; डायनेमिक स्क्रिप्ट्स फिर भी समान शुरुआती डॉक्युमेंट्स से अलग रेंडर किया हुआ व्यवहार उत्पन्न कर सकती हैं।

CDN लक्षणों की व्याख्या कैसे करें

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

तेज़ी से दिया गया रिस्पॉन्स कोई एरर पेज हो सकता है जो एज पर संग्रहीत है या वहीं जेनरेट हुआ है। धीरे दिया गया रिस्पॉन्स फिर भी सही हो सकता है और अभी‑अभी ओरिजिन से लिया गया हो सकता है। केवल लेटेंसी परिणाम को वर्गीकृत नहीं कर सकती। एप्लिकेशन द्वारा आवश्यक फ़ील्ड्स और पेज मार्कर का उपयोग करें।

इसी तरह, किसी एक रिसोर्स की सफल CDN डिलीवरी यह साबित नहीं करती कि ऑथेंटिकेटेड एप्लिकेशन व्यू सही तरह से रेंडर हो रहा है। रिसोर्स पब्लिक हो सकता है जबकि व्यू को क्रेडेंशियल्स, स्क्रिप्ट्स और अन्य डिपेंडेंसीज़ की ज़रूरत हो। जब वास्तविक आवश्यकता वही हो तो पूरे यूज़र‑फेसिंग ऑपरेशन को वैलिडेट करें।

निष्कर्ष

CDN रिक्वेस्ट्स को रूट करता है और स्पष्ट कैश नियमों के तहत योग्य कंटेंट का पुन: उपयोग करता है। किसी रिस्पॉन्स की व्याख्या करने से पहले कैश की, फ़्रेशनेस पॉलिसी और TLS बाउंडरी को समझें। रीजनल डेटा काम के लिए, कलेक्शन कॉन्टेक्स्ट को सुरक्षित रखें और सफलता का आकलन लौटाए गए रिप्रेज़ेंटेशन से करें, सिर्फ डिलीवरी स्पीड से नहीं।