बैकएंड इंटरव्यू: आप एक सुरक्षित WHIP WebRTC इंगेस्ट एंडपॉइंट कैसे डिज़ाइन करेंगे?

प्रॉम्प्ट और संदर्भ

आपको एक एनकोडर या मीडिया प्रोड्यूसर के लिए एक WHIP (WebRTC-HTTP Ingestion Protocol) एंडपॉइंट की आवश्यकता है। क्लाइंट HTTP POST के साथ एक application/sdp ऑफर भेजता है; सर्वर ICE और DTLS को नेगोशिएट करता है और एक SDP उत्तर (answer) लौटाता है। API, सेशन लाइफसाइकिल, ऑथेंटिकेशन, रिसोर्स सुरक्षा और ऑब्जर्वेबिलिटी के बारे में बताएं। एकतरफा (one-way) मीडिया इंगेस्ट मान लें; रिकॉर्डिंग और ट्रांसकोडिंग दायरे से बाहर हैं।

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

• क्या HTTP सिग्नलिंग रिसोर्सेज और WebRTC मीडिया रिसोर्सेज को अलग-अलग मॉडल किया गया है।
• क्या एक POST ऑथेंटिकेशन, लिमिट्स, टाइमआउट और क्लीनअप के लिए एक ठोस क्रम की ओर ले जाता है।
• क्या उम्मीदवार WHIP को मीडिया ट्रांसपोर्ट मानने के बजाय HTTPS, ICE, DTLS-SRTP और ब्राउज़र API के बीच की सीमा को समझता है।
• क्या पुनः प्रयास (retries), डुप्लिकेट निर्माण, हाफ-ओपन सेशन्स और दुर्भावनापूर्ण SDP को कवर किया गया है।

स्पष्टीकरण के लिए प्रश्न

• क्या पब्लिशर एक नियंत्रित एनकोडर है या एक खुला उपयोगकर्ता? क्या क्रेडेंशियल्स कम समय के लिए वैध (short-lived) और सिंगल-स्ट्रीम हो सकते हैं?
• क्या एंडपॉइंट रीजनल है या मल्टी-रीजन? क्या सेशन की स्थिति रीजन्स के बीच स्थानांतरित हो सकती है?
• क्या कम लेटेंसी प्राथमिकता है, या रिकॉर्डिंग की पूर्णता और पुनरुत्पादन क्षमता (replayability) की गारंटी दी जानी चाहिए?
• क्या trickle ICE या किसी अन्य WHIP एक्सटेंशन का समर्थन किया जाएगा, और इसके नेगोशिएशन और ऑथराइजेशन का स्वामित्व किसके पास है?

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

मैं एंडपॉइंट को एक ऑथेंटिकेशन गेटवे, एक सेशन कंट्रोल प्लेन और WebRTC मीडिया नोड्स में विभाजित करूँगा। गेटवे सेशन सर्विस को SDP ऑफर पास करने से पहले एक शॉर्ट-लिव्ड क्रेडेंशियल, रिक्वेस्ट लिमिट्स और टेनेंट कोटा को सत्यापित करता है। सर्विस सीमित रिसोर्सेज आवंटित करती है, ICE/DTLS को पूरा करती है, और 201 Created, एक SDP उत्तर, और एक सेशन Location लौटाती है। हर अधूरी नेगोशिएशन को रिसोर्सेज रिलीज करने चाहिए; DELETE इडेम्पोटेंट (idempotent) है, और लिमिट्स प्रति टेनेंट और स्रोत पर लागू होती हैं। मैं POST की सफलता को उपलब्धता मेट्रिक के रूप में उपयोग करने के बजाय HTTP सिग्नलिंग, ICE/DTLS स्थिति और पहले मीडिया पैकेट की लेटेंसी को अलग से मापूंगा।

चरण-दर-चरण समाधान

1. प्रोटोकॉल की सीमा निर्धारित करें। WHIP एक HTTP ऑफर/उत्तर एक्सचेंज निष्पादित करता है; WebRTC बाद में मीडिया ले जाता है। W3C ब्राउज़र नियंत्रणों को उजागर करता है, जबकि सर्वर अभी भी ICE, DTLS और मीडिया रिसेप्शन को संभालता है।
2. सस्ते चेक पहले करें। ICE या मीडिया नोड्स आवंटित करने से पहले, HTTPS, ऑथेंटिकेशन, टेनेंट स्थिति, Content-Type: application/sdp, रिक्वेस्ट साइज, चैनल ऑथराइजेशन और रेट कोटा की जांच करें। अस्वीकृति से महंगा SDP पार्सिंग या कनेक्शन आवंटन ट्रिगर नहीं होना चाहिए।
3. एक सेशन रिसोर्स को मॉडल करें। pending → connected → closing → closed के साथ एक यादृच्छिक, गैर-गणना योग्य (non-enumerable) सेशन URL का उपयोग करें। निर्माण पर 201 Created, Location और एक SDP उत्तर मिलता है; आंतरिक टोपोलॉजी को उजागर किए बिना त्रुटियों का निदान किया जा सकना चाहिए।
4. हाफ-ओपन कार्य को सीमित करें। SDP पार्सिंग, ICE/DTLS स्थापना और पहले मीडिया पैकेट के लिए अलग-अलग समय सीमा निर्धारित करें। RFC 9725 POST फ्लडिंग की चेतावनी देता है: एक क्रेडेंशियल वाला हमलावर आवंटन के लिए बाध्य कर सकता है और ICE/DTLS टाइमआउट की प्रतीक्षा कर सकता है। एज रेट लिमिट्स, सेशन समवर्ती कोटा और टाइमआउट रिक्लेमेशन लागू करें।
5. पुनः प्रयासों और विलोपन को संभालें। नेटवर्क के पुनः प्रयास एक ही ऑफर को एक से अधिक बार भेज सकते हैं। क्रेडेंशियल्स को किसी चैनल या इडेम्पोटेंसी की से बांधें; यदि समानता सिद्ध नहीं की जा सकती है, तो केवल समवर्ती सीमा के तहत ही एक नया सेशन बनाएं। DELETE /session को इडेम्पोटेंट बनाएं और बार-बार कॉल करने पर वही अंतिम स्थिति लौटाएं।
6. ट्रांसपोर्ट और क्रेडेंशियल्स को सुरक्षित रखें। RFC 9725 को WebRTC सुरक्षा मॉडल को बनाए रखने के लिए HTTPS की आवश्यकता होती है। क्रेडेंशियल्स को क्वेरी स्ट्रिंग्स से बाहर रखें और केवल हैश किए गए सेशन पहचानकर्ताओं को लॉग करें। मीडिया नोड्स को व्यापक रूप से कॉपी की गई चैनल की के बजाय सेशन सर्विस से अल्पकालिक ऑथराइजेशन स्वीकार करना चाहिए।
7. एक्सटेंशन को स्पष्ट रूप से नेगोशिएट करें। यदि trickle ICE या सर्वर इवेंट्स समर्थित हैं, तो Link जैसे तंत्रों के माध्यम से क्षमता का विज्ञापन करें; क्लाइंट्स को यह नहीं मान लेना चाहिए कि प्रत्येक WHIP सर्वर इसका समर्थन करता है। एक्सटेंशन विफलता पर, बेस एक्सचेंज पर वापस आएं या स्पष्ट रूप से समाप्त करें।
8. वास्तविक तत्परता सीमा का परीक्षण करें। टेनेंट-स्तरीय POST स्वीकृति, SDP पार्स विफलताओं, ICE सफलता, DTLS सेटअप समय, फर्स्ट-मीडिया लेटेंसी, टाइमआउट रिक्लेमेशन और DELETE लेटेंसी को ट्रैक करें। डुप्लिकेट POST, बड़े आकार के SDP, दुर्गम ICE, नोड पुनरारंभ और क्रेडेंशियल निरसन (revocation) इंजेक्ट करें।

मॉडल उत्तर

मैं पहले इसे कंट्रोल-प्लेन एंडपॉइंट के रूप में तैयार करूँगा: HTTP POST सेशन सर्विस को एक SDP ऑफर सौंपता है, जबकि WebRTC बाद में मीडिया ले जाता है। गेटवे SDP को पार्स करने से पहले HTTPS, एक शॉर्ट-लिव्ड क्रेडेंशियल, चैनल अनुमति, कंटेंट प्रकार, आकार और टेनेंट समवर्तीता की पुष्टि करता है; प्रत्येक अस्वीकृति मीडिया रिसोर्सेज आवंटित होने से पहले होती है। एक सफल अनुरोध एक गैर-गणना योग्य सेशन बनाता है, 201 Created, Location और उत्तर लौटाता है, और एक समयबद्ध पेंडिंग स्थिति में प्रवेश करता है। यदि ICE या DTLS कभी पूरा नहीं होता है, तो सर्विस उम्मीदवारों (candidates) और नोड्स को रिक्लेम करती है ताकि हाफ-ओपन सेशन्स क्षमता को समाप्त न कर सकें। DELETE इडेम्पोटेंट है, और शॉर्ट-लिव्ड क्रेडेंशियल्स के साथ-साथ एक इडेम्पोटेंसी की पुनः प्रयासों को सीमित करती है। मैं सुरक्षा और रिकवरी दोनों को साबित करने के लिए HTTP, ICE/DTLS और फर्स्ट-मीडिया मेट्रिक्स को अलग करूँगा, फिर POST फ्लड्स, प्रतिकूल SDP, रिस्टार्ट और क्रेडेंशियल निरसन का लोड-परीक्षण करूँगा।

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

• WHIP को मीडिया चैनल के रूप में मानना → ICE, DTLS और नोड की स्थिति डिज़ाइन से गायब हो जाती है → कंट्रोल और मीडिया प्लेन को अलग करें।
• प्रत्येक POST पर एक पूर्ण नोड आवंटित करना → शत्रुतापूर्ण अनुरोध हाफ-ओपन कार्य जमा करते हैं → पहले सस्ते चेक और चरणबद्ध कोटा लागू करें।
• केवल एक वैश्विक दर सीमा का उपयोग करना → एक टेनेंट या चैनल सभी को प्रभावित करता है → टेनेंट, क्रेडेंशियल, चैनल और स्रोत द्वारा सीमित करें।
• रॉ SDP लॉग करना → पते और टोपोलॉजी लीक हो सकते हैं → एक डाइजेस्ट, एरर क्लास और कोरिलेशन ID रिकॉर्ड करें।
• DELETE को नॉन-इडेम्पोटेंट बनाना → पुनः प्रयास से क्लीनअप रेस और अवांछित 404 त्रुटियां होती हैं → टर्मिनल स्थितियां और दोहराने योग्य प्रतिक्रियाएं परिभाषित करें।
• प्रत्येक परिणाम के लिए HTTP 200 लौटाना → क्लाइंट निर्माण, अस्वीकृति और पुनः प्रयास में अंतर नहीं कर सकते → सिमेंटिक स्टेटस और सुरक्षित एरर बॉडीज का उपयोग करें।

फॉलो-अप और उत्तर

एक हमलावर के पास वैध क्रेडेंशियल है और वह लगातार पोस्ट कर रहा है। आप सेवा की सुरक्षा कैसे करते हैं?

क्रेडेंशियल को एक टेनेंट, चैनल और समाप्ति से बांधें; एज पर टोकन बकेट और समवर्ती सीमा लागू करें, फिर कंट्रोल प्लेन में पेंडिंग सेशन्स और कुल प्रतीक्षा समय को सीमित करें। उन क्रेडेंशियल्स को रद्द करें जो बार-बार सीमा पार करते हैं और ऑडिट साक्ष्य बनाए रखें।

ICE सफल होता है लेकिन DTLS कभी नहीं होता। क्या आप पुनः प्रयास करते हैं या सफलता की रिपोर्ट करते हैं?

ICE की सफलता मीडिया की तत्परता नहीं है। सेशन को तब तक पेंडिंग रखें जब तक कि DTLS और पहली मीडिया स्थिति पास न हो जाए; टाइमआउट होने पर, इसे बंद करें, पुनः प्रयास करने योग्य विफलता वर्ग लौटाएं, और उम्मीदवारों और नोड्स को रिलीज करें।

क्लाइंट एक ही SDP ऑफर दो बार भेजता है। आप डुप्लिकेट इंगेस्ट से कैसे बचते हैं?

एक शॉर्ट-लिव्ड इडेम्पोटेंसी की की आवश्यकता रखें और इसे क्रेडेंशियल, चैनल और ऑफर डाइजेस्ट से बांधें। सिद्ध डुप्लिकेट के लिए मूल सेशन लौटाएं। यदि समानता सिद्ध नहीं की जा सकती है, तो केवल समवर्ती कोटे के भीतर ही एक नया सेशन बनाएं।

क्या कोई WHIP सेशन आउटेज के दौरान दूसरे क्षेत्र में स्थानांतरित हो सकता है?

एक स्थापित ICE/DTLS सेशन को आमतौर पर पारदर्शी रूप से स्थानांतरित नहीं किया जा सकता है। नए एंडपॉइंट को एक नया सेशन URL जारी करना चाहिए, क्लाइंट को फिर से POST करना चाहिए, और पुराने सेशन को टाइमआउट या स्पष्ट DELETE द्वारा रिलीज किया जाना चाहिए। रेप्लिकेट की गई क्रेडेंशियल स्थिति को एक्सपोज़र के दायरे को विस्तृत नहीं करना चाहिए।