जो लगभग हर वेब सेवा के सामने बैठता है
स्वागत है
अगर आप ब्राउज़र में example.com टाइप करते हैं, तो आप लगभग कभी भी उस मशीन तक नहीं पहुंचते हैं जो वास्तव में एप्लिकेशन चलाती है। आप उस मशीन तक पहुंचते हैं जो अनुरोध (request) को उस मशीन को अग्रेषित (forwards) करती है जो इसे संभालती है। उस अग्रेषण करने वाली मशीन का एक नाम है: रिवर्स प्रॉक्सी।
यह पाठ आपको सिखाता है कि एक रिवर्स प्रॉक्सी क्या करता है, लगभग हर सार्वजनिक वेब सेवा एक के पीछे क्यों छिपती है, और एज लेयर एक साथ तीन काम कैसे संभालती है।
अंत तक आप समझ पाएंगे:
- क्लाइंट, प्रॉक्सी, और ओरिजिन के बीच का अंतर
- ओरिजिन के सामने प्रॉक्सी क्यों सुरक्षा प्रदान करता है, स्केल करता है, और किसी को पता नहीं चलने देता है कि आप घटकों को बदल रहे हैं
- रिवर्स प्रॉक्सी द्वारा एक साथ निभाए जाने वाले तीन कार्य: ओरिजिन को छिपाना, TLS समाप्त करना, और रिप्लिकाओं के बीच लोड का वितरण करना
- एक अनुरोध ब्राउज़र से प्रॉक्सी तक और फिर अपस्ट्रीम तक, और वापस कैसे यात्रा करता है, हर कदम (hop) के साथ
अंत तक आप प्रॉक्सी की स्थिति, एज पर चिंताओं की अलग-अलग व्यवस्था, और इस बात के बारे में आत्मविश्वास के साथ तर्क करेंगे कि एक स्टेटलेस प्रॉक्सी टियर सस्ती कीमत पर कई गुना बढ़ सकता है, जबकि एकल ओरिजिन ऐसा नहीं कर सकता।
फॉरवर्ड प्रॉक्सी बनाम रिवर्स प्रॉक्सी
प्रॉक्सी के दो दिशाएं
दोनों प्रकार के प्रॉक्सी दो पक्षों के बीच खड़े होते हैं और ट्रैफिक को आगे बढ़ाते हैं। उनमें यह अंतर है कि वे किस पक्ष का प्रतिनिधित्व करते हैं।
फॉरवर्ड प्रॉक्सी: यह एक समूह के क्लाइंट्स के सामने खड़ा होता है। क्लाइंट्स प्रॉक्सी के बारे में जानते हैं; एक बाहरी सर्वर प्रॉक्सी का पता देखता है, न कि क्लाइंट का पता। कॉर्पोरेट एग्रेस प्रॉक्सी, कंटेंट फिल्टर, और SOCKS प्रॉक्सी इस पैटर्न में आते हैं।
रिवर्स प्रॉक्सी: यह एक समूह के सर्वरों के सामने खड़ा होता है। बाहरी दुनिया (क्लाइंट्स) प्रॉक्सी पते से बात करती है; क्लाइंट्स को पता ही नहीं होता कि इसके पीछे एक वास्तविक सर्वर छिपा है। लगभग हर सार्वजनिक वेब सेवा एक का उपयोग करती है।
मनोमनिक (याद रखने की युक्ति): एक फॉरवर्ड प्रॉक्सी सर्वरों से क्लाइंट्स को छुपाता है। एक रिवर्स प्रॉक्सी क्लाइंट्स से सर्वरों को छुपाता है।
यह जानना क्यों ज़रूरी है कि यह किस दिशा में है? कार्य, विफलता के मोड (failure modes), और सुरक्षा सीमा (security boundary) सभी अलग होते हैं। एक फॉरवर्ड प्रॉक्सी यह चिंता करता है कि उसके उपयोगकर्ता किसे संपर्क करते हैं; एक रिवर्स प्रॉक्सी यह चिंता करता है कि उसके सर्वरों से किसे संपर्क किया जाता है।
एक क्लाइंट जो एक साथ दोनों प्रकारों के माध्यम से ट्रैफिक भेज रहा है, इस रास्ता तय करता है: client -> forward_proxy -> internet -> reverse_proxy -> origin।
एज पर इतना कुछ क्यों रहता है
एज लेयर अपनी कीमत चुकाती है
एक रिवर्स प्रॉक्सी एक ही समय पर तीन काम संभालता है। इनमें से कोई भी एक काम इस लेयर को सही ठहराने के लिए पर्याप्त है; सभी तीन काम एक ही पते पर संभालना यह समझाने के लिए पर्याप्त है कि लगभग हर प्रोडक्शन वेब आर्किटेक्चर सामने से एक ही आकार का दिखता है।
काम 1: ओरिजिन को छुपाएं। प्रॉक्सी एक सार्वजनिक IP पर जवाब देता है। बैकएंड्स प्राइवेट IP पर बैठे होते हैं जिन तक इंटरनेट नहीं पहुँच सकता। एक हमलावर जो ओरिजिन को निशाना बनाना चाहता है, उसे पहले प्रॉक्सी को ख़तरे में डालना होगा।
कार्य 2: TLS समाप्त करें। प्रॉक्सी example.com के लिए प्रमाणपत्र (certificate) रखता है और आगामी HTTPS अनुरोधों को डिक्रिप्ट करता है। बैकएंड प्रॉक्सी के साथ एक विश्वसनीय नेटवर्क खंड के माध्यम से सादर HTTP (या सरल आंतरिक TLS) बोलते हैं। प्रमाणपत्र रोटेशन, नवीनीकरण, और साइफर नीति—all एक ही स्थान पर होते हैं।
कार्य 3: लोड वितरित करें। प्रॉक्सी यह चुनता है कि प्रत्येक अनुरोध को कौन सा बैकएंड संभालेगा। एक प्रॉक्सी के पीछे के बैकएंड एक पूल बनाते हैं; प्रॉक्सी एक रणनीति (राउंड-रोबिन, लीस्ट-कनेक्शन, हेडर पर हैश) का उपयोग करके प्रत्येक अनुरोध के लिए एक बैकएंड चुनता है। क्षमता जोड़ने का मतलब है पूल में एक बैकएंड जोड़ना, न कि हर क्लाइंट को नया पता बताना।
प्रत्येक कार्य एक छोटा प्रोग्राम है। मिलकर वे यह समझाते हैं कि 'पाइथन ऐप के सामने Caddy' जितना सरल टियर भी पाइथन ऐप स्वयं से अधिक डिज़ाइन वजन क्यों रखता है।
तीनों के लिए डिज़ाइन करना
आपकी टीम एक छोटा API एकल पाइथन प्रोसेस पर चलाती है, जो एकल VM पर पोर्ट 8000 पर सुन रहा है। ट्रैफिक इतना बढ़ गया है कि एक VM का पता नहीं चल पा रहा है, और एक सुरक्षा समीक्षा ने यह चिह्नित किया है कि VM का एक सार्वजनिक IP है और यह अपना अपना TLS प्रमाणपत्र चलाता है।
आपने फैसला किया है कि सामने एक रिवर्स प्रॉक्सी रखना है। लेआउट का स्केच बनाएं: DNS कहाँ इशारा करता है, प्रमाणपत्र कहाँ रहता है, लोड बैकएंड तक कैसे पहुंचता है, और मूल VM में क्या बदलाव होता है?
किसी को भी पता न चलने दें और घटक (Component) बदलें
अप्रत्यक्षता (Indirection) स्वतंत्रता खरीदती है
एक पुरानी कंप्यूटर-विज्ञान कहावत है: हर समस्या को एक अंतराध्ययन (indirection) की परत जोड़कर हल किया जा सकता है (बस अत्यधिक अंतराध्ययन की परतों की समस्या को छोड़कर)। वितरित प्रणालियों में रिवर्स प्रॉक्सी सबसे उपयोगी अंतराध्ययनों में से एक है।
इससे आपको क्या मिलता है:
- बदलने योग्य बैकएंड। क्या आप एप्लिकेशन को पाइथन से गो (Go) में ले जा रहे हैं? एक डेटासेंटर से दूसरे में माइग्रेशन कर रहे हैं? शून्य डाउनटाइम के साथ एक नया वर्जन रोल आउट कर रहे हैं? ये सभी चीजें एक स्थिर सार्वजनिक पते के पीछे होती हैं। उपयोगकर्ताओं के लिए कुछ भी बदलता नहीं है।
- स्वतंत्र स्केलिंग। प्रॉक्सी परत TLS स्तर पर बैंडविड्थ और CPU के आधार पर स्केल होती है। बैकएंड परत एप्लिकेशन कार्य के आधार पर स्केल होती है। चूंकि वे अलग-अलग मशीनों पर चलते हैं, इसलिए प्रत्येक अपनी-अपनी अक्ष पर बढ़ता है।
- दोष निवारण (Fault containment)। बैकएंड पर एक खराब डेप्लॉयमेंट सार्वजनिक पते को बंद नहीं कर देता है। प्रॉक्सी चालू रहती है; आप एक सुधार धकेलते हैं या रोल बैक करते हैं; और जब बैकएंड रिकवर होता है, तो दुनिया फिर से कनेक्ट हो जाती है।
- एक ही जगह पर क्रॉस-कटिंग चिंताएं। रेट लिमिटिंग, जियो-ब्लॉकिंग, रिक्वेस्ट लॉगिंग, हेडर रीराइटिंग, कैशिंग, रिस्पॉन्स कम्प्रेशन: ये सभी प्रॉक्सी पर रहते हैं। बैकएंड कोड एप्लिकेशन पर केंद्रित रहता है।
प्रॉक्सी के बिना इनमें से हर एक समस्या को एप्लिकेशन प्रोसेस के अंदर रहना पड़ता है। प्रॉक्सी के साथ, वे एक ऐसी परत पर रहते हैं जिसे एक टीम स्वामित्व रखती है।
लागत: एक और परत जो संचालित करनी है। परिपक्व टीमें इस लागत को स्वीकार करती हैं क्योंकि प्रॉक्सी परत स्वयं स्टेटलेस (stateless) चलती है और क्षैतिज रूप से स्केल होती है; एक प्रॉक्सी को दो से बदलने के लिए कोई समन्वय आवश्यक नहीं है।
प्रॉक्सी के माध्यम से ब्लू/ग्रीन डिप्लॉयमेंट
आपकी टीम तीन बैकएंड VMs (ब्लू पूल) पर API के संस्करण 1 को एक रिवर्स प्रॉक्सी के पीछे चला रही है। आप संस्करण 2 को डिप्लॉय करना चाहते हैं, जिसमें यह क्षमता हो कि यदि कुछ गलत हो जाता है, तो तीस सेकंड से कम समय में रोल बैक किया जा सके।
आप संस्करण 2 चला रहे तीन नए बैकएंड VMs (ग्रीन पूल) को ब्लू पूल के साथ-साथ लॉन्च करते हैं, लेकिन आप अभी तक उन पर कोई ट्रैफिक राउट नहीं करते हैं।
ब्राउज़र से बैकएंड तक और वापस
एक अनुरोध को अंत से अंत तक ट्रैक करें
एक रिवर्स प्रॉक्सी के माध्यम से https://api.example.com/users/42 के एकल HTTPS GET को बैकएंड पूल के सामने से ट्रैक करें।
हॉप 1: DNS रिज़ॉल्यूशन। ब्राउज़र api.example.com के लिए रिज़ॉल्वर से पूछता है। रिज़ॉल्वर प्रॉक्सी का सार्वजनिक IP (जैसे, 203.0.113.10) लौटाता है। ब्राउज़र 203.0.113.10:443 के साथ एक TCP कनेक्शन खोलता है।
हॉप 2: TLS हैंडशेक। प्रॉक्सी api.example.com के लिए अपना प्रमाणपत्र प्रस्तुत करता है। ब्राउज़र प्रमाणपत्र की सत्यापन करता है, दोनों पक्ष एक सत्र कुंजी पर सहमत होते हैं, और एन्क्रिप्टेड चैनल खुल जाता है।
हॉप 3: TLS के अंदर HTTP अनुरोध। ब्राउज़र GET /users/42 HTTP/1.1\nHost: api.example.com\n... भेजता है। प्रॉक्सी अनुरोध बाइट्स को डिक्रिप्ट करता है।
Hop 4: Backend selection. प्रॉक्सी api.example.com के लिए अपने अपस्ट्रीम पूल की सलाह लेता है और अपने लोड-बैलेंसिंग रणनीति का उपयोग करके एक बैकएंड (जैसे 10.0.0.21:8000) का चयन करता है।
Hop 5: Upstream request. प्रॉक्सी 10.0.0.21:8000 के साथ एक साधारण HTTP कनेक्शन खोलता है (या पुनर्उपयोग करता है) और अनुरोध को आगे बढ़ाता है। प्रॉक्सी रास्ते में हेडर्स को पुनर्लेखित कर सकता है: X-Forwarded-For: <client-ip> जोड़ना, Host: को सही से सेट करना, और Connection जैसे hop-by-hop हेडर्स को हटाना।
Hop 6: Backend processing. बैकएंड एप्लिकेशन अनुरोध को पढ़ता है, अपने डेटाबेस से पूछताछ करता है, और एक JSON प्रतिक्रिया बनाता है।
Hop 7: Upstream response. बैकएंड प्रतिक्रिया को साधारण HTTP के रूप में प्रॉक्सी को वापस भेजता है।
Hop 8: Edge response. प्रॉक्सी प्रतिक्रिया को पुनर्लेखित या संपीड़ित कर सकता है, इसे TLS सत्र के माध्यम से फिर से एन्क्रिप्ट करता है, और इसे ब्राउज़र को भेजता है।
Hop 9: Connection lifecycle. TLS सत्र आमतौर पर अगले अनुरोध के लिए खुला रहता है (HTTP/2 एक कनेक्शन पर कई अनुरोधों को मल्टीप्लेक्स करता है)। प्रॉक्सी-से-बैकएंड कनेक्शन अक्सर पुनर्उपयोग के लिए पूल किया जाता है।
हर सार्वजनिक वेब सेवा इस रूप का कोई न कोई विचरण (variant) अनुसरण करती है। हॉप्स को जानने से आपको यह तर्क करने में सक्षम बनाता है कि लेटेंसी कहाँ जमा होती है, लॉगिंग कहाँ होनी चाहिए, और विफलता कहाँ छुप सकती है।
समय कहाँ गया?
एक उपयोगकर्ता शिकायत करता है कि API धीमा लग रहा है। आपने माप किया और पाया कि अनुरोध (request) को अंत से अंत तक 850 ms लगते हैं। बैकएंड पर सर्वर लॉग दिखाते हैं कि एप्लिकेशन ने अनुरोध को 40 ms में प्रदान किया। प्रॉक्सी लॉग दिखाते हैं कि प्रॉक्सी ने अपने पक्ष की कार्यवाही (TLS हैंडशेक + राउटिंग + प्रतिक्रिया लेखन) में 50 ms बिताए।
नए सेवा के लिए एक न्यूनतम एज (Edge) डिज़ाइन करें
संश्लेषण
आपने सीखा है कि फॉरवर्ड और रिवर्स प्रॉक्सी के बीच अंतर क्या है, एक रिवर्स प्रॉक्सी एक साथ तीन काम कैसे संभालती है, ओरिजिन को छिपाने से हर बार बदलाव की आवश्यकता होने पर लाभ कैसे होता है, और एक अनुरोध (request) एज के माध्यम से हॉप-बाय-हॉप (hop by hop) कैसे प्रवाहित होता है।
अब इसे लागू करें।
एक छोटी टीम notes.example.com नामक एक नई सेवा लॉन्च करने की योजना बना रही है। उपयोगकर्ता व्यक्तिगत नोट्स पढ़ेंगे और लिखेंगे। लॉन्च के समय टीम दो बैकएंड VM चलाएगी और अगले वर्ष में दस तक स्केल होने की उम्मीद है। उन्हें उपयोगकर्ताओं के लिए HTTPS, नए वर्शनों के लिए क्रमिक रोलआउट (gradual rollout), और बैकएंड IP का कोई सार्वजनिक प्रदर्शन नहीं चाहिए।
यह कोर्स आगे कहाँ जाता है
यह कोर्स आगे कहाँ जाता है
इस पाठ ने एज लेयर का आकार स्थापित किया। इस कोर्स में चार और पाठ इस पर आधारित हैं:
- स्टेटलेस हॉरिज़ॉन्टल स्केलिंग: यह कि एक प्रॉक्सी टियर (और उसके पीछे के बैकएंड) सस्ते में कई गुना क्यों बढ़ते हैं, और सर्ज के तहत रिप्लिका संख्याओं के साइज़िंग के लिए गणित।
- इंग्रेस / एज्रेस अलगाव: यह कि एकल प्रॉक्सी बॉक्स जो आने वाली और जाने वाली दोनों यातायात को संभालता है, अंततः आश्चर्यजनक तरीकों से विफल हो जाता है, और लेयर्स को कैसे अलग किया जाए।
- विफलता मोड और ब्लैस्ट रेडियस: एकल कॉन्फ़िगरेशन परिवर्तन कैसे एक आउटेज में बदल जाता है, और दोहराव को रोकने के लिए बिना दोषारोपण वाले कार्रवाई आइटम (blameless action items) कैसे लिखे जाएं।
- ओब्ज़र्वेबिलिटी और क्षमता: एज (edge) पर क्या मापना है ताकि उपयोगकर्ताओं को पता चलने से पहले ही आपको पता चल सके कि कुछ टूट गया है।
हर पाठ स्वतंत्र है। एक साथ मिलकर ये आपको वेब-स्केल फ्लीट (web-scale fleet) का एक कार्यशील मानसिक मॉडल (mental model) प्रदान करते हैं।
संगत पाठ: geometry_of_proxies_and_origins इस पाठ में मौजूद सब कुछ एक निर्देशित ग्राफ़ (directed graph) के रूप में प्रस्तुत करता है और यह अन्वेषण करता है कि ग्राफ़ सिद्धांत (graph theory) आपको एक अनुरोध पथ (request path) के बारे में क्या बताता है।
बहुत बढ़िया। आगे बढ़िए।