CDN से क्या डिलीवर करवाना है — फैसला करें
इन्वेंट्री से शुरू करें। इमेज, स्टाइलशीट, स्क्रिप्ट, फ़ॉन्ट और डाउनलोड जैसी संस्करण-आधारित एसेट को HTML, APIs, अकाउंट पेज, चेकआउट, और एडमिनिस्ट्रेशन से अलग करें। CDNs अक्सर मांग पर कैश भरते हैं: पहली रिक्वेस्ट ऑरिजिन तक जा सकती है, जबकि बाद की मिलती-जुलती रिक्वेस्ट किनारे (edge) पर सर्व हो सकती हैं। पास का edge और एक कैश हिट अलग-अलग लाभ हैं।
प्रत्येक पाथ को सप्लाई करने वाला होस्ट, एप्लिकेशन, स्टोरेज बकेट, या लोड बैलेंसर रिकॉर्ड करें; उसे कैश मिस पर जवाब देना चाहिए।
उन एसेट से शुरू करें जो हर विज़िटर के लिए समान हों और जो उनकी निर्दिष्ट जीवन-काल समाप्त होने तक सुरक्षित रूप से उपलब्ध रखी जा सकें।
पर्सनलाइज़्ड डैशबोर्ड, सेशन-बाउंड पेज, या ग्राहक डेटा को साझा न करें जब तक कि एक योग्य इंजीनियर ने पृथक्करण डिज़ाइन और परीक्षण न कर लिया हो।
सामग्री के व्यवहार से कैश नीति सेट करें
HTTP रिस्पॉन्स हेडर कैश व्यवहार व्यक्त करते हैं। Cache-Control बताता है कि एक प्रतिक्रिया संग्रहीत की जा सकती है और कितनी देर तक ताज़ा रहती है; समय-सीमा को TTL (time to live) कहा जाता है। ब्राउज़र एक प्राइवेट कैश है, जबकि CDN आमतौर पर साझा कैश होता है। स्पष्ट हेडर का उपयोग करें। HTTP स्टैंडर्ड shared-cache के लिए s-maxage को max-age से अलग से सेट करने की अनुमति देता है।
जब कंटेंट बदलता है तो नया URL प्रकाशित करें—उदाहरण के लिए कंटेंट-हैश्ड फ़ाइलनाम—और फिर अपरिवर्तनीय (immutable) संस्करण को लंबी, दस्तावेजीकृत जीवन-काल दें।
स्टेल कंटेंट की लागत के आधार पर छोटा TTL या वैलिडेशन व्यवहार चुनें; कीमतें, इन्वेंटरी, या अकाउंट स्टेट के लिए किसी एसेट नियम को पुन: उपयोग न करें।
एक यूज़र के लिए लक्षित प्रतिक्रियाओं के लिए response को private के रूप में सेट करें। केवल कुकी होने से प्रतिक्रिया साझा कैश के लिए सुरक्षित नहीं बन जाती।
इनवैलिडेशन (पर्ज़) को अपवाद बनाएं, रिलीज़ प्लान न बनाएं
इनवैलिडेशन या पुर्सिंग मैनेज्ड CDN को चयनित संग्रहीत ऑब्जेक्ट्स को सामान्य एक्सपायरी से पहले हटाने को बताती है। इसे करेक्शंस के लिए उपयोग करें, हर डिप्लॉय के लिए नहीं। पुर्ज़ करने से पहले पुष्टि करें कि ऑरिजिन पहले से ही रिप्लेसमेंट वापस कर रहा है; अन्यथा रीफ़िल坏 (refill) खराब प्रतिक्रिया को बरकरार रख सकता है। ब्राउज़र कैश CDN के पुर्ज़ नियंत्रण के बाहर होते हैं, इसलिए URL वर्ज़निंग बदलती फ़ाइलों के लिए भरोसेमंद बनी रहती है।
पूरे-साइट पुर्ज़ के बजाय किसी विशिष्ट पाथ, रिलीज़ ग्रुप, या प्रदाता-सपोर्टेड कैश टैग को प्राथमिकता दें; व्यापक मिसेस अचानक ऑरिजिन पर लोड कर सकते हैं।
एक वितरित पुर्ज़ हर edge तक एक साथ पहुँच सकता है यह जरूरी नहीं। प्रदाता की कम्प्लीशन सेमान्टिक्स जाँचें और एक प्रतिनिधि URL का परीक्षण करें।
पुराना और नया URL, कैश नियम, पुर्ज़ स्कोप, अपेक्षित परिणाम, और रिवर्सल स्टेप रिकॉर्ड करें।
डिलीवरी परत के पीछे ऑरिजिन रखें
डाइरेक्ट ऑरिजिन एक्सेस CDN कैशिंग और एज नियंत्रणों को बाईपास कर सकता है। इसे प्रतिबंधित करें ताकि केवल CDN और इरादे वाले पाथ ही पहुँच सकें। आपके स्टैक के अनुसार क्लाउड-ऑरिजिन एक्सेस कंट्रोल, दस्तावेजीकृत CDN एग्रीगेट ईग्रैस रेंज के साथ फ़ायरवॉल नियम, प्राइवेट नेटवर्किंग, साइन किए गए ऑरिजिन अनुरोध, या म्यूचुअल TLS (mTLS) का उपयोग करें, जहाँ दोनों पक्ष सर्टिफ़िकेट के साथ प्रमाणित होते हैं।
एक अधिकृत टेस्ट लोकेशन से पुष्टि करें कि ऑरिजिन सार्वजनिक अनुरोधों को अस्वीकार करता है जबकि CDN होस्टनाम काम कर रहा है।
हेल्थ चेक, डिप्लॉयमेंट टूल, और आंतरिक एक्सेस को विस्तृत सार्वजनिक नियम की बजाय पहचान और नेटवर्क के अनुसार स्कोप करें।
ऑरिजिन प्रमाणीकरण CDN और ऑरिजिन द्वारा अलग होता है। वर्तमान प्रदाता सेटअप मार्गदर्शन और सुरक्षा समीक्षा का उपयोग करें।
TLS को दो कनेक्शनों की तरह संभालें
एज पर HTTPS विज़िटर-से-CDN कनेक्शन को सुरक्षित करता है, पर CDN-से-ऑरिजिन कनेक्शन को भी सुरक्षा की आवश्यकता होती है। दोनों लेग पर एन्क्रिप्शन आवश्यक करें, CDN मोड के लिए ऑरिजिन सर्टिफ़िकेट को वेलिडेट करें, और होस्टनेम और नवीनीकरण का मालिक तय करें। OWASP डिफ़ॉल्ट रूप से TLS 1.3 की सिफारिश करता है और संगतता के लिए TLS 1.2 की अनुमति देता है; TLS 1.0 और 1.1 को डिसेबल करने की सलाह देता है। संवेदनशील या नियम-आधारित डेटा, पेमेंट फ्लो, या असामान्य क्लाइंट संगतता के लिए योग्य समीक्षा प्राप्त करें।
एज और ऑरिजिन सर्टिफ़िकेट मालिकों, नवीनीकरण मार्गों, और विफलता प्रतिक्रिया की सूची बनाएं।
HTTP-से-HTTPS, कैनॉनिकल-होस्ट, और डीप-लिंक रीडायरेक्ट्स में लूप्स या खोए हुए पाथ के लिए परीक्षण करें।
एन्क्रिप्शन किसी प्रतिक्रिया को कैश करने के लिए सुरक्षित नहीं बनाता; authenticated, personal, और payment-सीधे पृष्ठों के लिए अलग कैश नियम सेट करें।
ट्रैफ़िक बदलने से पहले वास्तविक डिलीवरी पाथ का परीक्षण करें
स्टेजिंग होस्टनेम या संकीर्ण प्रोडक्शन पाथ से शुरू करें, फिर CDN होस्टनेम का परीक्षण करें, सिर्फ़ ऑरिजिन का नहीं। Chrome DevTools Network अनुरोध की स्थिति, डोमेन, टाइमिंग, साइज, और हेडर दिखाता है। पहली विज़िट का अनुकरण करने के लिए empty-cache hard reload टेस्ट करें, फिर पुनरावृत्ति के लिए दोबारा विज़िट कर reuse का निरीक्षण करें। केवल तेज दिखने वाले पृष्ठ की बजाय अपेक्षित हेडर और कंटेंट की तुलना करें। जब ऑडियंस फैलाव में हो तो प्रतिनिधि क्षेत्र (regions) से दोहराएँ।
Cache-Control और प्रदाता cache-status हेडर्स का निरीक्षण करें। पुष्ट करें कि सार्वजनिक एसेट पुन: उपयोग हो रहे हैं और संवेदनशील पेज अनपेक्षित रूप से साझा नहीं हो रहे।
एक मिस, स्टेल-कंटेंट करेक्शन, ऑरिजिन त्रुटि, और एक एसेट या रूट के रोलबैक का अभ्यास करें इससे पहले कि व्यापक लॉन्च करें।
परीक्षित URL, हेडर कैप्चर्स, रूट-रूल वर्शन, और बदलाव रिकॉर्ड के साथ पहले और बाद के टाइमिंग सेव करें।
ऑपरेटिंग आवश्यकताओं के अनुसार CDN चुनें, फिर साबित करें
केवल पॉइंट-ऑफ-प्रेजेंस काउंट या एक सामान्य स्पीड दावा के आधार पर CDN न चुनें। प्रदर्शन भौगोलिक स्थान, समय, ट्रैफ़िक वितरण, रूटिंग, और कैश हिट रेशियो के साथ बदलता है। प्रतिनिधि रूट, एसेट, और क्षेत्रों पर उम्मीदवारों की तुलना करें। पूछें कि क्या हर एक आपके आवश्यक कैश कंट्रोल, लक्षित इनवैलिडेशन, ऑरिजिन प्रतिबंध, सर्टिफ़िकेट वर्कफ़्लो, लॉग, एक्सेस रोल, प्राइसिंग, सपोर्ट, और परिवर्तन प्रक्रिया का समर्थन करता है।
उम्मीदवारों के लिए समान कैश हेडर्स, ऑरिजिन व्यवहार, और पेज उपयोग करें; पहली विज़िट और दोबारा विज़िट परिणाम अलग-अलग रिकॉर्ड करें।
रिक्वेस्ट, ट्रांसफर, इनवैलिडेशन, लॉगिंग, और सपोर्ट लागतों की समीक्षा करें, साथ ही कैश-मिस सरज का खर्च। प्राइसिंग और कंट्रोल योजना के अनुसार भिन्न होते हैं।
निर्यात योग्य कॉन्फ़िगरेशन, सबसे कम-विशेषाधिकार (least privilege), परीक्षण रोलबैक, और κρίर यानस्पष्ट मालिकत्व की आवश्यकता रखें इससे पहले कि आप क्रिटिकल रूट कवर करें।