प्रॉम्प्ट और दायरा
आप पेमेंट, पासवर्ड-परिवर्तन या ऑर्डर-निर्माण API के प्रभारी हैं। एज (edge) TLS 1.3 0-RTT को सक्षम करता है, और एक गेटवे Early-Data: 1 ले जाने वाले अनुरोधों को अग्रेषित (forward) कर सकता है। बताएं कि कब 425 वापस करना है, कब आगे बढ़ना है, और हैंडशेक पूरा होने के बाद क्लाइंट कैसे रिट्री करता है। यह बैकएंड, प्लेटफॉर्म और API-इन्फ्रास्ट्रक्चर इंटरव्यू के लिए उपयुक्त है।
RFC 8470, 425 को सर्वर द्वारा ऐसे अनुरोध को प्रोसेस करने के जोखिम से इनकार करने के रूप में परिभाषित करता है जिसे रीप्ले किया जा सकता है; यह कोई सामान्य "सर्वर व्यस्त है" रिट्री कोड नहीं है। मान लें कि गेटवे Early-Data सिग्नल को बनाए रख सकता है और सर्विस केवल-पढ़ने योग्य (read-only) ऑपरेशनों को साइड इफेक्ट्स से अलग कर सकती है।
इंटरव्यूअर क्या जांच रहा है
- क्या आप 0-RTT के लेटेंसी लाभ को रीप्ले जोखिम (replay risk) से अलग करते हैं, बजाय इसके कि हर 4xx को सामान्य क्लाइंट इनपुट की तरह मानें।
- क्या आप प्रतीक्षा करने, रिट्री करने और इडेम्पोटेंसी के लिए क्लाइंट, गेटवे और एप्लिकेशन की जिम्मेदारियों को ट्रैक कर सकते हैं।
- क्या आप RFC शर्तों, नॉन-कैशेबिलिटी और रिट्री टाइमिंग को एक परीक्षण योग्य API पॉलिसी में बदल सकते हैं।
एक कमजोर उत्तर "425 का अर्थ Too Early है" याद रखता है। एक मजबूत उत्तर साइड इफेक्ट्स, Early-Data सिग्नल, एक इडेम्पोटेंसी कुंजी और एक सीमित रिट्री विंडो से निर्णय लेता है, फिर बताता है कि एक गलत कॉन्फ़िगरेशन किसी ग्राहक से दो बार शुल्क कैसे ले सकता है।
पहले पूछे जाने वाले स्पष्टीकरण प्रश्न
- क्या अनुरोध
Early-Data: 1ले जाता है, या क्या एज यह साबित कर सकता है कि यह early data में आया है? RFC 8470 उस सिग्नल के बिना 425 प्रतिक्रियाएं गढ़ने के खिलाफ सलाह देता है। - क्या ऑपरेशन कोई बाहरी साइड इफेक्ट उत्पन्न करता है? ऑर्डर को पढ़ना आगे बढ़ सकता है; एक चार्ज, पासवर्ड परिवर्तन या कूपन जारी करने को हैंडशेक की प्रतीक्षा करनी चाहिए या एक सख्त इडेम्पोटेंसी रिकॉर्ड का उपयोग करना चाहिए।
- क्या गेटवे स्वचालित रूप से रिट्री करेगा? यदि हाँ, तो सत्यापित करें कि यह हैंडशेक के बाद रिट्री करता है और गेटवे तथा SDK दोनों अलग-अलग रिट्री नहीं करेंगे।
- क्या क्लाइंट इडेम्पोटेंसी कुंजी और रिट्री सीमा का समर्थन करता है? उनके बिना, ऑपरेशन के लिए 0-RTT को अक्षम करना 425 को हमेशा के लिए रिट्री करने की अनुमति मानने से अधिक सुरक्षित है।
30 सेकंड का उत्तर
"मैं पहले सत्यापित करता हूं कि अनुरोध Early-Data: 1 के साथ TLS early data के माध्यम से आया है, फिर इसके साइड इफेक्ट्स को वर्गीकृत करता हूं। केवल-पढ़ने योग्य कार्य आगे बढ़ सकता है; भुगतान और पासवर्ड परिवर्तन या तो गेटवे पर प्रतीक्षा करते हैं या 425 प्राप्त करते हैं। क्लाइंट केवल हैंडशेक पूरा होने के बाद रिट्री करता है, और सर्विस डुप्लिकेट निष्पादन को रोकने के लिए एक इडेम्पोटेंसी कुंजी और विशिष्टता बाधा (uniqueness constraint) का उपयोग करती है। गेटवे सिग्नल को सुरक्षित रखता है, एक रिट्री पॉलिसी का स्वामित्व रखता है, और हम 425 दर, रिट्री सफलता और डुप्लिकेट साइड इफेक्ट्स की निगरानी करते हैं। यदि पूरी चेन इन शर्तों को साबित नहीं कर सकती है, तो मैं राइट एंडपॉइंट्स के लिए 0-RTT को अक्षम कर देता हूं।"
चरण-दर-चरण समाधान
1. जोखिम संकेत की पहचान करें
RFC 8470 के लिए आवश्यक है कि मध्यस्थ (intermediaries) early data को आगे भेजते समय Early-Data अर्थ को सुरक्षित रखें। एक सर्विस को 425 पर केवल तभी विचार करना चाहिए जब अनुरोध को रीप्ले किया जा सकता हो। बिना प्रमाण के 425 लौटाना एक साधारण नेटवर्क विफलता को भ्रामक सुरक्षा अस्वीकृति में बदल देता है।
2. साइड इफेक्ट के आधार पर वर्गीकृत करें
एंडपॉइंट्स को केवल-पढ़ने योग्य (read-only), सुरक्षित रूप से दोहराने योग्य (safely repeatable), या दोहराने के लिए असुरक्षित के रूप में वर्गीकृत करें। GET /orders/123 सामान्यतः केवल-पढ़ने योग्य है; एकमुश्त कूपन जारी करना, कार्ड से शुल्क लेना, या पासवर्ड बदलना सुरक्षित रूप से दोहराने योग्य नहीं है। असुरक्षित वर्ग को किसी भी साइड इफेक्ट से पहले एक पूर्ण हैंडशेक की प्रतीक्षा करनी चाहिए या एक इडेम्पोटेंसी कुंजी को सहेजना चाहिए।
3. एक रिट्री स्वामी असाइन करें
425 के बाद, क्लाइंट TLS हैंडशेक की प्रतीक्षा करता है और अनुरोध फिर से भेजता है; रिट्री में early data का उपयोग नहीं होना चाहिए। एक गेटवे उस रिट्री का स्वामित्व ले सकता है, लेकिन अनुबंध में ऐसा स्पष्ट होना चाहिए, अन्यथा गेटवे और SDK दोनों रिट्री कर सकते हैं। एक्सपोनेंशियल बैकऑफ़, अधिकतम प्रयास गणना और प्रत्येक रिट्री के लिए एक दृश्यमान कारण सेट करें।
4. इडेम्पोटेंसी को दूसरा बचाव बनाएं
राइट्स के लिए एक इडेम्पोटेंसी कुंजी की आवश्यकता रखें। सर्विस टेनेंट, एंडपॉइंट और कुंजी द्वारा अनुक्रमित एक अद्वितीय रिकॉर्ड संग्रहीत करती है, जिसमें कम से कम प्रोसेसिंग, सफलता और रिट्री योग्य-विफलता स्थितियां होती हैं। एक डुप्लिकेट मूल परिणाम या स्पष्ट इन-प्रोग्रेस प्रतिक्रिया देता है। इडेम्पोटेंसी 425 की जगह नहीं लेती है: डेटाबेस कमिट के बाद और क्लाइंट तक प्रतिक्रिया पहुंचने से पहले पहला निष्पादन अभी भी रीप्ले किया जा सकता है।
5. गेटवे और इंस्टेंसेस को सुसंगत रखें
प्रत्येक इंस्टेंस को समान Early-Data पॉलिसी लागू करनी चाहिए। यदि कोई गेटवे अनिश्चित है कि अपस्ट्रीम सिग्नल को समझता है, तो वह हैंडशेक की प्रतीक्षा करता है या प्रारंभिक अनुरोध को अस्वीकार करता है; इसे केवल-HTTP सर्विस पर बिना बताए राइट को अग्रेषित नहीं करना चाहिए। एक अनुरोध ID, Early-Data स्थिति, 425 कारण और एक हैश की गई इडेम्पोटेंसी कुंजी लॉग करें, भुगतान सामग्री को कभी नहीं।
6. विफलता पथों का परीक्षण करें
Early-Data: 1 के साथ और उसके बिना अनुरोधों का परीक्षण करें, हैंडशेक के बाद पहला रिट्री, गेटवे रिट्रीज़, क्लाइंट टाइमआउट के बाद पुनः सबमिशन, और एक इडेम्पोटेंसी कुंजी पर प्रतिस्पर्धा करने वाले दो इंस्टेंसेस। पुष्टि करें कि एक असुरक्षित साइड इफेक्ट केवल एक बार होता है और 425 को कैश नहीं किया जाता है।
सरल विकल्प 0-RTT को पूरी तरह से अक्षम करना है। इसकी एक स्पष्ट सुरक्षा सीमा है लेकिन यह हैंडशेक लेटेंसी को जोड़ता है। कुछ एंडपॉइंट्स के लिए जहां लेटेंसी की बचत महत्वहीन है, इसे अक्षम करना क्रॉस-लेयर पॉलिसी बनाए रखने की तुलना में अधिक सुरक्षित है।
उच्च गुणवत्ता वाला नमूना उत्तर
"मैं 425 का उपयोग सामान्य थ्रॉटलिंग त्रुटि के रूप में नहीं करूंगा। मैं पहले Early-Data: 1 की जांच करता हूं, फिर पूछता हूं कि क्या ऑपरेशन का कोई साइड इफेक्ट है। ऑर्डर पढ़ना आगे बढ़ सकता है; भुगतान और पासवर्ड-परिवर्तन एंडपॉइंट्स गेटवे पर प्रतीक्षा करते हैं या 425 लौटाते हैं। क्लाइंट एक सीमित SDK पॉलिसी के साथ, हैंडशेक के ठीक बाद रिट्री करता है। सर्विस को एक इडेम्पोटेंसी कुंजी की भी आवश्यकता होती है, टेनेंट-प्लस-की विशिष्टता बाधा को लागू करती है, और प्रोसेसिंग तथा अंतिम परिणाम संग्रहीत करती है ताकि खोई हुई प्रतिक्रिया दूसरा चार्ज न लगा सके। गेटवे और इंस्टेंसेस एक पॉलिसी साझा करते हैं, और हम 425 दर, रिट्री सफलता और डुप्लिकेट निष्पादन की निगरानी करते हैं। यदि Early-Data प्रसारित नहीं किया जा सकता है, तो मैं अनुमान लगाने के बजाय राइट्स के लिए 0-RTT को अक्षम कर देता हूं।"
सामान्य गलतियाँ
- 425 को 429 के प्रतिस्थापन के रूप में उपयोग करना → ट्रिगर और क्लाइंट क्रिया भिन्न हैं → 425 का उपयोग केवल तब करें जब early-data रीप्ले जोखिम मौजूद हो।
- प्रत्येक अनुरोध के लिए 425 लौटाना → रीड्स अवरुद्ध हो जाते हैं और क्लाइंट हमेशा के लिए पुनः प्रयास कर सकते हैं → साइड इफेक्ट्स को वर्गीकृत करें और रिट्रीज़ को सीमित करें।
- फिर से 0-RTT में पुनः प्रयास करना → रीप्ले विंडो खुली रहती है → फिर से भेजने से पहले एक पूर्ण हैंडशेक की आवश्यकता रखें।
- इडेम्पोटेंसी को केवल एप्लिकेशन में रखना → एक गेटवे या अन्य इंस्टेंस पहले निष्पादित हो सकता है → एज, सर्विस और पर्सिस्टेंस में एक पॉलिसी लागू करें।
- पूरे भुगतान भाग (body) को लॉग करना → डिबगिंग संवेदनशील डेटा को उजागर करती है → पहचानकर्ता, कारण और एक छिपा हुआ (redacted) कुंजी हैश लॉग करें।
अनुवर्ती प्रश्न और उत्तर
क्या होगा यदि गेटवे Early-Data हेडर को हटा देता है?
इसे एक क्षमता अंतर (capability gap) के रूप में मानें: गेटवे को हैंडशेक की प्रतीक्षा करनी चाहिए या प्रारंभिक अनुरोध को अस्वीकार करना चाहिए। एप्लिकेशन एक साधारण अनुरोध से 0-RTT का अनुमान नहीं लगा सकता है; राइट्स सक्षम करने से पहले सिग्नल प्रसारण को ठीक करें।
क्या होगा यदि क्लाइंट टाइमआउट हो जाता है और 425 देखने से पहले फिर से सबमिट कर देता है?
समान इडेम्पोटेंसी कुंजी का उपयोग करें ताकि दूसरा अनुरोध पहले अनुरोध की इन-प्रोग्रेस या अंतिम स्थिति को पढ़ सके। बिना कुंजी के खतरनाक राइट के लिए, एक निदान योग्य त्रुटि लौटाएं और एक मैनुअल या क्षतिपूर्ति वर्कफ़्लो का उपयोग करें; अनुमान न लगाएं कि चार्ज लगा था या नहीं।
क्या होगा यदि रिट्रीज़ अक्सर सफल होते हैं लेकिन लेटेंसी SLO को खराब करते हैं?
एंडपॉइंट और यूजर एजेंट द्वारा 425 दर, p95 पहली-सफलता लेटेंसी, डुप्लिकेट साइड इफेक्ट्स और व्यावसायिक सफलता की तुलना करें। यदि राइट का लाभ लेटेंसी की भरपाई नहीं करता है, तो 0-RTT को केवल सुरक्षित रीड्स के लिए रखें या उस वर्ग के एंडपॉइंट के लिए इसे अक्षम करें।