प्रॉम्प्ट और दायरा
एक SaaS प्लेटफ़ॉर्म को थर्ड-पार्टी रूल प्लगइन्स लोड करने हैं। प्लगइन्स अलग-अलग भाषाओं में लिखे हो सकते हैं, और होस्ट उन्हें एक ही प्रोसेस या हल्के रनटाइम में पुन: उपयोग करना चाहता है, जबकि केवल स्पष्ट क्लॉक, लॉगिंग और ऑब्जेक्ट-स्टोरेज इंटरफेस प्रदान करता है। कोर WebAssembly मॉड्यूल, Component Model, WIT और WASI के बीच संबंधों की व्याख्या करें, फिर वर्ज़निंग, परफॉरमेंस, सिक्योरिटी और ऑपरेशंस कंट्रोल्स का प्रस्ताव दें।
यह क्रॉस-लैंग्वेज रनटाइम और सिक्योरिटी सीमाओं का परीक्षण करता है, न कि "नियर-नेगेटिव स्पीड" जैसे जुमले का। WebAssembly 3.0 स्पेसिफिकेशन कोर Wasm को एक वैलिडेटेड, सैंडबॉक्स किए गए वर्चुअल इंस्ट्रक्शन सेट के रूप में परिभाषित करता है। Component Model टाइप्ड इंटरफेस, कंपोज़िशन और कॉलिंग कन्वेंशन जोड़ता है; WIT इंटरफेस का वर्णन करता है; और WASI, WIT रूप में सिस्टम कैपेबिलिटीज़ प्रदान करता है। एक अच्छा उत्तर "मॉड्यूल निष्पादित होता है" को "प्लगइन होस्ट कैपेबिलिटीज़ का सुरक्षित रूप से उपयोग कर सकता है" से अलग करता है।
इंटरव्यूअर क्या जांच रहा है
एक मजबूत उत्तर सबसे छोटे कैपेबिलिटी सेट के साथ शुरू होता है, प्लगइन इंटरफेस को परिभाषित करता है, और फिर यह तय करता है कि क्या प्रत्येक प्लगइन को एक होस्ट प्रोसेस देने के बजाय एक Component उचित है। यह कोर मॉड्यूल में साझा लीनियर मेमोरी को टाइप्ड Component सीमाओं से अलग करता है, बताता है कि एक world इम्पोर्ट्स और एक्सपोर्ट्स को कैसे घोषित करता है, और दिखाता है कि होस्ट अघोषित इम्पोर्ट्स को कैसे अस्वीकार करता है।
यह वास्तविकता को भी कवर करता है: यदि होस्ट डेटा-एक्सपोर्टिंग API को उजागर करता है तो सैंडबॉक्स बिज़नेस सिक्योरिटी नहीं है; सीमा पार करने से बड़े मान कॉपी हो सकते हैं; और Component Model व WASI वर्ज़न्स को एक लॉक्ड रनटाइम मैट्रिक्स की आवश्यकता होती है। इंटरव्यू की तैयारी सामग्री आमतौर पर पोर्टेबिलिटी, आइसोलेशन, इंटरफेस डिज़ाइन और रिकवरी को किसी एक टूल के बारे में सामान्य ज्ञान के बजाय इंजीनियरिंग सिग्नल मानती है।
पहले स्पष्ट करने योग्य प्रश्न
प्लगइन ट्रस्ट और आइसोलेशन का लक्ष्य
पूछें कि क्या प्लगइन्स फर्स्ट-पार्टी हैं, पार्टनर के स्वामित्व वाले हैं, या पूरी तरह से अविश्वसनीय (untrusted) हैं। यदि कोई हमलावर होस्ट प्रोसेस से बाहर निकल सकता है, तो एक Wasm सैंडबॉक्स अपर्याप्त है; प्रोसेस आइसोलेशन या एक समर्पित सर्विस का उपयोग करें। पुष्टि करें कि क्या नेटवर्क, फ़ाइलें, रैंडमनेस और क्लॉक आवश्यक हैं क्योंकि प्रत्येक कैपेबिलिटी की सीमा का विस्तार करता है।
कॉल मॉडल और डेटा का आकार
स्पष्ट करें कि क्या कॉल छोटे सिंक्रोनस नियम हैं, लंबे जॉब्स हैं, या स्ट्रीम्स हैं। छोटे संरचित मान इंटरफ़ेस सीमा के अनुकूल होते हैं; बार-बार कॉपी करने से बचने के लिए बड़ी फ़ाइलों को नियंत्रित हैंडल या होस्ट-प्रबंधित ऑब्जेक्ट्स का उपयोग करना चाहिए। लेटेंसी और कॉनक्रेन्सी लक्ष्य पूलिंग, वार्म-अप और बैकप्रेशर निर्धारित करते हैं।
वर्ज़न और विफलता का अनुबंध
पूछें कि पहले कौन अपग्रेड करता है, क्या पुराने इंटरफेस को सह-अस्तित्व में होना चाहिए, क्या असफल कॉल पुनः प्रयास (retry) कर सकती है, और क्या साइड इफेक्ट्स इडेम्पोटेंट (idempotent) हैं। यदि कोई प्लगइन किसी बाहरी सिस्टम में लिखता है, तो टाइमआउट, इडेम्पोटेंसी कीज़ और ऑडिट रिकॉर्ड के बाद अज्ञात परिणामों को परिभाषित करें।
30-सेकंड उत्तर रूपरेखा
"मैं एक प्लगइन को एक Component के रूप में मानूंगा जो केवल घोषित इंटरफेस के माध्यम से इंटरैक्ट करता है। मैं एक न्यूनतम WIT world को परिभाषित करूंगा, जैसे लॉगिंग और प्रतिबंधित ऑब्जेक्ट रीड्स को इम्पोर्ट करते हुए evaluate को एक्सपोर्ट करना; होस्ट इसे एक अनुमति-सूची (allow-list) से इन्स्टैन्शिएट करता है और इसके अलावा कुछ भी प्रदान नहीं करता है। WASI सिस्टम इंटरफेस का एक मानकीकृत परिवार है, न कि फ़ाइलों या नेटवर्क के लिए स्वचालित अनुमति। कोर Wasm वैलिडेटेड निष्पादन प्रदान करता है, जबकि Component Model टाइप्ड क्रॉस-लैंग्वेज कंपोज़िशन प्रदान करता है। मैं इंटरफेस को वर्ज़न करूंगा, संसाधनों को सीमित करूंगा, और प्रिविलेज, कम्पैटिबिलिटी, परफॉरमेंस और रिकवरी का परीक्षण करूंगा। यदि प्लगइन पूरी तरह से अविश्वसनीय है या व्यापक साझा स्थिति की आवश्यकता है, तो मैं एक अलग सर्विस चुनूंगा।"
चरण-दर-चरण समाधान
चरण 1: कैपेबिलिटीज़ और ट्रस्ट के साथ शुरुआत करें
प्रत्येक प्लगइन की ज़रूरतों को एक कैपेबिलिटी सूची के रूप में लिखें: लॉगिंग, वर्तमान समय, कॉन्फ़िगरेशन रीड्स, ऑब्जेक्ट रीड्स, या कतार सबमिशन। एक कैपेबिलिटी एक वास्तविक इम्पोर्ट है, कोई टिप्पणी नहीं। शुद्ध-गणना वाले world में फ़ाइल या नेटवर्क इंटरफेस नहीं होने चाहिए। अविश्वसनीय प्लगइन्स के लिए, Wasm को एक लेयर के रूप में मानें और प्रोसेस सीमाएं, हस्ताक्षरित रिलीज़ और डिपेंडेंसी समीक्षा जोड़ें।
चरण 2: एक कोर मॉड्यूल और एक Component के बीच अंतर करें
एक कोर मॉड्यूल निम्न-स्तरीय फ़ंक्शंस, टेबल्स, लीनियर मेमोरी और इम्पोर्ट्स और एक्सपोर्ट्स को परिभाषित करता है, जो एक रनटाइम या भाषा बाइंडिंग के अंदर अच्छा काम करता है। मॉड्यूल के बीच स्ट्रिंग्स और सूचियों को पास करने के लिए अक्सर एक शेयर्ड-मेमोरी लेआउट और हाथ से लिखे गए ABI की आवश्यकता होती है, जिससे भाषा युग्मन (language coupling) बनता है। एक Component एक या अधिक कोर मॉड्यूल को एक सेल्फ-डिस्क्राइबिंग कंटेनर में पैकेज करता है, स्ट्रिंग्स, रिकॉर्ड्स, वेरिएंट्स और परिणामों के लिए इंटरफ़ेस प्रकारों का उपयोग करता है, और सीमा अनुकूलन के लिए एक Canonical ABI लागू करता है।
world rules {
import logger: interface { log: func(level: string, message: string) }
import objects: interface { read: func(key: string) -> result<list<u8>, not-found> }
export evaluate: func(input: list<u8>) -> result<list<u8>, rule-error>
}यह WIT जैसी घोषणा एक सीमा को व्यक्त करती है, न कि कार्यान्वयन भाषा को। होस्ट यह पुष्टि करता है कि कंपोनेंट घोषणा अनुमत world से मेल खाती है और अतिरिक्त इम्पोर्ट्स को अस्वीकार करता है; प्लगइन होस्ट पॉइंटर्स या फ़ाइल डिस्क्रिप्टर के बजाय इंटरफेस देखता है।
चरण 3: WIT worlds और WASI की व्याख्या करें
WIT इंटरफेस और इम्पोर्ट/एक्सपोर्ट दिशा को परिभाषित करता है; एक world एक बंद अनुबंध है जिसमें वे इंटरफेस शामिल हैं। एक होस्ट शेयर्ड मेमोरी के बिना एक कंपोनेंट के एक्सपोर्ट को दूसरे कंपोनेंट के इम्पोर्ट से जोड़ सकता है। WASI फ़ाइलों, नेटवर्किंग, क्लॉक और अन्य सिस्टम कैपेबिलिटीज़ के लिए समान इंटरफ़ेस-विवरण शैली का उपयोग करता है, लेकिन रनटाइम अभी भी डायरेक्टरी मैपिंग, नेटवर्क नीति और संसाधन सीमाओं को कॉन्फ़िगर करता है। WASI को लागू करने से प्रत्येक कैपेबिलिटी अपने आप नहीं खुल जाती है।
चरण 4: लाइफसाइकिल और संसाधन नियंत्रण डिज़ाइन करें
प्रति-इन्स्टेंस मेमोरी, कॉल-टाइम, फ्यूल या निष्पादन, कॉनक्रेन्सी और आउटपुट-बाइट सीमाएं सेट करें। छोटे कॉल एक पूल का उपयोग कर सकते हैं और अनुरोधों के बीच स्थिति साफ़ कर सकते हैं; स्टेटफुल प्लगइन्स को स्पष्ट होस्ट ऑब्जेक्ट्स में स्थिति रखनी चाहिए। रद्दीकरण पर, नए कॉल्स रोकें, इन्स्टेंस की प्रतीक्षा करें या उसे समाप्त करें, और रिकॉर्ड करें कि क्या कोई बाहरी साइड इफेक्ट हो सकता है। लौटाया गया एरर यह साबित नहीं करता है कि कोई बाहरी राइट रोल बैक हो गया है।
चरण 5: वर्ज़न्स और भाषा इंटरऑपरेबिलिटी को संभालें
मौजूदा सिमेंटिक्स को बदलने की तुलना में वैकल्पिक इंटरफ़ेस फ़ील्ड जोड़ना आमतौर पर अधिक सुरक्षित होता है; हटाने या अर्थ परिवर्तन के लिए एक नए world या माइग्रेशन विंडो की आवश्यकता होती है। रिलीज़ में WIT पैकेज, रनटाइम, एडेप्टर और कैपेबिलिटी मेनिफेस्ट को लॉक करें, और कंपोनेंट हैश और डिपेंडेंसी वर्ज़न्स को रिकॉर्ड करें। एक अपग्रेड को शैडो-रन करें, परिणामों, लेटेंसी और संसाधन उपयोग की तुलना करें, फिर टेनेंट या प्लगइन वर्ज़न द्वारा कैनरी डिप्लॉय करें। नए सिमेंटिक्स को जबरन शामिल करने के बजाय पुराने प्लगइन्स को पुराने world पर ही रखें।
चरण 6: परीक्षणों के साथ सीमाओं और मूल्य को साबित करें
सुरक्षा परीक्षण अघोषित इम्पोर्ट्स, पाथ ट्रैवर्सल, नेटवर्क एस्केप, संसाधन थकावट, दुर्भावनापूर्ण रूप से बड़े परिणाम और अमान्य कंपोनेंट हस्ताक्षरों को कवर करते हैं। कम्पैटिबिलिटी परीक्षण कई भाषाओं में समान WIT मान उत्पन्न करते हैं और वैकल्पिक फ़ील्ड, एरर वेरिएंट और स्वतंत्र होस्ट/कंपोनेंट अपग्रेड को कवर करते हैं। परफॉरमेंस परीक्षण सीमा अनुकूलन, कोल्ड स्टार्ट, पूल हिट और बिज़नेस गणना को अलग करते हैं। यदि डेटा कॉपी करना हावी है, तो एक नेटिव लाइब्रेरी या अलग सर्विस बेहतर डिज़ाइन हो सकती है।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं सबसे पहले प्लगइन ट्रस्ट और कैपेबिलिटीज़ की पुष्टि करूंगा। एक नियंत्रित पार्टनर प्लगइन के लिए, मैं एक न्यूनतम WIT world को परिभाषित करूंगा: प्लगइन नियम मूल्यांकन को एक्सपोर्ट करता है और संरचित लॉगिंग और प्रतिबंधित ऑब्जेक्ट रीड्स को इम्पोर्ट करता है। होस्ट केवल उन इम्पोर्ट्स को जोड़ता है और मेमोरी, समय, कॉनक्रेन्सी और आउटपुट सीमाएं लागू करता है। एक शुद्ध-गणना वाले world में कोई फ़ाइल या नेटवर्क कैपेबिलिटी नहीं होती है।
कोर Wasm वैलिडेटेड निम्न-स्तरीय निष्पादन प्रदान करता है, लेकिन क्रॉस-लैंग्वेज कंपाउंड मान शेयर्ड-मेमोरी ABI पर निर्भर हो सकते हैं। Component Model मॉड्यूल को टाइप्ड इंटरफेस और एक Canonical ABI के साथ लपेटता है; WIT दिशा का वर्णन करता है, जबकि WASI मानक सिस्टम कैपेबिलिटीज़ का एक वैकल्पिक परिवार है। मैं अभी भी डायरेक्टरी, नेटवर्क और क्लॉक अनुमतियों को कॉन्फ़िगर करता हूं। रिलीज़ WIT पैकेज, एडेप्टर, रनटाइम और कंपोनेंट हैश को लॉक करते हैं। पुराने worlds उपलब्ध रहते हैं जबकि एक नए वर्ज़न को शैडो और कैनरी किया जाता है।
अंत में मैं प्रिविलेज, संसाधन थकावट, पुनः प्रयास व्यवहार और बाहरी साइड इफेक्ट्स का परीक्षण करूंगा, कोल्ड स्टार्ट, सीमा अनुकूलन, पूल हिट और बिज़नेस समय को मापूंगा। यदि कोई प्लगइन पूरी तरह से अविश्वसनीय है, जटिल नेटवर्किंग की आवश्यकता है, या एक बड़ी म्यूटेबल स्थिति साझा करता है, तो मैं Wasm सैंडबॉक्स को एक पूर्ण सुरक्षा समाधान के रूप में मानने के बजाय मजबूत प्रोसेस आइसोलेशन के साथ एक अलग सर्विस का उपयोग करूंगा।
सामान्य गलतियां
- WebAssembly को डायरेक्ट सिस्कॉल वाली प्रोसेस मानना → कोर मॉड्यूल में कोई पर्यावरण API नहीं होता है; कैपेबिलिटीज़ होस्ट इम्पोर्ट्स के माध्यम से आती हैं → प्रत्येक इम्पोर्ट को सूचीबद्ध करें और न्यूनतम विशेषाधिकार (least privilege) कॉन्फ़िगर करें।
- एक Component को केवल एक तेज़ कोर मॉड्यूल मानना → इसका मुख्य मूल्य टाइप्ड इंटरफेस, कंपोज़िशन और क्रॉस-लैंग्वेज ABI है, जो अनुकूलन लागत जोड़ सकता है → कोल्ड स्टार्ट, अनुकूलन और बिज़नेस वर्क को अलग से बेंचमार्क करें।
- प्रत्येक प्लगइन को पूर्ण WASI प्रदान करना → फ़ाइल, नेटवर्क और क्लॉक कैपेबिलिटीज़ डेटा-लीक और संसाधन-दुरुपयोग के रास्तों को बड़ा करती हैं → प्रति world और टेनेंट कैपेबिलिटीज़ प्रदान करें, डिफ़ॉल्ट रूप से अस्वीकार (deny) रखें।
- केवल रिटर्न वैल्यू को मान्य करना → टाइमआउट से पहले एक बाहरी राइट हो सकता है, इसलिए पुनः प्रयास करने से साइड इफेक्ट डुप्लिकेट हो सकता है → इडेम्पोटेंसी, ऑडिट और अज्ञात-परिणाम स्थितियों को परिभाषित करें।
- पुराने प्लगइन में एक नया होस्ट इंटरफ़ेस जबरन डालना → समान प्रकार समान सिमेंटिक्स की गारंटी नहीं देते हैं → वर्ज़न किए गए worlds और स्पष्ट माइग्रेशन का समर्थन करें।
फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: कंटेनरों में प्लगइन्स क्यों न चलाएं?
कंटेनर उन प्लगइन्स के अनुकूल होते हैं जिन्हें एक स्वतंत्र फ़ाइल सिस्टम, नेटवर्क स्टैक या प्रोसेस विफलता सीमा की आवश्यकता होती है, लेकिन स्टार्टअप और संसाधन लागत आमतौर पर अधिक होती है। Components छोटे कॉल्स, स्पष्ट कैपेबिलिटीज़ और सघन (dense) इन्स्टेंस के अनुकूल होते हैं। यदि किसी प्लगइन को कर्नेल विशेषाधिकार, विशेष ड्राइवर या मजबूत आइसोलेशन की आवश्यकता है, तो कंटेनर या सर्विस का उपयोग करें। थ्रेट मॉडल, स्टार्टअप लक्ष्य, संसाधन बजट और संचालन परिपक्वता के आधार पर चयन करें।
फॉलो-अप 2: एक बाहरी राइट के बाद एक कंपोनेंट का समय समाप्त (timeout) हो जाता है। क्या आप पुनः प्रयास कर सकते हैं?
टाइमआउट यह साबित नहीं कर सकता कि राइट नहीं हुआ था। बाहरी सिस्टम को एक अनुरोध आईडी और इडेम्पोटेंसी की पास करें, UNKNOWN रिकॉर्ड करें, और एक क्वेरी या कंपेंसेशन वर्कफ़्लो के माध्यम से पुष्टि करें। निष्पादन न होने की पुष्टि के बाद ही या जब बाहरी अनुबंध इडेम्पोटेंसी की गारंटी देता है, तभी पुनः प्रयास करें; Component Model क्रॉस-सिस्टम लेनदेन प्रदान नहीं करता है।
फॉलो-अप 3: आप किसी प्लगइन को लॉग के माध्यम से डेटा निकालने (exfiltrate) से कैसे रोकते हैं?
लॉगिंग भी एक कैपेबिलिटी है। फ़ील्ड आकार, संरचना और दर को सीमित करें; संवेदनशील फ़ील्ड्स को वर्गीकृत करें और टेनेंट्स को अलग करें। एक उच्च जोखिम वाला प्लगइन एक रिडैक्टिंग प्रॉक्सी का उपयोग कर सकता है या उसे कोई लॉगिंग इम्पोर्ट नहीं मिल सकता है। रनटाइम ऑडिट वर्ज़न, कैपेबिलिटीज़ और कॉल काउंट्स को रिकॉर्ड करता है, सुरक्षा प्रमाण के रूप में लॉग सामग्री को नहीं।
फॉलो-अप 4: क्या होगा यदि WASI Preview वर्ज़न बदल जाए?
WASI इंटरफ़ेस पैकेज और रनटाइम वर्ज़न को कंपोनेंट रिलीज़ मेनिफेस्ट में रखें, और कम्पैटिबिलिटी मैट्रिक्स को एक डिप्लॉयमेंट गेट बनाएं। नए रनटाइम को पुराने world के साथ रिग्रेशन और परिणाम तुलना के साथ चलाएं; सिमेंटिक्स भिन्न होने पर पुराने रनटाइम या एडेप्टर को बनाए रखें। "WASI लागू करता है" क्रॉस-वर्ज़न कम्पैटिबिलिटी का वादा नहीं है।