प्रॉम्प्ट और संदर्भ
एक सर्विस रिज़्यूम्ड कनेक्शन्स पर फर्स्ट-बाइट लेटेंसी कम करने के लिए TLS 1.3 0-RTT को सक्षम करती है। कुछ अनुरोध हैंडशेक पूरा होने से पहले आते हैं, और प्रारंभिक डेटा (early data) को किसी अन्य कनेक्शन पर रीप्ले किया जा सकता है। बताएं कि किसी API को 425 Too Early कब वापस करना चाहिए, क्लाइंट कैसे रीट्राई करता है, और गेटवे तथा प्रत्येक सर्विस रेप्लिका कैसे सुसंगत रहते हैं।
यह बैकएंड, नेटवर्किंग, इन्फ्रास्ट्रक्चर और सुरक्षा साक्षात्कारों के लिए उपयुक्त है। यह परीक्षा किसी स्टेटस कोड को रटने की नहीं है। यह ट्रांसपोर्ट-लेवल रीप्ले जोखिम को किसी रिसोर्स के वास्तविक साइड इफेक्ट्स के साथ मैप करने, और फिर 425, डिफरल (विलंब), प्रारंभिक डेटा को अक्षम करने, आइडेम्पोटेंसी कीज़ और ऑडिट साक्ष्य के बीच की सीमा को परिभाषित करने के बारे में है।
इंटरव्यूअर क्या जांच रहा है
एक मजबूत उत्तर यह स्पष्ट करता है कि 425 का अर्थ है कि सर्वर ऐसे अनुरोध को प्रोसेस करने का जोखिम नहीं उठाएगा जिसे रीप्ले किया जा सकता है। यह कोई सामान्य ओवरलोड, प्रमाणीकरण या व्यावसायिक-सत्यापन त्रुटि नहीं है। उत्तर सुरक्षित मेथड्स को साइड-इफेक्ट वाले रिसोर्सेज़ से अलग करता है, यह बताता है कि केवल ओरिजिन ही क्यों जानता है कि कोई रिसोर्स अर्ली डेटा को सहन कर सकता है या नहीं, और यह Early-Data हेडर, क्लाइंट रीट्राई, गेटवे फ़ॉरवर्डिंग और रेप्लिका निरंतरता को कवर करता है। यह रीट्राई स्टॉर्म्स, साझा स्थिति (shared state) और अपरिवर्तनीय प्रभावों को भी संबोधित करता है।
पहले स्पष्ट करने योग्य प्रश्न
- क्या अनुरोध वास्तव में अर्ली डेटा में आया था, या यह एक विश्वसनीय
Early-Data: 1ले जाता है? - क्या ऑपरेशन स्थिति को म्यूटेट करता है, पैसे चार्ज करता है, कोई ऑर्डर शिप करता है, कोई संदेश भेजता है, या कोई बाहरी साइड इफेक्ट ट्रिगर करता है?
- क्या क्लाइंट हैंडशेक के बाद, आइडेम्पोटेंसी की और डिडुप्लिकेशन स्टोर के साथ सुरक्षित रूप से रीट्राई कर सकता है?
- क्या गेटवे 425 और Early-Data को समझता है, और क्या सभी ओरिजिन रेप्लिकेस एक ही नीति साझा करते हैं?
- रिज़म्प्शन, लोड, टाइमआउट और रीट्राई बजट सुरक्षा और उपलब्धता को कैसे प्रभावित करते हैं?
30 सेकंड का उत्तर
"425 एक अर्ली-डेटा अनुरोध के लिए एक सुरक्षा अस्वीकृति (safety rejection) है जिसे रीप्ले किया जा सकता है, न कि कोई सामान्य दर सीमा (rate limiting)। ओरिजिन रिसोर्स के जोखिम के आधार पर चयन करता है: साइड-इफेक्ट-मुक्त या प्रमाणित रूप से आइडेम्पोटेंट अनुरोध आगे बढ़ सकता है या स्थगित किया जा सकता है, जबकि चार्जिंग, राइट्स और अपरिवर्तनीय क्रियाओं को हैंडशेक की प्रतीक्षा करनी चाहिए और वे 425 प्राप्त कर सकते हैं। एक क्लाइंट जिसे 425 प्राप्त होता है, वह केवल हैंडशेक के बाद ही रीट्राई करता है; गेटवे सिग्नल को बनाए रखते हैं, प्रत्येक रेप्लिका समान नीति लागू करता है, और आइडेम्पोटेंसी कीज़ प्लस सर्वर-साइड डिडुप्लिकेशन दोहराए गए अनुरोधों की रक्षा करते हैं।"
चरण-दर-चरण उत्तर
चरण 1: अर्ली डेटा और रीप्ले मॉडल की पहचान करें
TLS 1.3 0-RTT एक क्लाइंट को हैंडशेक पूरा होने से पहले एप्लिकेशन डेटा भेजने की अनुमति देता है। एक पूर्ण हैंडशेक केवल आपको उस कनेक्शन के डेटा के बारे में बताता है; यह यह साबित नहीं करता कि किसी अन्य कनेक्शन को समान बाइट्स प्राप्त नहीं हुए थे। इसलिए एक सर्विस किसी सफल कनेक्शन से विशिष्टता (uniqueness) का अनुमान नहीं लगा सकती है।
चरण 2: रिसोर्स साइड इफेक्ट्स को वर्गीकृत करें
ओरिजिन किसी रिसोर्स के लिए रीप्ले के परिणाम को जानता है। रीड्स, क्वेरीज़ और बिना किसी स्थिति परिवर्तन वाले ऑपरेशन्स अक्सर कम जोखिम वाले होते हैं, लेकिन सत्यापित करें कि बिलिंग और ऑडिट पाथ्स में कोई छिपे हुए राइट्स न हों। ऑर्डर बनाना, कार्ड चार्ज करना, क्रेडिट जारी करना, अनुमतियाँ बदलना और संदेश भेजना दो बार निष्पादित हो सकते हैं; हैंडशेक पूरा होने तक उन्हें अस्वीकार करें या टालें।
चरण 3: डिफरल, रिजेक्शन या 0-RTT को अक्षम करने में से चुनें
RFC 8470 TLS पर अर्ली डेटा को अस्वीकार करने, प्रोसेसिंग से पहले हैंडशेक की प्रतीक्षा करने, या 425 लौटाने का वर्णन करता है ताकि क्लाइंट बाद में रीट्राई करे। सभी रीप्ले जोखिम को कम करते हैं; चुनाव रिसोर्स नीति, मेमोरी बजट, क्लाइंट व्यवहार और लोड पर निर्भर करता है। प्रत्येक हैंडशेक विफलता के विकल्प के रूप में 425 का उपयोग न करें।
चरण 4: 425 को सही ढंग से उत्सर्जित करें
जब कोई अनुरोध अर्ली डेटा में आता है या Early-Data: 1 ले जाता है और सुरक्षित रूप से संसाधित नहीं किया जा सकता है, तो ओरिजिन 425 लौटाता है। यह डिफ़ॉल्ट रूप से कैशेबल नहीं है, और इसका पेलोड किसी पहचाने गए रिसोर्स का प्रतिनिधित्व नहीं है। जब क्लाइंट रीट्राई न कर सके या जब अनुरोध अर्ली डेटा न रहा हो, तब 425 उत्सर्जित न करें, क्योंकि रिकवरी असंभव हो सकती है।
चरण 5: क्लाइंट रीट्राई सीमाओं को परिभाषित करें
अर्ली डेटा का उपयोग करने वाले क्लाइंट से 425 के बाद रीट्राई करने की उम्मीद की जाती है, लेकिन रीट्राई में फिर से अर्ली डेटा का उपयोग नहीं होना चाहिए। अनुरोध सिमेंटिक्स को सुरक्षित रखें, प्रयासों को सीमित करें, बैकऑफ़ लागू करें, और रद्दीकरण तथा समय सीमाओं का सम्मान करें। यदि अनुरोध को स्वयं सुरक्षित रूप से रीट्राई नहीं किया जा सकता है, तो अनिश्चित काल तक रीप्ले करने के बजाय कॉलर को विफलता की रिपोर्ट करें।
चरण 6: गेटवे के माध्यम से सिग्नल अग्रेषित करें
एक गेटवे आमतौर पर यह नहीं जान सकता कि कोई विशिष्ट रिसोर्स अर्ली डेटा स्वीकार करता है या नहीं। ऐसे अनुरोध को अग्रेषित करते समय जिसे रीप्ले किया गया हो सकता है, उसे Early-Data: 1 को संरक्षित या जोड़ना होगा; इसे सिग्नल को हटाना नहीं चाहिए। यदि ओरिजिन तंत्र का समर्थन नहीं करता है, तो हैंडशेक की प्रतीक्षा करें या अस्वीकार करें। एक गेटवे क्लाइंट की ओर से केवल तभी रीट्राई कर सकता है जब सुरक्षा स्पष्ट रूप से ज्ञात हो।
चरण 7: रेप्लिकेस को सुसंगत रखें
प्रत्येक ओरिजिन रेप्लिका, एज नोड और एसिंक्रोनस वर्कर को समान अर्ली-डेटा नीति की आवश्यकता होती है। यदि एक रेप्लिका टालती है जबकि दूसरी तुरंत चार्ज करती है, तो एक हमलावर या पाथ का अंतर डुप्लिकेट प्रभाव पैदा कर सकता है। सभी रेप्लिकेस में नीति संस्करण, आइडेम्पोटेंसी की, डिडुप्लिकेशन रिकॉर्ड और देखने योग्य फ़ील्ड्स साझा करें।
चरण 8: रीट्राई और ओवरलोड व्यवहार का परीक्षण करें
एक पूर्ण हैंडशेक, किसी अन्य रेप्लिका पर रीप्ले, हैंडशेक से पहले आंशिक रूप से आने वाला अनुरोध, गेटवे फ़ॉरवर्डिंग, क्लाइंट टाइमआउट और सर्वर ओवरलोड का परीक्षण करें। अर्ली-डेटा दर, 425 दर, रीट्राई, डुप्लिकेट कीज़, डुप्लिकेट प्रभाव और कतार वृद्धि को रिकॉर्ड करें। लोड के तहत, बार-बार 425 या 503 प्रतिक्रियाएं रीट्राई को बढ़ा सकती हैं, इसलिए बजट निर्धारित करें और 0-RTT को विश्व स्तर पर अक्षम करने में सक्षम हों।
ट्रेड-ऑफ़ और सीमाएं
0-RTT रिज़्यूम्ड कनेक्शन्स पर फर्स्ट-बाइट प्रतीक्षा को कम करता है, लेकिन इसके लिए रीप्ले विश्लेषण, सुसंगत नीति और डिडुप्लिकेशन की आवश्यकता होती है। केवल एक मेथड का नाम पर्याप्त नहीं है: एक नाममात्र सुरक्षित मेथड भी बिलिंग, ऑडिट या कैश स्थिति लिख सकता है। रिसोर्स-स्तरीय नीति अधिक विश्वसनीय होती है।
एक आइडेम्पोटेंसी की डुप्लिकेट प्रभावों को कम करती है लेकिन प्रत्येक अनुरोध को अर्ली डेटा के लिए उपयुक्त नहीं बनाती है। डिडुप्लिकेशन स्थिति के लिए एक उपयोगी प्रतिधारण अवधि, क्रॉस-रेप्लिका दृश्यता, और की टकराव, रीट्राई समाप्ति और स्टोरेज विफलता के लिए परिभाषित व्यवहार की आवश्यकता होती है। अपरिवर्तनीय क्रियाओं के लिए, जटिल मुआवजे (compensation) पर निर्भर रहने की तुलना में हैंडशेक की प्रतीक्षा करना अक्सर अधिक स्पष्ट होता है।
रोलआउट योजना और साक्ष्य
प्रत्येक रिसोर्स के लिए एक अर्ली-डेटा नीति पंजीकृत करें: अनुमति दें, टालें, या 425। राइट्स के लिए आइडेम्पोटेंसी कीज़ और डिडुप्लिकेशन जोड़ें, गेटवे को Early-Data का प्रचार करने दें, और ओरिजिन पर कनेक्शन स्थिति, नीति संस्करण और रीट्राई सहसंबंध लॉग करें। एक क्रॉस-रेप्लिका रीप्ले अभ्यास चलाएं और सत्यापित करें कि ऑर्डर, शुल्क और संदेश डुप्लिकेट नहीं होते हैं।
लॉन्च के बाद, रिसोर्स और क्लाइंट संस्करण द्वारा 425, रीट्राई और साइड-इफेक्ट मेट्रिक्स का निरीक्षण करें। यदि क्लाइंट रीट्राई नियमों का उल्लंघन करते हैं, तो ओरिजिन सुरक्षा को कमजोर करने के बजाय क्लाइंट को ठीक करें या एज पर 0-RTT को अक्षम करें। RFC 8470 को सुसंगत गेटवे और ओरिजिन हैंडलिंग की आवश्यकता होती है, इसलिए रिलीज़ जांच में प्रत्येक इनग्रेस पाथ को कवर किया जाना चाहिए।
सामान्य गलतियाँ और फॉलो-अप
425 को रेट लिमिटिंग या ओवरलोड के रूप में मानना
425 संभवतः रीप्ले किए गए अर्ली-डेटा अनुरोध को लक्षित करता है। उच्च समवर्तीता (high concurrency), एक अनुपलब्ध निर्भरता, और एक कोटा उल्लंघन के अलग-अलग सिमेंटिक्स और बैकऑफ़ व्यवहार होते हैं।
प्रत्येक POST के लिए 425 लौटाना
मेथड केवल एक संकेत है। रिसोर्स की रीप्ले सहनशीलता और विश्वसनीय आइडेम्पोटेंसी तथा डिडुप्लिकेशन के आधार पर निर्णय लें। एक प्रमाणित रूप से आइडेम्पोटेंट राइट को टाला जा सकता है या रिसोर्स-विशिष्ट नीति द्वारा नियंत्रित किया जा सकता है।
425 को फिर से 0-RTT के साथ रीट्राई करना
RFC 8470 के लिए आवश्यक है कि 425 के बाद रीट्राई अर्ली डेटा से बचे। अन्यथा क्लाइंट सर्वर की सुरक्षा को दूसरे रीप्ले अवसर में बदल देता है।
गेटवे पर Early-Data हेडर को हटाना
सिग्नल को हटाने से ओरिजिन को यह विश्वास हो जाता है कि अनुरोध अर्ली डेटा से होकर नहीं गुजरा। हेडर को संरक्षित या जोड़ें, 425 के लिए ओरिजिन समर्थन को सत्यापित करें, और अनिश्चित होने पर हैंडशेक की प्रतीक्षा करें।
आप कैसे साबित करेंगे कि कोई डुप्लिकेट चार्ज नहीं था?
क्रॉस-रेप्लिका आइडेम्पोटेंसी की, अनुरोध फ़िंगरप्रिंट और चार्ज स्टेट मशीन के साथ एक रीप्ले अभ्यास चलाएं, फिर प्रति ऑपरेशन एक अंतिम व्यावसायिक परिणाम सत्यापित करें। डिडुप्लिकेशन-स्टोर विफलता, टाइमआउट के बाद क्लाइंट रीट्राई और डुप्लिकेट डाउनस्ट्रीम डिलीवरी का भी परीक्षण करें; अकेले एक HTTP स्टेटस कोड प्रमाण नहीं है।