गहन विश्लेषण: रेजिडेंशियल प्रॉक्सी नेटवर्क कैसे काम करता है? आर्किटेक्चर समझाया गया

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

शुरुआत करने के लिए, आइए परिभाषित करें कि रेजिडेंशियल नेटवर्क क्या है: पीयर्स का एक नेटवर्क जो गंतव्यों के लिए पैकेट को प्रॉक्सी करने में सक्षम है।

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

1. SDK

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

2. मानक बनाम प्रॉक्सी अनुरोध

यहाँ एक मानक HTTPS अनुरोध कैसे रूट किया जाता है (L4 से L7)। नीचे RTT गणना संचयी हैं; प्रत्येक परत चलते-चलते कुल में जोड़ती है, और ताज़ा कनेक्शन मानती है:

TCP हैंडशेक (चरण: 1 RTT | संचयी: 1 RTT)

1. उपयोगकर्ता गंतव्य को SYN भेजता है

2. गंतव्य उपयोगकर्ता को SYN-ACK भेजता है

3. उपयोगकर्ता गंतव्य को ACK भेजता है (डेटा इस अंतिम सेगमेंट पर सवार हो सकता है)

चरण लागत: 1 RTT, जो चलते-चलते समय को 1 RTT पर लाता है। RFC 9293।

L5/L6: (चरण: TLS 1.3 के लिए 1 RTT / TLS 1.2 के लिए 2 RTT | संचयी: TLS 1.3 के साथ 2 RTT / TLS 1.2 के साथ 3 RTT)

1. उपयोगकर्ता गंतव्य को ClientHello भेजता है

2. गंतव्य उपयोगकर्ता को ServerHello, EncryptedExtensions, Certificate, CertificateVerify, Finished भेजता है

चरण लागत: आधुनिक TLS 1.3 के लिए 1 RTT (संचयी: 2 RTT), या विरासत TLS 1.2 के लिए 2 RTT (संचयी: 3 RTT)

अपने आप में, TLS 1.3 एक 1-RTT हैंडशेक है, और TLS 1.2 2-RTT है; यहाँ कुल TCP राउंड ट्रिप सहित संचयी हैं, इसलिए TLS 1.2 एक पूरा अतिरिक्त RTT जोड़ता है (कुल 3 RTT)। TLS 1.3 ज्ञात रीप्ले ट्रेड-ऑफ के साथ दोहराए गए कनेक्शन पर 0-RTT रिज़्यूमेशन भी कर सकता है।

L7: एप्लिकेशन परत (चरण: 1 RTT | संचयी: TLS 1.3 के साथ 3 RTT / TLS 1.2 के साथ 4 RTT)

1. उपयोगकर्ता गंतव्य को Request + Headers भेजता है

2. गंतव्य उपयोगकर्ता को Response + Headers भेजता है

चरण लागत: 1 RTT, अंतिम समय को पहले डेटा बाइट तक TLS 1.3 के तहत 3 RTT या TLS 1.2 के तहत 4 RTT पर लाता है

एक बार जब आप एक प्रॉक्सी जोड़ते हैं, तो यह हमेशा कम से कम एक हॉप और कुछ लेटेंसी जोड़ता है: पथ लंबा है (उपयोगकर्ता → प्रॉक्सी → गंतव्य, और वापस), और प्रॉक्सी अपना स्वयं का प्रोसेसिंग समय जोड़ता है। क्या यह राउंड-ट्रिप भी जोड़ता है यह प्रॉक्सी प्रकार पर निर्भर करता है।

एक समाप्ति प्रॉक्सी (एक HTTP फॉरवर्ड प्रॉक्सी CONNECT का उपयोग करके, या एक रेजिडेंशियल गेटवे जो अपना स्वयं का अपस्ट्रीम कनेक्शन खोलता है) उन्हें जोड़ता है: क्लाइंट पहले प्रॉक्सी के साथ हैंडशेक करता है, और HTTPS के लिए, CONNECT अनुरोध और इसकी "200 Connection Established" प्रतिक्रिया स्वयं के लिए एक राउंड ट्रिप हैं, इससे पहले कि end-to-end TLS हैंडशेक भी शुरू हो, फिर प्रॉक्सी गंतव्य की ओर हैंडशेक करता है।

एक पारदर्शी L3/L4 फॉरवर्डर जो कनेक्शन को समाप्त नहीं करता, हैंडशेक को end-to-end छोड़ देता है और कोई अतिरिक्त राउंड ट्रिप नहीं जोड़ता, बस लंबा पथ। किसी भी तरह, अधिक दूरी और अधिक मध्यस्थ का मतलब है अधिक लेटेंसी, जो बिल्कुल यही है जो इस लेख का बाकी हिस्सा कम करने के बारे में है।

3. "ट्रैफिक जाम" समस्या

रेजिडेंशियल नेटवर्क अत्यंत जटिल हैं क्योंकि नेटवर्क को धीमा किए बिना अनुरोधों को बुद्धिमानी से रूट करने में कई बारीकियां होती हैं।

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

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

4. प्रदाता-पक्ष अनुकूलन

4a. DNS और डेटासेंटर

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

4b. परत 4 आंतरिक अनुकूलन

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

4c. परत 4 बाहरी अनुकूलन

SDK लोकप्रिय गंतव्यों के लिए वार्म किए गए TCP कनेक्शन को बनाए रख सकता है ताकि पीयर और गंतव्य के बीच 1 RTT सहेजा जा सके, क्योंकि एप्लिकेशन परत को हमेशा मौजूदा TCP कनेक्शन के ऊपर पुनर्निर्माण किया जा सकता है।

4d. पैरामीटर कॉन्फ़िगरेशन

TCP पैरामीटर को वास्तविक समय में ट्यून किया जा सकता है ताकि पैकेट ट्रांसमिशन को अधिक कुशल बनाया जा सके और SDK द्वारा CPU/RAM उपयोग को कम किया जा सके। संसाधन खपत को कम करना महत्वपूर्ण है। यदि SDK पीयर के उपकरण पर एक नकारात्मक अनुभव बनाता है, तो प्रकाशक SDK अनुबंध को छोड़ देंगे।

4e. बुद्धिमान राउटिंग एल्गोरिदम (प्रदर्शन-आधारित)

यह सबसे कठिन, लेकिन सबसे प्रभावी अनुकूलन है। नेटवर्क सभी गेटवे के पार एक वास्तविक-समय, इन-मेमोरी डेटाबेस बनाए रखता है जिसे तुरंत क्वेरी किया जा सकता है: "कौन सा उपकरण इस अनुरोध को रूट करने के लिए सर्वोत्तम उपयुक्त है?"

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

4f. IP कैपिंग एल्गोरिदम (प्रतिष्ठा-आधारित)

रेजिडेंशियल नेटवर्क को गंतव्य प्रति IP प्रतिष्ठा को संरक्षित करने में रुचि है। यदि पूल का एक-तिहाई गंतव्य A, B, और C से ब्लैकलिस्ट किया गया है, तो उन गंतव्यों को लक्ष्य करने वाले उपयोगकर्ता 33% त्रुटि दर देखते हैं। केवल शेष 67% के माध्यम से रूटिंग करके और ब्लैकलिस्ट किए गए IP को कूलडाउन पर रखकर, नेटवर्क ग्राहकों को काफी बेहतर अनुभव प्रदान करता है।

IP कैपिंग एल्गोरिदम बनाने और बनाए रखने के लिए जटिल हैं, लेकिन जब सही तरीके से किया जाता है तो नेटवर्क गुणवत्ता में महत्वपूर्ण सुधार देते हैं।

5. क्लाइंट-पक्ष अनुकूलन

5a. डेटासेंटर

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

5b. DNS

डोमेन नाम को स्वयं पास करें, न कि इसके समाधान किए गए IP पते को। यह पीयर को DNS संकल्प करने की अनुमति देता है, जिसके परिणामस्वरूप अधिक कुशल राउटिंग हो सकती है। हमेशा SNI फील्ड में डोमेन शामिल करें ताकि TLS हैंडशेक सफल हो सके।

5c. भू-लक्ष्यीकरण

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

5d. L4 और स्टिकी सेशन अनुकूलन

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

एक पेशेवर प्रॉक्सी उपयोगकर्ता प्रति IP एक कनेक्शन बनाए रखता है, प्रत्येक 10 से 20 सेकंड में निकास IP की निगरानी करता है ताकि यह पुष्टि हो सके कि पीयर अभी भी सक्रिय है, और प्रदर्शन के आधार पर पीयर्स में लोड-बैलेंस करता है। उदाहरण के लिए, यदि एक लक्ष्य 50 अनुरोधों के बाद दर-सीमा करता है, तो 25 से 30 पर वापस ले लें, या सीमा तक पहुँचने पर घुमाएं।

मूल सिद्धांत: जब अपर्याप्त पीयर्स उपलब्ध हों, तो प्रत्येक पीयर की क्षमता को अधिकतम करें, दर सीमा, नेटवर्क गति, और भीड़ प्रबंधन के संदर्भ में।

FlashProxy के CEO एलॉन लेवी द्वारा प्रकाशित

लेखक के बारे में: एलॉन लेवी FlashProxy के CEO हैं और प्रॉक्सी बुनियादी ढांचे, नेटवर्क आर्किटेक्चर, और बड़े पैमाने पर IP राउटिंग प्रौद्योगिकियों में व्यापक अनुभव रखते हैं।  

LinkedIn पर कनेक्ट करें  ·  संपर्क: [email protected]

अक्सर पूछे जाने वाले प्रश्न

रेजिडेंशियल प्रॉक्सी डेटासेंटर प्रॉक्सी से धीमे क्यों हैं?

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

प्रॉक्सी में स्टिकी सेशन क्या है?

एक स्टिकी सेशन एक निर्धारित अवधि के लिए अनुरोधों को एक ही IP पते के माध्यम से रूट रखता है। यह उन कार्यों के लिए उपयोगी है जिनके लिए सेशन निरंतरता आवश्यक है, जैसे लॉगिन स्थिति बनाए रखना या शॉपिंग कार्ट को पकड़ना।

रेजिडेंशियल प्रॉक्सी IP क्यों ब्लैकलिस्ट किए जाते हैं?

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

एक प्रॉक्सी पीयर क्या है?

एक प्रॉक्सी पीयर एक वास्तविक उपभोक्ता उपकरण (फोन, कंप्यूटर, या स्मार्ट TV) है जिसका इंटरनेट कनेक्शन प्रॉक्सी ट्रैफिक को रूट करने के लिए उपयोग किया जाता है, उपकरण मालिक की सहमति के साथ, एक SDK के माध्यम से जो उन्होंने एक ऐप में स्थापित किया है।

स्रोत और संदर्भ

• IETF RFC 9293, Transmission Control Protocol: https://datatracker.ietf.org/doc/html/rfc9293

• IETF RFC 8446, TLS 1.3 (1-RTT handshake; 0-RTT resumption): https://datatracker.ietf.org/doc/html/rfc8446

• IETF RFC 5246, TLS 1.2 (2-RTT handshake): https://datatracker.ietf.org/doc/html/rfc5246

• IETF RFC 9110, HTTP Semantics (CONNECT method): https://datatracker.ietf.org/doc/html/rfc9110

• IETF RFC 6066, TLS Server Name Indication (SNI): https://datatracker.ietf.org/doc/html/rfc6066

• IETF RFC 7235, HTTP/1.1 Authentication (Proxy-Authorization): https://datatracker.ietf.org/doc/html/rfc7235

• MDN Web Docs, HTTP CONNECT method: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/CONNECT

• Cloudflare, forward-proxy latency: https://blog.cloudflare.com/how-we-think-about-zero-trust-performance/

• Cloudflare Learning Center, What is SNI?: https://www.cloudflare.com/learning/ssl/what-is-sni/

• Ilya Grigorik, High Performance Browser Networking: https://hpbn.co/