General Interview: HTTP 425 Too Early और 0-RTT Replay Safety को समझाइए

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

यह HTTP और सुरक्षा बुनियादी सिद्धांतों का प्रश्न बैकएंड, प्लेटफॉर्म, SRE और इंफ्रास्ट्रक्चर भूमिकाओं के लिए उपयुक्त है। परिदृश्य यह है कि एक TLS 1.3 0-RTT अनुरोध गेटवे तक पहुंचता है: early data हैंडशेक की प्रतीक्षा को कम करता है लेकिन इसे रीप्ले किया जा सकता है। एक मजबूत उत्तर 425 semantics, व्यावसायिक idempotency और hop-by-hop नीति को आपस में जोड़ता है।

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

• 0-RTT के प्रदर्शन लाभ और रीप्ले जोखिम की समझ।
• 425, 429, 503 और 408 के बीच सटीक सीमाएं।
• साइड इफेक्ट्स के लिए idempotency keys, deduplication ledgers और स्टेटस लुकअप का उपयोग।
• गेटवे, ऑरिजिन और इंस्टेंस के बीच सुसंगत early-data नीति।

स्पष्टीकरण वाले प्रश्न

पहले पुष्टि करें कि early data का कोई प्रमाण है या नहीं, क्या ऑपरेशन में साइड इफेक्ट्स हैं, क्या गेटवे Early-Data को सुरक्षित रखता है, और क्या क्लाइंट पूर्ण हैंडशेक के बाद पुनः प्रयास कर सकता है। फिर idempotency keys, विशिष्टता बाधाओं (uniqueness constraints), deduplication रिकॉर्ड और इंस्टेंस के बीच साझा स्थिति के बारे में पूछें। एक GET में भी व्यावसायिक साइड इफेक्ट्स हो सकते हैं, इसलिए केवल मेथड का नाम सुरक्षा का प्रमाण नहीं है।

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

TLS 1.3 0-RTT क्लाइंट को हैंडशेक समाप्त होने से पहले early data भेजने की अनुमति देता है, लेकिन उस डेटा को रीप्ले किया जा सकता है। यदि किसी अनुरोध को प्रोसेस करना सुरक्षित सिद्ध नहीं होता है, तो सर्वर 425 Too Early लौटाता है और क्लाइंट से हैंडशेक के बाद पुनः प्रयास करने के लिए कहता है; इस पुनः प्रयास में फिर से early data का उपयोग नहीं होना चाहिए। Early data को केवल रीप्ले-सुरक्षित, deduplication वाले idempotent ऑपरेशन्स के लिए ही स्वीकार करें। गेटवे और ऑरिजिन को Early-Data: 1 पर सहमत होना चाहिए, साथ ही रीट्राई एम्प्लीफिकेशन की निगरानी करनी चाहिए।

चरण-दर-चरण विस्तृत विश्लेषण

1. जोखिम बताएं। 0-RTT early data अभी भी एन्क्रिप्टेड है, लेकिन कोई हमलावर वैध अनुरोध को कॉपी करके रीप्ले कर सकता है। मुख्य जोखिम डुप्लिकेट साइड इफेक्ट्स का है, गोपनीयता की प्रत्यक्ष हानि नहीं।
2. 425 को परिभाषित करें। जब early-data चरण के दौरान प्रोसेसिंग असुरक्षित हो तो 425 लौटाएं। सर्वर को early data के प्रमाण के बिना 425 उत्सर्जित नहीं करना चाहिए; यह रिस्पॉन्स डिफ़ॉल्ट रूप से कैश करने योग्य नहीं है।
3. ऑपरेशन्स को वर्गीकृत करें। पढ़ने (reads) के लिए भी वास्तविक साइड इफेक्ट्स की जांच करें। भुगतान, शिपमेंट और कोटा परिवर्तनों को सामान्यतः पूर्ण हैंडशेक की प्रतीक्षा करनी चाहिए। यदि early data स्वीकार किया जाता है, तो idempotency key, विशिष्टता बाधा, या deduplication ledger की आवश्यकता रखें।
4. पुनः प्रयास (retry) निर्दिष्ट करें। एक क्लाइंट जिसने early data भेजा है, वह पूर्ण हैंडशेक के बाद पुनः प्रयास करता है, और यह पुनः प्रयास early data के रूप में नहीं भेजा जाना चाहिए। पुनः प्रयास की संख्या और कुल समय को सीमित करें।
5. हॉप्स को सुसंगत रखें। एक विश्वसनीय मध्यस्थ Early-Data: 1 को जोड़ या अग्रेषित कर सकता है। गेटवे, लोड बैलेंसर और ऑरिजिन को समान विश्वास सीमा की आवश्यकता होती है; अन्यथा एक इंस्टेंस प्रतीक्षा कर सकता है जबकि दूसरा साइड इफेक्ट निष्पादित कर देता है।
6. एम्प्लीफिकेशन को नियंत्रित करें। ओवरलोड के दौरान, 425 रिस्पॉन्स और हैंडशेक पुनः प्रयास ट्रैफ़िक को बढ़ा सकते हैं। Early-data आकार और समवर्तीता को सीमित करें, और 425 अनुपात, रीट्राई दर, डुप्लिकेट व्यावसायिक कुंजियों और हैंडशेक लेटेंसी की निगरानी करें।

मॉडल उत्तर

मैं Early-Data: 1 को रीप्ले-जोखिम सिग्नल के रूप में मानूंगा, न कि एक सामान्य पुष्ट अनुरोध के रूप में:

POST /payments HTTP/1.1
Early-Data: 1
Idempotency-Key: pay-123

यदि भुगतान ऑपरेशन रीप्ले-सुरक्षित साबित नहीं होता है, तो मैं 425 Too Early लौटाता हूं और क्लाइंट से उसी idempotency key के साथ पुनः प्रयास करने से पहले TLS हैंडशेक पूरा करवाता हूं; पुनः प्रयास में दोबारा early data का उपयोग नहीं होना चाहिए। रीप्ले-सुरक्षित ऑपरेशन के लिए भी, मैं डुप्लिकेट निष्पादन को रोकने के लिए विशिष्टता बाधा या deduplication ledger का उपयोग करता हूं। 425 दर सीमित करने (429), व्यापक अस्थायी अनुपलब्धता (503), या क्लाइंट टाइमआउट (408) के समान नहीं है। गेटवे और ऑरिजिन एक ही नीति साझा करते हैं और अनुरोध आईडी, early-data मार्कर, रीट्राई गणना और डुप्लिकेट कुंजियों को लॉग करते हैं ताकि पुनः प्रयास ओवरलोड को न बढ़ाएं।

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

• यह कहना कि "0-RTT एन्क्रिप्टेड नहीं है" → TLS अभी भी इसे एन्क्रिप्ट करता है → जोखिम रीप्ले का है।
• 425 के बाद 0-RTT को बिना बदलाव के फिर से भेजना → जोखिम बना रहता है → पूर्ण हैंडशेक के बाद पुनः प्रयास करें।
• प्रत्येक POST के लिए 425 लौटाना → कुछ राइट्स में विश्वसनीय deduplication होता है → साइड इफेक्ट्स और साक्ष्य का आकलन करें।
• 425 को 429 की तरह मानना → 425 early data को संभालता है, जबकि 429 दर सीमा को दर्शाता है → अलग बैकऑफ़ और अलर्ट का उपयोग करें।
• केवल गेटवे पर जांच करना → ऑरिजिन असंगत रूप से निष्पादित हो सकते हैं → विश्वास सीमाओं और स्थिति को साझा करें।

फॉलो-अप प्रश्न

आप 425 को 503 से कैसे अलग करते हैं?

425 early-data चरण के दौरान रीप्ले जोखिम को संबोधित करता है; 503 का अर्थ है कि सेवा अस्थायी रूप से अनुरोध को संभालने में असमर्थ है। 425 केवल तभी चुनें जब early-data का प्रमाण मौजूद हो और नीति के अनुसार हैंडशेक की प्रतीक्षा करना आवश्यक हो।

केवल GET की अनुमति क्यों नहीं दी जाती?

HTTP मेथड के नाम व्यावसायिक साइड इफेक्ट्स न होने की गारंटी नहीं देते हैं। कुछ GET अनुरोध काउंटर्स, प्रीफेच या स्थिति परिवर्तनों को ट्रिगर करते हैं, इसलिए वास्तविक प्रभावों और deduplication का मूल्यांकन करें।

गेटवे को early-data जानकारी कैसे पास करनी चाहिए?

एक विश्वसनीय मध्यस्थ Early-Data: 1 जोड़ या अग्रेषित कर सकता है, लेकिन इसे अविश्वसनीय क्लाइंट्स को सिग्नल में हेरफेर करने से रोकना चाहिए और ऑरिजिन को बताना चाहिए कि मार्कर कहाँ से आया और कौन सी नीति लागू होती है।

आप कैसे साबित करते हैं कि कोई चार्ज दो बार नहीं हो सकता?

यूनिक इन्सर्ट या deduplication ledger के लिए समान idempotency key का उपयोग करें, अंतिम स्थिति रिकॉर्ड करें, पुनः प्रयास करने से पहले क्वेरी करें, और बाद में भुगतान घटनाओं का व्यावसायिक ऑर्डर के साथ मिलान करें।