वेब सेवा के सामने बैठने वाली चीज
स्वागत
यदि आप example.com को ब्राउज़र में टाइप करते हैं, तो आपने लगभग कभी भी उस मशीन के संपर्क में नहीं आया होता है जो वास्तविक एप्लिकेशन चलाती है। आप एक ऐसी मशीन तक पहुंचते हैं जो अनुरोध को एक ऐसी पर चला देती है जो करता है। वह अनुवाद करने वाली मशीन को विपरीत प्रॉक्सी का नाम दिया गया है।
इस पाठशाला में सीखें कि विपरीत प्रॉक्सी क्या करता है, क्यों लगभग हर पब्लिक वेब सेवा को एक प्रॉक्सी के सामने छिपा होता है, और एक्सेस लेयर के द्वारा एक ही समय में तीन काम क्या करता है।
इस पाठ के अंत में आप समझेंगे:
- क्लाइंट, प्रॉक्सी और मूल के बीच अंतर
- क्यों एक प्रॉक्सी को मूल के सामने रखकर सुरक्षा, वृद्धि, और किसी को भी ध्यान नहीं देने देने का काम करता है।
- एक विपरीत प्रॉक्सी द्वारा एक बार में तीन काम: मूल को छिपाना, TLS समाप्त करना, और रिप्लिका के बीच लोड का वितरण
- ब्राउज़र से प्रॉक्सी के माध्यम से ब्राउज़र तक अनुरोध का सफर, हॉप-बी-हॉप
इस पाठ के अंत में आप विश्वसनीय रूप से प्रॉक्सी के स्थान, एज लेयर में चिंताओं के विभाजन और एक स्टेटलेस प्रॉक्सी टियर को सस्ते में कई बार करने के बारे में विचार कर सकेंगे, जबकि एक मूल को नहीं कर सकता।
विपरीत प्रॉक्सी vs प्रॉक्सी
दो प्रॉक्सी दिशाएं
दोनों प्रकार के प्रॉक्सी दो पक्षों के बीच खड़े होते हैं और ट्रैफिक को रिले करते हैं। उनका अंतर जिस पक्ष को वे प्रतिनिधित्व करते हैं।
प्रॉक्सी को आगे: ग्रुप ऑफ क्लाइंट के सामने खड़ा होता है। ग्राहकों को प्रॉक्सी के बारे में पता होता है; बाहरी सर्वर को प्रॉक्सी के पते के बजाय ग्राहक के पते का पता चलता है। कॉर्पोरेट ईग्रेस प्रॉक्सी, कंटेंट फिल्टर्स और SOCKS प्रॉक्सी इस पैटर्न में आते हैं।
विपरीत प्रॉक्सी: एक समूह के सर्वर के सामने खड़ा होता है। बाहरी दुनिया (क्लाइंट) प्रॉक्सी के पते से बात करता है; ग्राहकों को पता नहीं होता है कि वास्तव में एक सर्वर इसके पीछे छिपा होता है। लगभग हर पब्लिक वेब सेवा इसे उपयोग करती है।
मेमन्टिक: एक प्रॉक्सी आगे हाइड क्लाइंट्स फ्रॉम सर्वर। एक विपरीत प्रॉक्सी हाइड सर्वर फ्रॉम क्लाइंट।
क्यों किस दिशा के बारे में चिंता करें? नौकरी, विफलता के मोड और सुरक्षा क्षेत्र सभी भिन्न होते हैं। एक आगे प्रॉक्सी को उसके उपयोगकर्ता से किसी भी संपर्क की चिंता होती है, जबकि एक विपरीत प्रॉक्सी को उसके सर्वर से संपर्क करता है।
क्लाइंट ट्रैफिक दोनों प्रकार के साथ एक साथ यात्रा करता है: client -> forward_proxy -> internet -> reverse_proxy -> origin.
क्यों एज लेयर में इतना काम होता है
एज लेयर का काम होता है
एक विपरीत प्रॉक्सी तीन काम एक ही समय में करता है। इनमें से कोई भी परत को उचित बना सकता है; सभी तीनों पतों को एक ही पते पर ले जाने के लिए प्रोडक्शन वेब आर्किटेक्चर के प्रत्येक प्रोडक्शन वेब आर्किटेक्चर के सामने एक ही आकार का कारण होता है।
काम 1: मूल को छिपाएं। प्रॉक्सी एक सार्वजनिक आईपी पर उत्तर देता है। बैकएंड्स सार्वजनिक आईपी को नहीं पहुंच सकते। एक हमलावर जो मूल को छूना चाहता है, उसे पहले प्रॉक्सी को तोड़ना होगा।
काम 2: TLS समाप्त करें। प्रॉक्सी example.com के लिए सертиफिकेट रखता है और आने वाले HTTPS अनुरोधों को डिक्रिप्ट करता है। बैकएंड प्रॉक्सी के साथ एक विश्वसनीय नेटवर्क सेगमेंट के माध्यम से सादे HTTP (या आसान अंतर्निहित TLS) को प्रॉक्सी के साथ बातचीत करते हैं। सертиफिकेट रोटेशन, नवीनीकरण और साइफर नीति सभी एक ही स्थान पर रहते हैं।
काम 3: लोड वितरण। प्रॉक्सी प्रत्येक अनुरोध के लिए किस बैकएंड को संभालता है। प्रॉक्सी के पीछे के बैकएंड एक पूल बनाते हैं; प्रॉक्सी प्रति अनुरोध एक रणनीति (चक्र, सबसे कम कनेक्शन, हैश एक हेडर पर) का उपयोग करके एक चुनती है। क्षमता बढ़ाने के लिए पूल में एक और बैकएंड जोड़ने की आवश्यकता होती है, नहीं कि हर ग्राहक को एक नया पता बताने की।
प्रत्येक काम एक छोटा प्रोग्राम है। मिलकर वे 'कैडी के सामने एक पायथन ऐप' जैसे एक स्तर को इतना वजन देते हैं कि पायथन ऐप खुद को समझा नहीं जा सकता।
सभी तीन के लिए डिज़ाइन करें
आपकी टीम एक छोटे API को सिंगल पायथन प्रक्रिया पर चला रही है जो पोर्ट 8000 पर सुनता है और एक सिंगल वीएम पर ट्रैफिक होता है। ट्रैफिक ने इतना बढ़ा है कि एक वीएम को काम नहीं कर पा रहा है और सुरक्षा समीक्षा में पाया गया कि वीएम को सार्वजनिक आईपी मिली हुई है और अपने TLS सертиफिकेट को चला रही है।
आप फ्रंट में एक विपरीत प्रॉक्सी डालेंगे। डिज़ाइन का निर्माण: DNS को कहाँ ले जाता है, सертиफिकेट की स्थिति, लोड को बैकएंड तक कैसे पहुंचता है, और मूल वीएम को क्या मिलता है या क्या खो जाता है।
किसी को भी ध्यान नहीं आयेगा कंपोनेंट का बदलाव
परिप्रेक्ष्य स्वतंत्रता खरीदता है
पुराने संगणक विज्ञान के मान्यों में एक है: प्रत्येक समस्या को समाधान के लिए एक परत जोड़ने की क्षमता है (सिवाय पर्याप्त संख्या में परतों की समस्या के)। वितरित प्रणालियों में सबसे उपयोगी परिप्रेक्ष्यों में से एक रिवर्स प्रॉक्सी है।
आपको क्या मिलता है:
- पीछे के सर्वर को स्वैप करना। एप्लिकेशन को पायथन से गो में मूव करें? एक डेटा सेंटर से दूसरे में माइग्रेट करें? एक नयी वर्जन को रोल आउट करें जो डाउनटाइम के साथ ना हो? प्रत्येक काम पब्लिक एड्रेस के पीछे एक स्थिर होता है। यूजर्स के लिए कुछ नहीं बदलता है।
- 独立 पैमाना। प्रॉक्सी टायर बैंडविड्थ और CPU पर टीएलएस पर स्केल करता है। पीछे के टायर एप्लिकेशन काम पर स्केल करता है। प्रत्येक अपने स्वयं के अक्ष पर बढ़ता है क्योंकि वे अलग-अलग मशीनों पर रहते हैं।
- क्षेत्रीय समस्याओं को सीमित करता है। पीछे के सर्वर पर एक बुरा डिप्लॉय नहीं करता है जो पब्लिक एड्रेस को नीचे नहीं लाता है। प्रॉक्सी उपस्थित रहता है; आप एक सुधार करते हैं या वापस करते हैं; दुनिया पीछे के सर्वर के साथ जब फिर से जुड़ती है।
- प्रॉक्सी पर क्रॉस-कटिंग चिंताओं को एक स्थान पर रखें। रेट लिमिटिंग, जियो-ब्लॉकिंग, रिक्वेस्ट लॉगिंग, हेडर रिव्राइटिंग, क्याचिंग, रिस्पांस कम्प्रेशन: सभी प्रॉक्सी पर रहते हैं। पीछे के कोड एप्लिकेशन पर केंद्रित रहता है।
प्रॉक्सी के बिना प्रत्येक समस्या को एप्लिकेशन प्रोसेस के अंदर रहना पड़ता है। प्रॉक्सी के साथ वे एक परत पर रहते हैं जो एक टीम के पास होती है।
लागत: एक और परत को संचालित करना होगा। संगठित टीमें लागत को स्वीकार करती हैं क्योंकि प्रॉक्सी टायर खुद राज्यहीन और क्षैतिज रूप से स्केल करता है; एक प्रॉक्सी को दो से बदलने के लिए किसी भी संगति की आवश्यकता नहीं होती है।
प्रॉक्सी के माध्यम से ब्लू/ग्रीन डिप्लॉय
आपकी टीम 1 वेरिएंट के API को तीन पीछे के VM (नीले पूल) पर चला रही है जो रिवर्स प्रॉक्सी के पीछे है। आप 2 वेरिएंट को डिप्लॉय करना चाहते हैं जो तीस सेकंड के अंतर्गत रोलबैक करने में सक्षम हो सकता है अगर कुछ गलत हो जाए।
आप 2 वेरिएंट को चलाने के लिए तीन नई बैकेंड VM (ग्रीन पूल) लॉन्च करते हैं, नीले पूल के साथ साइड-बाय-साइड, लेकिन अभी तक किसी ट्रैफ़िक को उनके दिशा में नहीं भेजते हैं।
ब्राउज़र से बैकएंड तक और वापस
एक ही अनुरोध का पालन करें
पीछे के पूल के पीछे एक विपरीत प्रॉक्सी में https://api.example.com/users/42 के लिए एक सिंगल HTTPS GET को ट्रेस करें।
हॉप 1: DNS समाधान। ब्राउज़र api.example.com के लिए एक समाधान को पूछता है। समाधान प्रॉक्सी के पब्लिक आईपी (उदाहरण के लिए, 203.0.113.10) को वापस करता है। ब्राउज़र 203.0.113.10:443 पर एक TCP कनेक्शन खोलता है।
हॉप 2: TLS हैंडशेक। प्रॉक्सी api.example.com के लिए अपना प्रमाणपत्र प्रस्तुत करता है। ब्राउज़र प्रमाणपत्र को सत्यापित करता है, दोनों ओरियें एक सेशन की कुंजी पर सहमति बनाते हैं और सुरक्षित चैनल खोला जाता है।
हॉप 3: HTTP अनुरोध अंतर्गत TLS। ब्राउज़र सेंड्स GET /users/42 HTTP/1.1\nHost: api.example.com\n...। प्रॉक्सी एन्क्रिप्टेड अनुरोध बाइट्स को डिक्रिप्ट करता है।
हॉप 4: बैकएंड चयन। प्रॉक्सी api.example.com के लिए अपने अपस्ट्रीम पूल को देखता है और एक बैकएंड का चयन करता है (उदाहरण के लिए 10.0.0.21:8000) अपनी लोड-बैलेंसिंग स्ट्रैटेजी के अनुसार।
हॉप 5: अपस्ट्रीम अनुरोध। प्रॉक्सी 10.0.0.21:8000 पर एक सामान्य HTTP कनेक्शन खोलता (या पुनर्स्थापित) करता है और अनुरोध को अग्रेषित करता है। प्रॉक्सी अनुरोध के साथ हेडर को बदल सकता है: Connection जैसे हॉप-बी-हॉप हेडर को हटा सकता है, X-Forwarded-For: <client-ip> जोड़ सकता है, और Host: सही रूप से सेट कर सकता है।
हॉप 6: बैकएंड प्रोसेसिंग। बैकएंड एप्लिकेशन को अनुरोध पढ़ने के लिए, अपने डेटाबेस का पूछता है, और एक JSON प्रतिक्रिया बनाता है।
हॉप 7: अपस्ट्रीम प्रतिक्रिया। बैकएंड प्रॉक्सी को सामान्य HTTP प्रतिक्रिया भेजता है।
हॉप 8: एज प्रतिक्रिया। प्रॉक्सी प्रतिक्रिया को संपादित या संपीड़ित कर सकता है, इसे वापस TLS सेशन के माध्यम से एन्क्रिप्ट करता है, और ब्राउज़र को भेजता है।
हॉप 9: कनेक्शन लाइफसाइकल। TLS सेशन आमतौर पर अगले अनुरोध के लिए खुला रहता है (HTTP/2 में कई अनुरोध एक ही कनेक्शन पर एक साथ गुजरते हैं। प्रॉक्सी-टू-बैकएंड कनेक्शन अक्सर पूल के लिए पुनर्स्थापित किया जाता है।
प्रत्येक पब्लिक वेब सेवा किसी प्रकार के इस आकार का पालन करती है। हॉप्स को जानने से आप समझ सकते हैं कि किसी विशेषता में लेटेंस क्यों जमा होता है, जहां लॉगिंग को रखना चाहिए, और जहां एक विफलता छुप सकती है।
समय कहाँ गया?
एक यूजर ग्राहक कहते हैं कि API का अनुभव धीरा लगता है। आप मापते हैं और पाते हैं कि अनुरोध लेता है 850 मिलीसेकंड अंत से लेकर आरंभ तक। सर्वर लॉग पीछे में दिखाते हैं कि एप्लिकेशन ने अनुरोध को 40 मिलीसेकंड में सेव किया। प्रॉक्सी लॉग दिखाते हैं कि प्रॉक्सी ने 50 मिलीसेकंड काम किया (TLS हैंडशेक + रूटिंग + रिस्पांस लिखना)।
एक नई सेवा के लिए न्यूनतम एज डिज़ाइन करें
संगति
आपको फॉरवर्ड और रिवर्स प्रॉक्सी के अंतर की जानकारी है, रिवर्स प्रॉक्सी द्वारा एक बार में तीन काम, ओरिजिन को छिपाने के फायदे, और अनुरोध को एज के हर हॉप पर कैसे प्रवाहित होता है, इसकी जानकारी है।
अब इसे लागू करें।
एक छोटी टीम notes.example.com नाम की नई सेवा लॉन्च करने की योजना बना रही है। यूजर्स व्यक्तिगत नोट्स पढ़ और लिखेंगे। टीम को लॉन्च के समय दो पीछे वीएम चलाने की योजना है और अगले साल दस की ओर वृद्धि करने की उम्मीद है। वे यूजर्स के लिए HTTPS चाहते हैं, नई संस्करणों का धीरे से रोलआउट, और पीछे के IP का कोई सार्वजनिक प्रकटीकरण नहीं।
यह पाठ का अगला चरण
यह पाठ का अगला चरण
यह पाठ एज लेयर की आकृति स्थापित कर गया। इस पाठ में चार और पाठ इसे विस्तारित करते हैं:
- राज्यहीन क्षैतिज पैमानीकरण: क्यों एक प्रॉक्सी टियर (& इसके पीछे के बैकेंड) सस्ती मात्रा में गुणा करता है, और भीड़ के साइज़िंग के लिए गणित।
- प्रवेश / निर्गमन विभाजन: क्यों एक सिंगल प्रॉक्सी बॉक्स जो दोनों आने वाली और जाने वाली ट्रैफिक को संभालता है, अंत में अप्रत्याशित तरीके से विफल होता है, और कैसे परतों को विभाजित किया जाए।
- फेलियर मोड और ब्लास्ट रेडियस: कैसे एक सिंगल कॉन्फ़िग चेंज किसी आउटेज में विलुप्त होता है, और कैसे आप ऐसी चीजें लिख सकते हैं जो पुनरावृत्ति को रोकने के लिए दोषरहित कार्रवाई के दस्तावेज़ बनाते हैं।
- दृश्यता और क्षमता: किसी एज़ के साथ मापें कि तुम जानते कि कुछ टूटा हुआ है इससे पहले कि यूजर्स को पता चले।
प्रत्येक पाठ अलग से खड़ा होता है। मिलकर वे आपको वेब-चक्र फ़्लीट के बारे में काम करने वाली मानसिक मॉडल देते हैं।
साथी पाठ: geometry_of_proxies_and_origins इस पाठ को एक निर्देशित ग्राफ के रूप में पुनर्निर्देशित करता है और पूछता है कि ग्राफ थ्योरी आपको एक अनुरोध पथ के बारे में क्या बता सकती है।
बहुत अच्छा। आगे बढ़ें।