प्रॉम्प्ट और संदर्भ
एक HTTP/3 गेटवे दीर्घकालिक (long-lived) कनेक्शन और मल्टीप्लेक्स रिक्वेस्ट्स को संभालता है। रोलआउट के दौरान इसे नए कार्यों को अस्वीकार करना चाहिए, स्वीकृत रिक्वेस्ट्स को पूरा करना चाहिए और समय सीमा के बाद सुरक्षित रूप से बंद होना चाहिए। RFC 9114 GOAWAY के साथ ग्रेसफुल शटडाउन डिज़ाइन करें और QUIC कनेक्शन क्लोज़ तथा HTTP पुनः प्रयासों के साथ इसकी सीमा स्पष्ट करें।
साक्षात्कारकर्ता क्या जांच रहा है
भविष्य के रिक्वेस्ट्स को सीमित करने वाले GOAWAY और QUIC कनेक्शन को समाप्त करने वाले CONNECTION_CLOSE के बीच अंतर करना। HTTP/3 GOAWAY एक रिक्वेस्ट-स्ट्रीम ID सीमा वहन करता है; एक सर्वर व्यापक मान से शुरुआत कर सकता है और इसे अंतिम सीमा तक घटा सकता है। समवर्ती (concurrent) स्ट्रीम्स, अप्रसंस्कृत (unprocessed) रिक्वेस्ट्स के बारे में क्लाइंट की जानकारी, इडेम्पोटेन्सी (idempotency), प्रॉक्सी प्रसार, टाइमआउट और अवलोकनीयता (observability) को कवर करें।
पहले पूछने योग्य स्पष्टीकरण प्रश्न
रिक्वेस्ट और कनेक्शन का स्वरूप
लॉन्ग पोलिंग, अपलोड, WebTransport, गैर-इडेम्पोटेंट POSTs और रिवर्स प्रॉक्सी के बारे में पूछें। स्ट्रीम प्रकार के आधार पर पूरा होने का समय और पुनः प्रयास का जोखिम भिन्न होता है।
ड्रेन का उद्देश्य और समय सीमाएं
स्पष्ट करें कि क्या यह कनेक्शन ड्रेनिंग है, नोड रखरखाव है, या फ़ॉल्ट आइसोलेशन है। अधिकतम ड्रेन समय सीमा, हार्ड-क्लोज़ समय सीमा और रोलआउट बैच आकार निर्धारित करें; अन्यथा पुराने कनेक्शन अनिश्चित काल तक क्षमता का उपभोग कर सकते हैं।
क्लाइंट क्षमता
पुष्टि करें कि क्लाइंट और प्रॉक्सी GOAWAY को प्रोसेस करते हैं, पुनः कनेक्ट और माइग्रेशन का समर्थन करते हैं, और "नई स्ट्रीम अस्वीकृत" तथा "रिक्वेस्ट निष्पादित लेकिन प्रतिक्रिया खो गई" के बीच अंतर कर सकते हैं।
30-सेकंड का उत्तर ढांचा
"HTTP/3 GOAWAY एक रिक्वेस्ट-स्ट्रीम ID सीमा विज्ञापित करता है; इसे प्राप्त करने के बाद, एक पीयर को उस सीमा से ऊपर नई रिक्वेस्ट्स नहीं बनानी चाहिए। सर्वर पहले एक बड़ा मान भेजता है, नया कार्य सौंपना बंद करता है, और फिर एक छोटा अंतिम मान भेजता है ताकि क्लाइंट को पता चले कि कौन सी रिक्वेस्ट्स स्वीकृत नहीं हुई होंगी। स्वीकृत स्ट्रीम्स ड्रेन होती हैं; समय सीमा के बाद सर्वर QUIC CONNECTION_CLOSE का उपयोग करता है। एक क्लाइंट केवल तभी पुनः प्रयास करता है जब वह स्थापित कर सके कि कोई रिक्वेस्ट निष्पादित नहीं हुई थी और ऑपरेशन को दोहराना सुरक्षित है।"
चरण-दर-चरण विस्तृत उत्तर
चरण 1: GOAWAY को CONNECTION_CLOSE से अलग करें
GOAWAY एक HTTP/3 नियंत्रण संदेश है जो उच्चतम रिक्वेस्ट-स्ट्रीम ID को सीमित करता है; यह कनेक्शन को तुरंत समाप्त नहीं करता है। CONNECTION_CLOSE QUIC को समाप्त करता है और सक्रिय रिक्वेस्ट्स को बाधित कर सकता है। पहले GOAWAY से ड्रेन करें और केवल हार्ड समय सीमा पर ही बंद करें।
चरण 2: व्यापक-फिर-संकीर्ण सीमा का उपयोग करें
एक बड़ी ID भेजें जो अवलोकित समवर्ती रिक्वेस्ट्स को कवर करती हो, नया कार्य स्वीकार करना बंद करें, और फिर एक छोटी अंतिम ID भेजें। क्लाइंट को घटती प्रक्रिया को नई रिक्वेस्ट्स बनाने की अनुमति के रूप में नहीं समझना चाहिए। नियंत्रण-फ़्रेम क्रम और स्थिति को बनाए रखें ताकि पुनः कनेक्ट लॉजिक नियतात्मक (deterministic) हो।
चरण 3: स्वीकृत, अप्रारंभिक और अज्ञात रिक्वेस्ट्स को संभालें
अंतिम सीमा से नीचे की स्वीकृत स्ट्रीम्स जारी रहती हैं। इससे ऊपर की रिक्वेस्ट्स स्वीकार नहीं की गईं और एक नए कनेक्शन पर उनका पुनः प्रयास किया जा सकता है। यदि सर्वर यह नहीं जान सकता कि कोई गैर-इडेम्पोटेंट रिक्वेस्ट निष्पादित हुई या नहीं, तो आँख बंद करके रीप्ले करने के बजाय एक इडेम्पोटेन्सी कुंजी या स्थिति लुकअप प्रदान करें।
चरण 4: प्रॉक्सी और माइग्रेशन व्यवहार डिज़ाइन करें
एक रिवर्स प्रॉक्सी जो अपस्ट्रीम GOAWAY प्राप्त करती है, उसे उस कनेक्शन पर नई रिक्वेस्ट्स सौंपना बंद कर देना चाहिए और ड्रेन स्थिति को डाउनस्ट्रीम प्रसारित करना चाहिए। QUIC कनेक्शन माइग्रेशन रिक्वेस्ट माइग्रेशन नहीं है; पथ बदलना किसी निष्पादित हो रही HTTP स्ट्रीम को सुरक्षित रूप से स्थानांतरित नहीं करता है।
चरण 5: ड्रेन और हार्ड-क्लोज़ समय सीमाएं निर्धारित करें
GOAWAY समय, अंतिम सक्रिय स्ट्रीम और शेष रिक्वेस्ट्स को रिकॉर्ड करें। ड्रेन टाइमआउट पर अधूरी स्ट्रीम्स को रद्द करें; हार्ड-क्लोज़ समय पर CONNECTION_CLOSE भेजें और कनेक्शन को रिलीज़ करें। एक बार में ड्रेन होने वाले इंस्टेंसेस की संख्या सीमित करें ताकि क्षमता पूरी तरह समाप्त न हो जाए।
चरण 6: पुनः प्रयासों और दुष्प्रभावों (side effects) की सुरक्षा करें
केवल उन इडेम्पोटेंट विधियों या इडेम्पोटेन्सी कुंजी वाले राइट्स का पुनः प्रयास करें जिनके अनिष्पादित होने की पुष्टि हो, वह भी एक्सपोनेंशियल बैकऑफ़ और पुनः प्रयास बजट के साथ। खोई हुई प्रतिक्रिया यह साबित नहीं करती कि रिक्वेस्ट निष्पादित नहीं हुई थी; भुगतानों और इन्वेंट्री परिवर्तनों को सर्वर-साइड डी-डुप्लीकेशन की आवश्यकता होती है।
चरण 7: रोलआउट को सत्यापित करें
कैनरी में, लंबी रिक्वेस्ट्स, समवर्ती स्ट्रीम्स, पुनः कनेक्ट, घटते GOAWAY मान, प्रॉक्सी प्रसार और हार्ड क्लोज़ को इंजेक्ट करें। अस्वीकृत नई स्ट्रीम्स, ड्रेन अवधि, अधूरी स्ट्रीम्स, पुनः प्रयास दर, डुप्लिकेट दुष्प्रभाव, कनेक्शन त्रुटियों और क्षमता हेडरूम की निगरानी करें। रोलआउट के दौरान p99 लेटेंसी और त्रुटि दर की जांच करें।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं नए कनेक्शन सौंपना बंद करूँगा, नई स्ट्रीम्स को रोकने के लिए एक व्यापक GOAWAY भेजूँगा, और फिर समवर्ती रिक्वेस्ट्स का अवलोकन करने के बाद एक छोटी अंतिम सीमा भेजूँगा। सीमा से नीचे की स्वीकृत स्ट्रीम्स ड्रेन होती हैं; केवल समय सीमा समाप्त होने के बाद ही उन्हें रद्द किया जाता है और QUIC कनेक्शन बंद किया जाता है। क्लाइंट केवल अनिष्पादित पुष्टि वाले इडेम्पोटेंट ऑपरेशनों का पुनः प्रयास करते हैं, गैर-इडेम्पोटेंट राइट्स के लिए इडेम्पोटेन्सी कुंजियों का उपयोग करते हैं। प्रॉक्सी ड्रेन स्थिति का प्रसार करते हैं, जबकि माइग्रेशन को कभी भी रिक्वेस्ट ट्रांसफर नहीं माना जाता है। कैनरी परीक्षण लंबी रिक्वेस्ट्स, समवर्ती स्ट्रीम्स, पुनः प्रयासों, प्रॉक्सी व्यवहार और डुप्लिकेट प्रभावों को कवर करते हैं।
सामान्य गलतियां
- गलती: GOAWAY के तुरंत बाद QUIC को बंद करना। → यह क्यों विफल होता है: सक्रिय रिक्वेस्ट्स बाधित हो जाती हैं। → समाधान: पहले ड्रेन करें और हार्ड समय सीमा पर बंद करें।
- गलती: GOAWAY सीमा को निष्पादन लेज़र के रूप में मानना। → यह क्यों विफल होता है: एक स्ट्रीम ID केवल एक सीमा (range) दर्शाती है, एप्लिकेशन की पूर्णता नहीं। → समाधान: एप्लिकेशन स्थिति और इडेम्पोटेन्सी कुंजियों के साथ पुष्टि करें।
- गलती: प्रत्येक विफल रिक्वेस्ट का पुनः प्रयास करना। → यह क्यों विफल होता है: किसी दुष्प्रभाव के बाद प्रतिक्रिया खो सकती है। → समाधान: पुनः प्रयासों को केवल इडेम्पोटेंट या की-युक्त ऑपरेशनों तक सीमित करें।
- गलती: यह मानना कि कनेक्शन माइग्रेशन सक्रिय रिक्वेस्ट्स को स्थानांतरित करता है। → यह क्यों विफल होता है: पथ परिवर्तन HTTP स्ट्रीम स्थिति को नहीं बदलता है। → समाधान: सुरक्षित पुनः प्रयासों के लिए एक नए कनेक्शन का उपयोग करें।
फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: GOAWAY मान क्यों घट सकते हैं?
सर्वर पहले अवलोकित समवर्ती रिक्वेस्ट्स को कवर कर सकता है और फिर नई स्ट्रीम्स के लिए अंतिम सीमा स्थापित कर सकता है। घटने की सुविधा क्लाइंट को पहले संकेत पर ही सभी इन-फ़्लाइट कार्यों का अनुमान लगाए बिना एकरूप (converge) होने की अनुमति देती है।
फॉलो-अप 2: एक क्लाइंट को कैसे पता चलता है कि कोई रिक्वेस्ट स्वीकार की गई थी या नहीं?
एक स्ट्रीम ID की अंतिम सीमा से तुलना करने पर एक संभावित सीमा का पता चलता है, यह नहीं कि एप्लिकेशन कोड निष्पादित हुआ या नहीं। इसे प्रतिक्रिया, कनेक्शन त्रुटि और इडेम्पोटेन्सी-स्थिति लुकअप के साथ संयोजित करें।
फॉलो-अप 3: क्या GOAWAY प्रॉक्सी के माध्यम से स्वचालित रूप से प्रसारित होता है?
ऐसा न मानें। एक प्रॉक्सी एक स्वतंत्र HTTP/3 एंडपॉइंट है और उसे अपस्ट्रीम ड्रेनिंग को डाउनस्ट्रीम कनेक्शन और रूटिंग नीति में अनुवादित करना होगा।
फॉलो-अप 4: हार्ड क्लोज़ से पहले स्ट्रीम्स को रद्द क्यों करें?
रद्दीकरण एप्लिकेशन संसाधनों को मुक्त करता है और एक स्पष्ट कारण रिकॉर्ड करता है, जिससे क्लाइंट ड्रेन टाइमआउट को नेटवर्क विफलता से अलग पहचान सकते हैं। QUIC क्लोज़ अंतिम कनेक्शन सीमा है, कोई एप्लिकेशन क्लीनअप तंत्र नहीं।