बैकएंड इंटरव्यू: आप HTTP/2 Extended CONNECT पर WebSockets को कैसे चलाएंगे?

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

एक गेटवे और क्लाइंट HTTP/2 का समर्थन करते हैं, और एक रीयल-टाइम सेवा एक ही कनेक्शन पर WebSocket स्ट्रीम्स को मल्टीप्लेक्स करना चाहती है। एक RFC 8441 माइग्रेशन डिज़ाइन करें: हैंडशेक, क्षमता नेगोशिएशन, प्रॉक्सी अनुकूलता, स्ट्रीम बनाम कनेक्शन बंद होना, फ़ॉलबैक और स्वीकृति मेट्रिक्स। यह HTTP/2 extended-connect सेमांटिक्स के बारे में एक backend प्रश्न है।

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

1. Extended CONNECT को HTTP/1.1 Upgrade से अलग पहचानना।
2. :protocol और SETTINGS_ENABLE_CONNECT_PROTOCOL का सही उपयोग करना।
3. HTTP/2 स्ट्रीम बंद होने को कनेक्शन बंद होने से अलग करना।
4. असमर्थित प्रॉक्सी और क्लाइंट्स के लिए फ़ॉलबैक डिज़ाइन करना।
5. हैंडशेक, स्ट्रीम एरर, पुन: उपयोग और लेटेंसी को मापना।

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

• क्या क्लाइंट, एज प्रॉक्सी, लोड बैलेंसर, गेटवे और ओरिजिन RFC 8441 का समर्थन करते हैं?
• क्या सामान्य अनुरोध और WebSocket स्ट्रीम एक ही HTTP/2 कनेक्शन साझा कर सकते हैं?
• क्या लोड बैलेंसर HTTP/2 को एंड-टू-एंड बनाए रखता है या इसे समाप्त करके फिर से बनाता है?
• क्या पुराने क्लाइंट HTTP/1.1 Upgrade का उपयोग जारी रख सकते हैं?
• क्या क्लाइंट एक ब्राउज़र, नेटिव SDK या आंतरिक RPC कार्यान्वयन है?

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

“मैं हर हॉप पर SETTINGS_ENABLE_CONNECT_PROTOCOL को सत्यापित करूँगा। एक सक्षम क्लाइंट :protocol = websocket के साथ Extended CONNECT भेजता है; सफलता के बाद, वह HTTP/2 स्ट्रीम WebSocket फ्रेम्स ले जाती है। एक असमर्थित हॉप HTTP/1.1 Upgrade पर फ़ॉलबैक करता है। एक स्ट्रीम को रद्द करने से पूरा कनेक्शन बंद नहीं होना चाहिए। कैनरी रोलआउट के दौरान, मैं हैंडशेक सफलता, फ़ॉलबैक, RST_STREAM, GOAWAY, पुन: उपयोग और पहले संदेश की लेटेंसी को ट्रैक करूँगा।”

विस्तृत उत्तर

चरण 1: एक्सटेंशन समर्थन पर बातचीत (Negotiate) करें

एंडपॉइंट्स HTTP/2 SETTINGS के माध्यम से Extended CONNECT का विज्ञापन करते हैं। क्लाइंट समर्थन प्राप्त करने के बाद ही :protocol स्यूडो-हेडर भेजता है; एक प्रॉक्सी जो सेटिंग को हटा देती है, उसे एक अमान्य अनुरोध भेजने के बजाय फ़ॉलबैक ट्रिगर करना चाहिए।

SETTINGS_ENABLE_CONNECT_PROTOCOL = 1
:method = CONNECT
:protocol = websocket
:authority = chat.example

यह स्निपेट हैंडशेक फ़ील्ड्स दिखाता है; फ्रेम ऑर्डरिंग अभी भी HTTP/2 और RFC 8441 का पालन करती है।

चरण 2: हैंडशेक और स्ट्रीम डेटा को संभालें

एक सफल Extended CONNECT एक HTTP/2 स्ट्रीम बनाता है जो WebSocket फ्रेम सेमांटिक्स ले जाती है। यह HTTP/1.1 के Connection, Upgrade, Sec-WebSocket-Key या 101 पथ का उपयोग नहीं करता है। सर्वर अभी भी प्रमाणित करता है, ओरिजिन की जांच करता है, और सब-प्रोटोकॉल तथा एक्सटेंशन पर बातचीत करता है।

चरण 3: लाइफ़साइकिल को अलग करें

RST_STREAM या सामान्य स्ट्रीम बंद होना केवल एक WebSocket को प्रभावित करता है, कनेक्शन पर मौजूद अन्य अनुरोधों को नहीं। GOAWAY नई स्ट्रीम्स को रोकता है; मौजूदा स्ट्रीम्स को पूर्णता, माइग्रेशन या पुनः कनेक्ट नीति की आवश्यकता होती है। रीकनेक्ट लॉजिक को उन संदेशों को दोबारा भेजने से बचना चाहिए जिन्हें पहले ही स्वीकार (acknowledge) किया जा चुका है।

चरण 4: प्रॉक्सी फ़ॉलबैक डिज़ाइन करें

क्लाइंट्स, CDNs, लोड बैलेंसर्स और गेटवे के लिए एक क्षमता मैट्रिक्स बनाएं। यदि किसी भी हॉप में समर्थन की कमी है, तो HTTP/1.1 Upgrade का उपयोग करें या एक स्पष्ट असमर्थित एरर लौटाएं; :protocol को सामान्य हेडर के रूप में अग्रेषित न करें। दोनों पथों में प्रमाणीकरण, ओरिजिन जांच, सब-प्रोटोकॉल और हार्टबीट व्यवहार को सुरक्षित रखें।

चरण 5: फ्लो कंट्रोल और बैकप्रेशर

HTTP/2 फ्लो-कंट्रोल विंडो और एप्लिकेशन कतार दोनों लागू होते हैं। प्रति-स्ट्रीम और प्रति-कनेक्शन बफ़र्स को सीमित करें, विंडो स्टॉल का निरीक्षण करें, और सुनिश्चित करें कि एक धीमी स्ट्रीम कनेक्शन साझा करने वाले सामान्य अनुरोधों को ब्लॉक न कर सके।

चरण 6: कैनरी और सुरक्षा जांच

आंतरिक क्लाइंट्स और एक क्षेत्र के साथ शुरुआत करें। हैंडशेक सफलता, पहले संदेश की लेटेंसी, रीकनेक्ट्स, RST_STREAM, GOAWAY और प्रॉक्सी त्रुटियों के लिए Extended CONNECT की HTTP/1.1 Upgrade से तुलना करें। TLS, ओरिजिन, प्रमाणीकरण, सब-प्रोटोकॉल और संदेश-आकार की सीमाएं अपरिवर्तित रहती हैं।

चरण 7: रोलबैक और स्वीकृति परिभाषित करें

HTTP/2 WebSockets को अक्षम करने के लिए एक क्लाइंट- या क्षेत्र-स्तरीय स्विच रखें। अनुपलब्ध SETTINGS, अस्वीकृत प्रोटोकॉल, स्ट्रीम रद्दीकरण, GOAWAY, नेटवर्क परिवर्तन और डुप्लिकेट रीकनेक्ट्स का परीक्षण करें। विस्तार करने से पहले संदेश क्रम, p95 लेटेंसी, कनेक्शन संख्या और फ़ॉलबैक अनुपात की तुलना करें।

आदर्श उत्तर

“मैं एक एंड-टू-एंड क्षमता मैट्रिक्स स्थापित करूँगा और प्रत्येक हॉप पर SETTINGS_ENABLE_CONNECT_PROTOCOL की आवश्यकता रखूँगा। समर्थित क्लाइंट :protocol = websocket के साथ Extended CONNECT भेजते हैं; सफल HTTP/2 स्ट्रीम WebSocket फ्रेम्स ले जाती है, जबकि असमर्थित पथ HTTP/1.1 Upgrade का उपयोग करते हैं। प्रमाणीकरण, ओरिजिन, सब-प्रोटोकॉल, हार्टबीट और आकार सीमाएं समान रहती हैं।

RST_STREAM केवल एक WebSocket को प्रभावित करता है; GOAWAY नई स्ट्रीम्स को प्रभावित करता है और इसके लिए एक पूर्णता या रीकनेक्ट नीति की आवश्यकता होती है। कैनरी हैंडशेक, फ़ॉलबैक, रीकनेक्ट्स, पहले संदेश के p95, पुन: उपयोग और प्रॉक्सी त्रुटियों को मापता है, जिसमें अनुपलब्ध SETTINGS, अस्वीकृत प्रोटोकॉल, धीमी स्ट्रीम्स और नेटवर्क परिवर्तनों को इंजेक्ट किया जाता है।”

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

• Extended CONNECT को सामान्य हेडर के रूप में मानना → प्रॉक्सी इसे अस्वीकार कर सकते हैं या गलत रूट कर सकते हैं → SETTINGS और स्यूडो-हेडर्स को मान्य करें।
• HTTP/1.1 Upgrade हेडर भेजना → HTTP/2 उस हैंडशेक का उपयोग नहीं करता है → RFC 8441 का पालन करें।
• RST_STREAM पर कनेक्शन बंद करना → असंबद्ध अनुरोध विफल हो जाते हैं → स्ट्रीम और कनेक्शन स्थिति को अलग करें।
• GOAWAY की उपेक्षा करना → रीकनेक्ट और समापन अस्पष्ट हो जाते हैं → लाइफ़साइकिल नीति परिभाषित करें।
• केवल प्रत्यक्ष कनेक्शन का परीक्षण करना → CDN और लोड-बैलेंसर के अंतर प्रोडक्शन को बाधित करते हैं → प्रत्येक हॉप का परीक्षण करें।
• माइग्रेशन के दौरान प्रमाणीकरण छोड़ना → एक्सटेंशन WebSocket सुरक्षा आवश्यकताओं को नहीं बदलता है → मौजूदा नीति का पुन: उपयोग करें।

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

फॉलो-अप 1: सीधे HTTP/3 WebSockets का उपयोग क्यों नहीं करते?

RFC 9220 HTTP/3 पथ को परिभाषित करता है। जब मौजूदा एंड-टू-एंड पथ HTTP/2 हो, तो RFC 8441 एक व्यावहारिक कदम है; समर्थन और माइग्रेशन लागत इसका निर्णय करते हैं।

फॉलो-अप 2: क्या कोई क्लाइंट सेटिंग के बिना Extended CONNECT का प्रयास कर सकता है?

नहीं। क्षमता संकेत की प्रतीक्षा करें, फिर प्रोटोकॉल-अमान्य अनुरोध भेजने के बजाय फ़ॉलबैक करें या असमर्थित रिपोर्ट करें।

फॉलो-अप 3: GOAWAY के बाद डुप्लिकेट संदेशों से कैसे बचें?

क्लाइंट अनुक्रम संख्या या आइडमपोटेंसी कुंजियों का उपयोग करें, स्वीकृत ऑफ़सेट को बनाए रखें (persist करें), और रीकनेक्ट के बाद एक परिभाषित बिंदु से फिर से शुरू करें।

फॉलो-अप 4: आप एक असंगत प्रॉक्सी का पता कैसे लगाते हैं?

प्रॉक्सी, क्षेत्र और क्लाइंट संस्करण द्वारा विभाजित करके, हॉप दर हॉप SETTINGS, CONNECT प्रतिक्रियाओं और एरर कोड्स को कैप्चर करें।