सिस्टम डिज़ाइन इंटरव्यू: आप MASQUE CONNECT-UDP प्रॉक्सी कैसे डिज़ाइन करेंगे?

प्रॉम्प्ट और दायरा

एक मोबाइल क्लाइंट HTTPS तक विश्वसनीयता से पहुँच सकता है, लेकिन वॉयस, गेम्स और रियल-टाइम प्रोब्स UDP पर निर्भर करते हैं। एक ऐसा प्रॉक्सी डिज़ाइन करें जो क्लाइंट को लक्षित UDP होस्ट के लिए एक HTTP टनल स्थापित करने दे, जिसमें लाइफ़साइकिल, फ़ॉरवर्डिंग, ऑथराइजेशन, रेट लिमिट्स, DNS, फ़ेलओवर और फ़ॉलबैक शामिल हों।

RFC 9298 CONNECT-UDP और एक प्रॉक्सी टेम्पलेट को परिभाषित करता है। RFC 9297 क्रमशः अनरिलायबल डेटा और रिलायबल कंट्रोल जानकारी के लिए HTTP Datagrams और Capsule Protocol को परिभाषित करता है। एक सशक्त उत्तर प्रोटोकॉल सेमांटिक्स, प्रॉक्सी रिसोर्सेस और सुरक्षा नीतियों को अलग करता है; केवल TLS दुरुपयोग को नहीं रोकता है।

इंटरव्यूअर क्या मूल्यांकन करता है

CONNECT-UDP के लिए टनल स्थापना, फ़ॉरवर्डिंग और क्लोज़र में अंतर करना।
फ़ॉलबैक सहित, HTTP/3 Datagrams और Capsules के बीच की सीमा को समझाना।
टारगेट अनुमति सूचियों (allowlists), पोर्ट नीति, यूज़र ऑथराइजेशन और टेनेंट कोटा को डिज़ाइन करना।
DNS, टाइमआउट्स, पुनः प्रयास (retries), हाफ-ओपन सेशन्स और फ़ेलओवर को संभालना।
बैंडविड्थ, कॉनक्रेन्सी, लॉस, लेटेंसी, दुरुपयोग और लागत मेट्रिक्स को परिभाषित करना।
यह स्पष्ट करना कि प्रॉक्सी UDP में विश्वसनीयता, क्रमबद्धता (ordering), या एंड-टू-एंड एन्क्रिप्शन सेमांटिक्स नहीं जोड़ सकता है।

स्पष्टीकरण हेतु प्रश्न

क्या क्लाइंट और प्रॉक्सी दोनों HTTP/3 Datagrams का समर्थन करते हैं, या HTTP/2 को भी काम करना चाहिए?
क्या टारगेट कोई एंटरप्राइज नेटवर्क है, रियल-टाइम मीडिया है, या खुला इंटरनेट है? जोखिम मॉडल अलग होता है।
क्या क्लाइंट होस्टनेम प्रदान करता है, और क्या प्रॉक्सी DNS रिज़ॉल्व करता है? गोपनीयता और लाइफ़टाइम आवश्यकताएं क्या हैं?
एक टेनेंट कितने टनल, बाइट्स और कॉनकरेंट UDP फ़्लो का उपयोग कर सकता है? क्या रीजनल रूटिंग आवश्यक है?
अधिकतम निष्क्रिय अवधि (idle period), पैकेट आकार और सेशन अवधि क्या हैं?

30-सेकंड का उत्तर

मैं प्रॉक्सी को प्रमाणित टेनेंट्स और एक स्पष्ट टारगेट सेट तक सीमित रखूँगा, फिर CONNECT-UDP के साथ एक सेशन स्थापित करूँगा। Capsules रिलायबल कंट्रोल ले जाते हैं; HTTP/3 Datagrams समर्थित होने पर UDP डेटा ले जाते हैं। अन्यथा, प्रॉक्सी रिलायबल इनकैप्सुलेशन पर फ़ॉलबैक करता है या समकक्ष लेटेंसी का दावा किए बिना रिक्वेस्ट को अस्वीकार कर देता है। डेटा प्लेन टेनेंट टोकन बकेट, कॉनक्रेन्सी सीमाएं और आइडल टाइमआउट लागू करता है, जबकि एक नियंत्रित रिज़ॉल्वर DNS परिणामों को सेशन से बांधता है। फ़ेलओवर केवल रीप्ले करने योग्य स्टेट को फिर से बनाता है। मैं p99 लेटेंसी, लॉस, सेटअप सफलता, रिसोर्स उपयोग, अस्वीकृति दर और दुरुपयोग अलर्ट को मान्य करूँगा।

चरण-दर-चरण डिज़ाइन

1. सेशन और स्टेट मशीन

क्लाइंट टारगेट होस्ट और पोर्ट के लिए CONNECT-UDP भेजता है। प्रॉक्सी पहचान, नीति और कोटा को प्रमाणित करता है, टारगेट को रिज़ॉल्व करता है और एक सेशन बनाता है। स्टेट्स में ऑथराइजेशन लंबित (pending authorization), कनेक्टेड (connected), ड्रेनिंग (draining), और बंद (closed) शामिल होने चाहिए, प्रत्येक के साथ एक टाइमआउट और रीज़न कोड होना चाहिए ताकि हाफ-ओपन सेशन अनिश्चित काल तक रिसोर्स रोककर न रख सकें।

http

CONNECT / .well-known/masque/udp/example.test/443 HTTP/3
Host: proxy.example

कार्यान्वयन को RFC 9298 रिक्वेस्ट-टेम्पलेट और एन्कोडिंग नियमों का पालन करना चाहिए; स्निपेट केवल उद्देश्य को व्यक्त करता है।

2. कंट्रोल और डेटा प्लेन को अलग करना

Capsule Protocol रिलायबल सेशन कंट्रोल, एरर्स और क्लोज़ नोटिफिकेशन्स के लिए उपयुक्त है। HTTP/3 Datagrams ऐसे UDP डेटा के लिए उपयुक्त हैं जिन्हें पुनः ट्रांसमिशन की आवश्यकता नहीं होती है। प्रत्येक Datagram को संबंधित UDP सॉकेट पर मैप करें और पैकेट आकार, कतार की गहराई (queue depth), और बर्स्ट को सीमित करें। यदि पाथ में Datagram समर्थन की कमी है, तो लेटेंसी और CPU लागत को छिपाने के बजाय स्पष्ट रूप से रिलायबल इनकैप्सुलेशन चुनें या असमर्थित (unsupported) लौटाएं।

3. ऑथराइजेशन और टारगेट नीति

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

4. सीमाएं, कोटा और लागत

प्रति टेनेंट टनल, पैकेट्स प्रति सेकंड, बाइट दर, सेशन अवधि और निष्क्रिय समय को सीमित करें। इनग्रेस और इग्रेस दोनों पर टोकन बकेट का उपयोग करें, जिसमें एक वैश्विक नोड सुरक्षा सीमा हो। प्रॉक्सी CPU, कर्नेल सॉकेट्स, कतारों, इग्रेस बैंडविड्थ और प्रति-सेशन लागत को ट्रैक करें; केवल HTTP रिक्वेस्ट संख्या को सीमित करने से लंबे समय तक चलने वाला UDP फ़्लो नियंत्रित नहीं होता है।

5. विफलता और फ़ॉलबैक

सेटअप विफलता, अगम्य (unreachable) टारगेट, DNS टाइमआउट और ओवरलोड के लिए अलग-अलग कारणों को रिकॉर्ड करें। नए सेशन किसी स्वस्थ नोड पर पुनः प्रयास कर सकते हैं। पहले से भेजा गया UDP डेटा आमतौर पर रीप्ले करने के लिए सुरक्षित नहीं होता है, इसलिए फ़ेलओवर को केवल कंट्रोल स्टेट को रीस्टोर करना चाहिए या ऊपरी प्रोटोकॉल को एक नया सेशन स्थापित करने देना चाहिए। यदि Datagrams असमर्थित हैं, तो रिलायबल इनकैप्सुलेशन या एक स्पष्ट विफलता चुनें और पाथ्स को अलग से मापें।

6. ऑब्ज़र्वेबिलिटी और सुरक्षा संचालन

प्रत्येक सेशन के लिए टेनेंट, प्रॉक्सी नोड, नीति वर्शन, सेटअप और क्लोज़ कारण, बाइट्स, पैकेट्स, अनुमानित लॉस, p50/p95/p99 लेटेंसी और थ्रॉटलिंग इवेंट्स रिकॉर्ड करें। पूर्ण क्रेडेंशियल या संवेदनशील पेलोड को कभी लॉग न करें। पोर्ट स्कैन, टारगेट एकाग्रता, प्रवर्धन (amplification) बर्स्ट और क्रॉस-टेनेंट विवाद का पता लगाएं, जिसमें टेनेंट, टारगेट या क्षेत्र द्वारा त्वरित निरसन (revocation) शामिल हो।

7. रोलआउट और स्वीकृति

डायरेक्ट, Datagram और फ़ॉलबैक पाथ्स की तुलना करते हुए निश्चित क्षेत्रों और अनुमति-सूचीबद्ध टारगेट्स पर कैनरी परीक्षण करें। लॉस, रीऑर्डरिंग, प्रॉक्सी रीस्टार्ट, DNS परिवर्तन, हाफ-ओपन सेशन और अत्यधिक ट्रैफ़िक के विरुद्ध स्ट्रेस टेस्ट करें। रिलीज़ गेट्स में सेटअप सफलता, रीयल-टाइम p99, लॉस, प्रति-सेशन रिसोर्स, गलत अस्वीकृति (false rejection) और दुरुपयोग-अलर्ट लेटेंसी शामिल होनी चाहिए। सुरक्षा या रिसोर्स सीमा पार होने पर नीति को कड़ा करें या पाथ को अक्षम करें।

नमूना सशक्त उत्तर

मैं एक प्रमाणित प्रॉक्सी का निर्माण करूँगा जो एक स्पष्ट टारगेट सेट तक सीमित हो। CONNECT-UDP के बाद, यह क्रेडेंशियल्स, टारगेट और कोटा को मान्य करता है, एक नियंत्रित रिज़ॉल्वर के माध्यम से DNS रिज़ॉल्व करता है और एक सेशन बनाता है। Capsules कंट्रोल ले जाते हैं; उपलब्ध होने पर HTTP/3 Datagrams गैर-रीप्ले करने योग्य UDP डेटा ले जाते हैं। प्रत्येक सेशन में पैकेट-आकार, कतार, दर, आइडल और लाइफ़टाइम सीमाएं होती हैं।

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

सामान्य गलतियाँ

टनल सेमांटिक्स के बिना "UDP को HTTPS के अंदर रखना" कहना → CONNECT-UDP, Capsules और Datagrams को अलग करें।
प्रॉक्सी को रिलायबल ट्रांसपोर्ट मानना → विश्वसनीयता और क्रमबद्धता ऊपरी परत की चिंता बनी रहती है।
मनमाने गंतव्यों की अनुमति देना → होस्ट और पोर्ट अनुमति सूचियों का उपयोग करें और विशेष श्रेणियों को ब्लॉक करें।
केवल HTTP रिक्वेस्ट को सीमित करना → टनल, पैकेट, बाइट्स, लाइफ़टाइम और आइडल टाइम को भी सीमित करें।
विफलता के बाद सभी UDP डेटा को रीप्ले करना → केवल रीप्ले करने योग्य कंट्रोल स्टेट को पुनर्स्थापित करें और ऊपरी परत को पुनः कनेक्ट करने दें।
केवल औसत लेटेंसी मापना → p99, लॉस, अस्वीकृति, रिसोर्स और दुरुपयोग मेट्रिक्स शामिल करें।

फॉलो-अप प्रश्न और प्रतिक्रियाएं

क्या होगा यदि HTTP/2 HTTP/3 Datagrams को ले जाने में असमर्थ हो?

वर्कलोड के अनुसार रिलायबल इनकैप्सुलेशन, पोलिंग-स्टाइल ट्रांसपोर्ट या स्पष्ट अस्वीकृति चुनें। लेटेंसी, CPU और बैंडविड्थ को अलग से मापें; अनरिलायबल Datagrams के साथ समानता का दावा न करें।

आप SSRF को कैसे रोकते हैं?

DNS के बाद और कनेक्ट करने से पहले रिज़ॉल्व किए गए IPs की जांच करें, लूपबैक, लिंक-लोकल, प्राइवेट, मेटाडेटा और नीति-बाहरी श्रेणियों को ब्लॉक करें, और DNS रिबाइंडिंग को संभालें। नीति वर्शन को सेशन से बांधें और इसे प्रतिसंहरणीय (revocable) बनाएं।

खोए हुए UDP पैकेट्स को कौन पुनः प्रयास करता है?

प्रॉक्सी ट्रांसपोर्ट अवलोकनों की रिपोर्ट करता है लेकिन एप्लिकेशन पैकेट्स को रीप्ले नहीं करता है। आइडमपोटेंसी और सीक्वेंस सेमांटिक्स वाला एक ऊपरी प्रोटोकॉल रीट्राय का फैसला करता है; रियल-टाइम मीडिया इसके बजाय डेटा को छोड़ (drop) या मरम्मत (repair) कर सकता है।

प्रॉक्सी रीस्टार्ट सेशन्स को कैसे पुनर्प्राप्त करता है?

पुनः प्रमाणीकरण और एक नए सेशन को प्राथमिकता दें। यदि कंट्रोल स्टेट को बनाए रखना आवश्यक है, तो गैर-रीप्ले योग्य डेटा के बिना केवल शॉर्ट-लिव्ड, सत्यापन योग्य स्थिति को पुनर्स्थापित करें, और पुराने सॉकेट्स को तुरंत ड्रेन करें।

आप कैसे दिखाते हैं कि सीमाएं गलत अस्वीकृति (false rejection) का कारण नहीं बनती हैं?

टेनेंट, क्षेत्र, टारगेट और क्लाइंट वर्शन द्वारा अस्वीकृति और सफलता की तुलना करें। एक एरर-रिजेक्शन बजट सेट करें और कोटा व्यवहार को सत्यापित करने के लिए बर्स्ट, लंबे सेशन और नोड विफलताओं को रीप्ले करें।