डेटा केंद्र प्रॉक्सी क्या है?

स्क्रैपलेस प्रॉक्सी कम विलंबता, उच्च थ्रूपुट वेब अनुरोधों के लिए प्रबंधित डेटा केंद्र प्रॉक्सी रूट प्रदान करता है।

परिभाषा

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

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

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

डेटा केंद्र प्रॉक्सी बुनियादी ढांचे के काम करने का तरीका

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

चूंकि निकासी प्रबंधित सर्वर नियंत्रण में है, प्रदाता क्षमता की निगरानी कर सकते हैं, निर्धारित क्षेत्रों के माध्यम से ट्रैफिक को रूट कर सकते हैं, और निश्चित पते की पेशकश कर सकते हैं। घूर्णन अभी भी संभव है: एक गेटवे प्रत्येक अनुरोध या सत्र के लिए एक नया सर्वर आईपी चुन सकता है। स्थिर और घूर्णन इसलिए आवंटन नीति का वर्णन करते हैं, न कि यह सुनिश्चित करते हैं कि एक पता किसी डेटा केंद्र से संबंधित है।

एक SOCKS तैनाती एचटीटीपी से परे प्रोटोकॉल को पास कर सकती है। SOCKS5 मानक रिले परत पर प्रमाणीकरण वार्ता और कनेक्ट अनुरोधों को परिभाषित करता है। एक एचटीटीपी प्रॉक्सी इसके बजाय एचटीटीपी अनुरोध लक्ष्यों या कनेक्ट सुरंगों को समझता है। अनुप्रयोग को चुने गए विधि का समर्थन करना चाहिए और अनिच्छित नेटवर्क पथ पर नामों को हल करने से बचना चाहिए।

1. ग्राहक एक प्रॉक्सी एंडपॉइंट का चयन करता है और प्रमाणीकरण करता है।
2. प्रॉक्सी पूल, स्थान, सत्र, और पहुंच नियम लागू करता है।
3. प्रॉक्सी अनुरोधित गंतव्य की ओर एक आउटबाउंड कनेक्शन बनाती है।
4. गंतव्य प्रतिक्रिया प्रॉक्सी के माध्यम से ग्राहक को लौटती है।

मुख्य आयाम

डेटा केंद्र प्रॉक्सी क्या है, इसे एक विपणन लेबल के बजाय अवलोकनीय नेटवर्क और सत्र गुणों के एक संग्रह के रूप में समझा जाता है।

सामान्य उपयोग के मामले

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

साझा, समर्पित, स्थिर या घुमाने वाला?

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

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

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

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

डेटा केंद्र प्रॉक्सी प्रतिबंध

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

साझा पते एक और अनिश्चितता पैदा करते हैं: एक ग्राहक दूसरों के लिए प्रतिष्ठा को प्रभावित कर सकता है। समर्पित पते उस युग्मन को कम करते हैं लेकिन प्रतिष्ठा प्रबंधन को पूरी तरह से मालिक पर सौंप देते हैं। अनुरोध की मात्रा को उपयुक्त रखें, अनियंत्रित समवर्तन से बचें, और रिस्पॉन्स श्रेणियों की निगरानी करें ताकि एक एप्लिकेशन तब तक ट्रैफिक नहीं भेजता जब तक कि उसे पहुँच अस्वीकृत न कर दी गई हो।

पता अनुवाद एक पहचान प्रणाली नहीं है। IETF द्वारा प्रलेखित NAT शब्दावली और व्यवहार दिखाते हैं कि मानचित्र निजी और सार्वजनिक पते के क्षेत्रों को जोड़ते हैं; वे यह नहीं साबित करते कि प्रत्येक एप्लिकेशन अनुरोध को किसने संचालित किया। एप्लिकेशन-स्तरीय प्रमाणीकरण और ऑडिट संदर्भ को अलग से बनाए रखें।

संबंधित प्रॉक्सी प्रकार और सत्र मॉडल

जब पते की उत्पत्ति और सत्र व्यवहार की स्वतंत्र रूप से तुलना की जाती है, तो प्रॉक्सी आर्किटेक्चर के बारे में सोचना आसान हो जाता है।

ऑपरेशन्स और जिम्मेदार उपयोग

प्रॉक्सी परत को मापा गया बुनियादी ढाँचा मानें। चुने गए क्षेत्र, प्रॉक्सी कक्षा, सत्र नीति, लक्षित होस्ट, प्रतिक्रिया स्थिति, प्रतिक्रिया समय, और स्थानांतरित बाइट्स को बिना प्रमाणपत्रों या संवेदनशील सामग्री को लॉग किए रिकॉर्ड करें। नेटवर्क विफलताओं को अनुप्रयोग विफलताओं से अलग करें: एक पहुँचा जा सकने वाली प्रॉक्सी फिर भी लक्षित पक्ष का इंकार कर सकती है, जबकि एक मान्य पृष्ठ अभी भी पार्सिंग में विफल हो सकता है। यह विभाजन क्षमता योजना और घटना समीक्षाओं को एकल सफलता काउंटर की तुलना में बहुत अधिक उपयोगी बनाता है।

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

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

निष्कर्ष

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

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