प्रॉम्प्ट
मल्टी-पार्टी WebRTC मीटिंग के लिए ब्राउज़र-साइड एंड-टू-एंड एन्क्रिप्शन डिज़ाइन करें। मीडिया सर्वर RTP को फ़ॉरवर्ड करता है लेकिन उसे ऑडियो या वीडियो नहीं पढ़ना चाहिए। सेंडर और रिसीवर एन्कोडेड फ़्रेम्स को वर्कर्स में प्रोसेस करते हैं। RTCRtpScriptTransform, RTCRtpScriptTransformer, की डिस्ट्रीब्यूशन, कीफ़्रेम्स, परफ़ॉर्मेंस, फ़ेलियर रिकवरी और कम्पैटिबिलिटी के बारे में बताएं। एन्कोडेड-फ़्रेम ट्रांसफ़ॉर्म को ट्रांसपोर्ट TLS से अलग स्पष्ट करें।
इंटरव्यूअर क्या टेस्ट कर रहा है
परीक्षण यह है कि क्या आप ब्राउज़र मीडिया-पाइपलाइन सीमा को समझते हैं: एन्कोडिंग के बाद और डिकोडिंग से पहले ट्रांसफ़ॉर्म करना, readable से writable तक फ़्रेम ऑर्डर बनाए रखना, प्रति-फ़्रेम क्रिप्टो को वर्कर में स्थानांतरित करना, और की रोटेशन, जॉइन-टाइम कीफ़्रेम्स, ड्रॉप हुए फ़्रेम्स और असमर्थित ब्राउज़रों को संभालना। फ़्रेम लाइफ़साइकिल के बिना केवल "RTP एन्क्रिप्ट करें" कहना अधूरा है।
स्पष्टीकरण के लिए प्रश्न
- मीडिया सर्वर से किन पार्टियों को सुरक्षित किया जाना चाहिए, और क्या उसे केवल पैकेट फ़ॉरवर्ड करने की अनुमति है?
- क्या स्क्रीन शेयर और रिकॉर्डिंग के साथ ऑडियो भी शामिल है?
- क्या कुंजियाँ (keys) प्रमाणित एंड-टू-एंड सिग्नलिंग द्वारा वितरित की जाती हैं, और बाहर जाने वाले सदस्यों को कैसे निरस्त (revoke) किया जाता है?
- कौन सा ब्राउज़र मैट्रिक्स समर्थित है? क्या असमर्थित क्लाइंट्स को अस्वीकार किया जाना चाहिए, डाउनग्रेड किया जाना चाहिए, या E2EE को अक्षम किया जाना चाहिए?
30-सेकंड का फ़्रेमवर्क
TLS ट्रांसपोर्ट लिंक्स की सुरक्षा करता है; यह मीडिया सर्वर को प्लेनटेक्स्ट देखने से नहीं रोकता है। E2EE सेंडर एन्कोडर के बाद एन्क्रिप्ट करता है और रिसीवर डिकोडर से पहले डिक्रिप्ट करता है। पांच स्तरों को कवर करें: कैपेबिलिटी डिटेक्शन, वर्कर फ़्रेम पाइपलाइन, कुंजियाँ और नॉनस (nonces), कीफ़्रेम्स और पुनः प्रयास (retry), और डाउनग्रेड/ऑब्जर्वेबिलिटी। MDN इस API को Baseline 2025 के रूप में चिह्नित करता है, लेकिन ब्राउज़र मैट्रिक्स को अभी भी परीक्षण की आवश्यकता है।
चरण-दर-चरण डिज़ाइन
1. क्षमता का पता लगाएं और जल्दी अटैच करें
एक वर्कर, एक डायरेक्शन मार्कर और ट्रांसफ़रेबल MessagePort के साथ RTCRtpScriptTransform का निर्माण करें। पहले फ़्रेम से पहले इसे सेंडर पर RTCRtpSender.transform और रिसीवर पर RTCRtpReceiver.transform से अटैच करें। एक विफल कैपेबिलिटी चेक एक स्पष्ट स्थिति (explicit state) है, न कि प्लेनटेक्स्ट मीडिया के साथ एक मूक सफलता (silent success)।
2. वर्कर में फ़्रेम्स को प्रोसेस करें
वर्कर rtctransform को हैंडल करता है, event.transformer.readable से एन्कोडेड फ़्रेम्स को पढ़ता है, TransformStream चलाता है, और event.transformer.writable में लिखता है। क्रम बनाए रखें और प्रत्येक फ़्रेम को ठीक एक बार कतारबद्ध (enqueue) करें; त्रुटियों पर स्ट्रीम बंद करें और स्थिति की रिपोर्ट करें। मुख्य थ्रेड कॉन्फ़िगरेशन और अल्पकालिक की-हैंडल भेजता है, न कि प्रति-फ़्रेम क्रिप्टो कार्य।
3. सिफ़रटेक्स्ट और की लाइफ़टाइम को परिभाषित करें
प्रति मीटिंग, सेंडर और की-युग (key epoch) एक संदर्भ बनाएं। फ़्रेम काउंटर और स्ट्रीम पहचान से कभी दोबारा उपयोग न किया जाने वाला नॉनस प्राप्त करें। सिफ़रटेक्स्ट में वर्शन, युग (epoch) और एक प्रमाणीकरण टैग शामिल करें, और डिक्रिप्ट करने से पहले सत्यापित करें। प्रमाणित एंड-टू-एंड सिग्नलिंग पर कुंजियाँ वितरित करें, रोटेशन के दौरान एक छोटे ड्यूल-युग ओवरलैप की अनुमति दें, और किसी सदस्य के जाने पर नए-फ़्रेम का एक्सेस निरस्त करें।
4. कीफ़्रेम्स के साथ रिकवर करें
एक नया प्रतिभागी कीफ़्रेम से पहले डेल्टा फ़्रेम प्राप्त कर सकता है और इसे डिकोड नहीं कर सकता है। एक नई कुंजी आने के बाद या डिकोडिंग असंभव होने पर रिसीवर ट्रांसफ़ॉर्म sendKeyFrameRequest() को कॉल कर सकता है; सेंडर ट्रांसफ़ॉर्म generateKeyFrame() को कॉल कर सकता है। दोनों प्रॉमिस लौटाते हैं, इसलिए दिशा और वीडियो स्थिति की जांच करें और अनुरोधों को रेट-लिमिट करें।
5. लेटेंसी और मेमोरी का बजट बनाएं
कॉपी और कचरा संग्रहण (garbage collection) को न्यूनतम करें, जहां सुरक्षित हो वहां फ़्रेम बफ़र्स का पुन: उपयोग करें, और वर्कर समवर्ती (concurrency) को सीमित रखें। ट्रांसफ़ॉर्म लेटेंसी, कतार की गहराई, ड्रॉप दर और कीफ़्रेम-अनुरोध दर को मापें। यदि क्रिप्टो लेटेंसी बजट से अधिक हो जाता है, तो UI थ्रेड को ब्लॉक करने के बजाय वीडियो की गुणवत्ता कम करें या ट्रैक को रोकें।
6. त्रुटियों और पुन: कनेक्शन को संभालें
समाप्त हो चुकी कुंजियाँ, प्रमाणीकरण विफलताएं, वर्कर क्रैश और अस्वीकृत API कॉल एक अवलोकनीय स्टेट मशीन में प्रवेश करते हैं। क्षणिक विफलताओं के लिए वर्कर को पुनरारंभ करें और वर्तमान युग को फिर से शुरू करें; ट्रैक को रोकें और पुनर्प्राप्ति विफल होने पर स्थिति की व्याख्या करें। PeerConnection पुनर्नगोशिएशन के बाद, यह मानने के बजाय कि पुराना वर्कर नए सेंडर का अनुसरण करता है, एक नया ट्रांसफ़ॉर्म अटैच करें।
7. कम्पैटिबिलिटी और सुरक्षा सीमाएं निर्धारित करें
MDN Encoded Transform को Baseline 2025 के रूप में लेबल करता है, फिर भी पुराने ब्राउज़रों और उपकरणों में इसकी कमी हो सकती है। उत्पाद नीति को स्पष्ट रूप से अस्वीकार करना चाहिए, E2EE को अक्षम करना चाहिए, या किसी विश्वसनीय मीडिया सर्वर को ट्रांसकोड करने की अनुमति देनी चाहिए। W3C दस्तावेज़ एक वर्किंग ड्राफ्ट (Working Draft) है, इसलिए इंटरफ़ेस स्थिरता और कार्यान्वयन अंतर रोलआउट योजना में दृश्यमान रहने चाहिए।
एक मजबूत उत्तर का उदाहरण
"मैं सेंडर एन्कोडर के बाद और रिसीवर डिकोडर से पहले RTCRtpScriptTransform को अटैच करूँगा। एक वर्कर readable से एन्कोडेड फ़्रेम्स को पढ़ता है, प्रमाणित एन्क्रिप्शन लागू करता है, और writable में लिखता है। एंड-टू-एंड सिग्नलिंग प्रति मीटिंग, सदस्य और युग में कुंजियों का प्रबंधन करती है; कभी दोबारा इस्तेमाल न किया जाने वाला फ़्रेम काउंटर नॉनस बनाता है, और रिसीवर डिक्रिप्ट करने से पहले टैग को सत्यापित करता है। जब कोई नया सदस्य या कुंजी डेल्टा फ़्रेम को डिकोड नहीं कर पाती है, तो रिसीवर sendKeyFrameRequest को रेट-लिमिट करता है और सेंडर generateKeyFrame कर सकता है। हम ट्रांसफ़ॉर्म लेटेंसी, कतार की गहराई, ड्रॉप्स और प्रमाणीकरण विफलताओं को मापते हैं; विफल पुनर्प्राप्ति ट्रैक को रोक देती है। कैपेबिलिटी डिटेक्शन अस्वीकृति, डाउनग्रेड या अक्षम E2EE चुनता है, और रोलआउट Baseline 2025 के साथ-साथ W3C Working Draft स्थिति को रिकॉर्ड करता है।"
सामान्य विफलता मोड
- TLS को मीडिया एंड-टू-एंड एन्क्रिप्शन मानना।
- मुख्य थ्रेड पर प्रत्येक फ़्रेम को एन्क्रिप्ट करना या एन्कोडेड फ़्रेम के बजाय रॉ फ़्रेम को ट्रांसफ़ॉर्म करना।
- नॉनस का पुन: उपयोग करना, प्रमाणीकरण जांच छोड़ना, या युगों और निरस्तीकरण को छोड़ देना।
- कीफ़्रेम्स, वर्कर क्रैश, पुन: कनेक्शन और ब्राउज़र अंतरों को अनदेखा करना।
- Encoded Transform इंटरफ़ेस की जांच किए बिना WebRTC समर्थन का दावा करना।
फ़ॉलो-अप दिशाएं
एन्कोडिंग के बाद ट्रांसफ़ॉर्म क्यों करें?
एन्कोडेड फ़्रेम छोटे होते हैं और RTP पाइपलाइन में बने रहते हैं; रॉ फ़्रेम को ट्रांसफ़ॉर्म करने से एन्कोडिंग से पहले कॉपी और गणना जुड़ जाती है।
क्या sendKeyFrameRequest() हमेशा एक अनुरोध भेजेगा?
नहीं। उपयोगकर्ता एजेंट प्रॉमिस को पूरा करते हुए भी यह तय कर सकता है कि यह अनावश्यक है, इसलिए उत्पाद को प्रतीक्षा और टाइमआउट हैंडलिंग की आवश्यकता होती है।
कुंजियाँ वर्कर तक कैसे पहुँचनी चाहिए?
विकल्पों या ट्रांसफ़रेबल MessageChannel के माध्यम से अल्पकालिक हैंडल पास करें; असंबंधित स्क्रिप्ट्स के सामने दीर्घकालिक कुंजियों को उजागर करने से बचें।
क्या असमर्थित ब्राउज़र चुपचाप डाउनग्रेड हो सकते हैं?
नहीं। उपयोगकर्ता और मीटिंग नीति को स्पष्ट रूप से बताना चाहिए कि क्या वर्तमान मीडिया E2EE है।
आप कैसे साबित करते हैं कि सर्वर कोई प्लेनटेक्स्ट नहीं देखता है?
परीक्षण परिवेश में फ़ॉरवर्डिंग नोड पर डेटा कैप्चर करें और सत्यापित करें कि केवल सिफ़रटेक्स्ट फ़्रेम ही दिखाई दे रहे हैं; सिग्नलिंग, वर्कर्स, की सेवाओं और रिकॉर्डिंग अनुमतियों का ऑडिट करें।
संदर्भ
MDN "Using WebRTC Encoded Transforms", MDN "RTCRtpScriptTransformer", और W3C "WebRTC Encoded Transform" Working Draft।