1. प्रश्न और संदर्भ
एक लॉन्ग-लिव्ड क्लाइंट NAT, लोड बैलेंसर और सर्वर के माध्यम से कनेक्ट होता है। नेटवर्क टूटने के बाद भी, ऑपरेटिंग सिस्टम सॉकेट को स्थापित (established) के रूप में रिपोर्ट करता है। टीम इस बात पर बहस करती है कि क्या केवल TCP Keepalive ही पर्याप्त है या प्रोटोकॉल में ping/pong मैसेज जोड़े जाने चाहिए। दोनों मैकेनिज्म की तुलना करें और डिटेक्शन, टाइमआउट, प्रॉक्सी और रीकनेक्ट व्यवहार का प्रस्ताव दें। मान लें कि बिज़नेस को यह जानने की आवश्यकता है कि क्या सेशन अभी भी अनुरोधों को प्रोसेस कर सकता है, न कि केवल यह कि नेटवर्क इंटरफ़ेस पहुंच योग्य (reachable) है या नहीं।
2. इंटरव्यूअर क्या टेस्ट कर रहा है
- क्या आप ट्रांसपोर्ट प्रोबिंग और एप्लिकेशन-उपलब्धता प्रोबिंग के बीच अंतर कर पाते हैं।
- क्या आप जानते हैं कि TCP Keepalive कर्नेल टाइमर का उपयोग करता है, इसलिए डिफॉल्ट्स और मिडलबॉक्स व्यवहार कोई बिज़नेस SLA नहीं हैं।
- क्या आप बिना किसी फॉल्स पॉजिटिव या स्टॉर्म के एक बाउंडेड हार्टबीट, टाइमआउट, क्लोज़ और रीकनेक्ट स्टेट मशीन डिज़ाइन कर सकते हैं।
- क्या आप एंड-टू-एंड डिज़ाइन में NAT, प्रॉक्सी आइडल टाइमआउट, मोबाइल नेटवर्क और सर्वर लोड को शामिल करते हैं।
3. पहले पूछे जाने वाले स्पष्टीकरण प्रश्न
- क्या हमें नेटवर्क पाथ, TCP पीयर प्रोसेस, या एप्लिकेशन-सेशन उपलब्धता का पता लगाने की आवश्यकता है?
- NAT, गेटवे और लोड बैलेंसर पर कौन सा आइडल टाइमआउट लागू होता है?
- क्या कनेक्शन में रिप्ले करने योग्य रीड्स शामिल हैं, या ऐसे कमांड्स और ट्रांज़ैक्शन हैं जिनके लिए कन्फर्मेशन की आवश्यकता होती है?
- कितने क्लाइंट हैं, कितना अतिरिक्त बैंडविड्थ स्वीकार्य है, और कितने रीकनेक्ट एक साथ (concurrently) चल सकते हैं?
4. 30-सेकंड का उत्तर ढांचा
TCP Keepalive कर्नेल द्वारा भेजा जाता है और यह मुख्य रूप से एक आइडल हाफ-ओपन TCP पीयर या टूटे हुए पाथ की पहचान करता है। एप्लिकेशन हार्टबीट प्रोटोकॉल द्वारा परिभाषित होती है और यह सत्यापित कर सकती है कि पीयर एप्लिकेशन अभी भी रीड, राइट कर रही है और बिज़नेस एक्नॉलेजमेंट लौटा रही है। मैं healthy, suspect, closed और backoff स्टेट्स को परिभाषित करूँगा, फिर सबसे छोटे मिडलबॉक्स आइडल टाइमआउट से हार्टबीट अंतराल सेट करूँगा। Keepalive ट्रांसपोर्ट फॉलबैक है; एप्लिकेशन हार्टबीट के पास बिज़नेस SLA का स्वामित्व होता है। टाइमआउट होने पर, पुराने सॉकेट को बंद करें, जिटर वाले एक्सपोनेंशियल बैकऑफ़ के साथ रीकनेक्ट करें और कन्करेंसी को सीमित करें।
5. चरण-दर-चरण गहन उत्तर
स्टेप 1: परिभाषित करें कि प्रत्येक मैकेनिज्म क्या देखता है
TCP Keepalive सॉकेट लेयर पर काम करता है। लिनक्स tcp(7) एक आइडल अवधि, प्रोब अंतराल और प्रोब काउंट को एक्सपोज़ करता है; एक ACK केवल यह साबित करता है कि TCP स्टैक उत्तर दे सकता है। यह यह साबित नहीं करता है कि एप्लिकेशन प्रमाणित है, इसका लीज वैध है, या यह किसी अनुरोध को प्रोसेस कर सकता है। Keepalive शांत हाफ-ओपन कनेक्शनों को खोजने और कर्नेल संसाधनों को रिलीज़ करने के लिए उपयोगी है।
एप्लिकेशन हार्टबीट एक प्रोटोकॉल मैसेज है, जैसे सत्र या क्षमता डेटा ले जाने वाला ping, जिसका उत्तर pong या स्टेटफुल रिस्पॉन्स द्वारा दिया जाता है। यह एक ब्लॉक किए गए इवेंट लूप, एक्सपायर्ड लीज, अमान्य प्रमाणीकरण, या ओवरलोड सर्विस का पता लगा सकता है जिसे TCP नहीं देख सकता है। इसमें एप्लिकेशन CPU, बैंडविड्थ और कनेक्शन क्षमता की लागत आती है।
स्टेप 2: एंड-टू-एंड टाइम बजट से पैरामीटर सेट करें
सबसे छोटा मिडलबॉक्स आइडल टाइमआउट T_idle खोजें, फिर जिटर मार्जिन के साथ इसके नीचे एक हार्टबीट अंतराल चुनें, उदाहरण के लिए T_hb <= T_idle / 2। एप्लिकेशन रिस्पॉन्स की समय सीमा को बिज़नेस द्वारा अनुमत डिस्कनेक्ट किए गए समय से कम रखें; डाउन घोषित करने से पहले N लगातार विफलताओं की आवश्यकता रखें ताकि एक ड्रॉप हुआ पैकेट एक स्वस्थ सेशन को समाप्त न करे। TCP Keepalive एप्लिकेशन के शांत रहने के दौरान ट्रांसपोर्ट फॉलबैक के रूप में एक लंबी आइडल अवधि का उपयोग कर सकता है; यह एप्लिकेशन SLA को प्रतिस्थापित नहीं कर सकता है।
स्टेप 3: स्टेट्स और एक्शन्स डिज़ाइन करें
कनेक्ट होने के बाद, healthy में प्रवेश करें। हार्टबीट भेजने पर यह suspect पर चला जाता है; समय सीमा से पहले एक एप्लिकेशन प्रतिक्रिया मिलने पर यह वापस healthy पर आ जाता है। लगातार विफलताएं सॉकेट को बंद कर देती हैं और backoff में प्रवेश करती हैं। रैंडम जिटर और एक कैप के साथ एक्सपोनेंशियल ग्रोथ का उपयोग करें; ऑफ़लाइन होने पर या पेज छिपे होने पर डायलिंग रोकें, फिर फिर से शुरू करने से पहले एक हेल्थ चेक चलाएं। पहले पुराने सॉकेट को बंद करें ताकि दो कनेक्शन एक कमांड स्ट्रीम का उपभोग न कर सकें।
स्टेप 4: मैसेज सिमेंटिक्स के अनुसार रिकवर करें
नोटिफिकेशन्स को ड्रॉप किया जा सकता है और रीकनेक्ट के बाद फिर से सब्सक्राइब किया जा सकता है। एक राइट कमांड को हार्टबीट एक्नॉलेजमेंट पर निर्भर नहीं होना चाहिए: एक इडेम्पोटेंसी की या सीक्वेंस नंबर संलग्न करें, एक स्पष्ट पुष्टि प्राप्त करें, और अंतिम सन्निहित (contiguous) पुष्टिकरण बिंदु रिकॉर्ड करें। रीकनेक्ट के बाद, कर्सर से रिप्ले करें या स्थिति के लिए क्वेरी करें। यदि निष्पादन अनिश्चित है, तो यह तय करने से पहले कि पुनः प्रयास करना है या नहीं, सर्वर स्थिति को पढ़ें।
स्टेप 5: मिडलबॉक्स और ऑपरेशनल सिग्नल्स सत्यापित करें
यह पुष्टि करने के लिए पैकेट कैप्चर या कनेक्शन लॉग का उपयोग करें कि हार्टबीट NAT, प्रॉक्सी और लोड बैलेंसर को पार करती हैं। हार्टबीट RTT, टाइमआउट दर, विफल Keepalive प्रोब्स, कनेक्शन आयु, रीकनेक्ट प्रयास, बैकऑफ़ अवधि और कन्करेंसी पीक्स रिकॉर्ड करें। अनप्लग किए गए नेटवर्क, NAT रिक्लेमेशन, एक ब्लॉक किया गया सर्वर इवेंट लूप, एक्सपायर हो चुके ऑथेंटिकेशन और एक सिंक्रनाइज़ डिस्कनेक्ट का अभ्यास करें। केवल एक ESTABLISHED TCP स्थिति बिज़नेस उपलब्धता को साबित नहीं करती है।
6. उच्च-गुणवत्ता वाला नमूना उत्तर
मैं दोनों तंत्रों को लेयर के अनुसार अलग करता हूँ। TCP Keepalive एक कर्नेल प्रोब है जो एक शांत हाफ-ओपन TCP कनेक्शन को खोज सकता है, लेकिन एक ACK का मतलब यह नहीं है कि एप्लिकेशन किसी अनुरोध को प्रोसेस कर सकता है। एक एप्लिकेशन हार्टबीट प्रोटोकॉल, ऑथेंटिकेशन और लीज हेल्थ को सत्यापित कर सकता है, इसलिए बिज़नेस निर्णय का स्वामित्व इसके पास होता है। मैं सबसे छोटे NAT या लोड-बैलेंसर आइडल टाइमआउट को मापता हूँ, हार्टबीट को इसके लगभग आधे पर सेट करता हूँ, और एक रिस्पॉन्स डेडलाइन और लगातार-विफलता सीमा जोड़ता हूँ। एक कनेक्शन स्टेट मशीन healthy, suspect, closed और जिटर वाले backoff के बीच चलती है; टाइमआउट रीकनेक्ट करने से पहले पुराने सॉकेट को बंद कर देता है। रिकवरी के बाद नोटिफिकेशन्स फिर से सब्सक्राइब हो जाते हैं, जबकि कमांड्स इडेम्पोटेंसी कीज़ और कन्फर्मेशन कर्सर का उपयोग करते हैं। Keepalive एप्लिकेशन के शांत रहने के दौरान एक फॉलबैक है, न कि हार्टबीट या असीमित रीट्राई लूप का विकल्प।
7. सामान्य गलतियाँ
- TCP ACK को बिज़नेस हेल्थ के प्रमाण के रूप में मानना → कर्नेल उत्तर दे सकता है जबकि एप्लिकेशन थ्रेड अटका हुआ है → एप्लिकेशन रिक्वेस्ट-रिस्पॉन्स हार्टबीट का उपयोग करें।
- सिस्टम Keepalive डिफॉल्ट्स को बिना बदलाव के अपनाना → आइडल अवधि प्रॉक्सी टाइमआउट से अधिक हो सकती है → एंड-टू-एंड टाइम बजट से कॉन्फ़िगर करें।
- एक छूटी हुई हार्टबीट के बाद रीकनेक्ट करना → थोड़ा सा पैकेट लॉस एक स्टॉर्म पैदा करता है → डेडलाइन, लगातार-विफलता सीमा और जिटर वाले बैकऑफ़ का उपयोग करें।
- केवल क्लाइंट हार्टबीट को ट्यून करना → एक NAT या लोड बैलेंसर अभी भी पहले पुनः प्राप्त कर सकता है → प्रत्येक मिडलबॉक्स का निरीक्षण करें।
- रीकनेक्ट के बाद राइट कमांड्स को आँख मूंदकर रिप्ले करना → दो बार चार्ज करता है या संसाधन बनाता है → इडेम्पोटेंसी कीज़, कन्फर्मेशन पॉइंट्स और स्टेट रीड्स का उपयोग करें।
8. फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: यदि एप्लिकेशन हार्टबीट अधिक मजबूत है, तो TCP Keepalive को क्यों बनाए रखें?
एप्लिकेशन लंबे समय तक शांत रह सकता है या इसका प्रोटोकॉल कोड टूट सकता है। Keepalive उस शांति के दौरान एक मृत ट्रांसपोर्ट का पता लगा सकता है और सॉकेट को रिलीज़ कर सकता है। यह एक निचली-लेयर का फॉलबैक है, कोई बिज़नेस एक्नॉलेजमेंट नहीं।
फॉलो-अप 2: क्या हार्टबीट अंतराल यथासंभव छोटा होना चाहिए?
नहीं। छोटे अंतराल विफलताओं का तेजी से पता लगाते हैं लेकिन अधिक CPU, बैंडविड्थ, मोबाइल बैटरी और सर्वर कन्करेंसी की खपत करते हैं। पहले मिडलबॉक्स आइडल बजट को पूरा करें, फिर विभिन्न कनेक्शन प्रकारों के लिए स्तरों (tiers) के साथ, फॉल्स पॉजिटिव और डिटेक्शन डिले को मापने के लिए फॉल्ट ड्रिल का उपयोग करें।
फॉलो-अप 3: फ्लीट-व्यापी रीस्टार्ट के बाद आप रीकनेक्ट स्टॉर्म से कैसे बचते हैं?
क्लाइंट रैंडम जिटर के साथ एक्सपोनेंशियल बैकऑफ़ का उपयोग करते हैं। सर्वर किरायेदार (tenant) या कनेक्शन प्रकार द्वारा दर सीमित (rate-limit) करता है और पुनः प्रयास का समय प्रदान कर सकता है। ऑफ़लाइन क्लाइंट डायलिंग बंद कर देते हैं; जब कनेक्टिविटी वापस आती है, तो वे बैचों में रीकनेक्ट होते हैं और निगरानी के लिए पीक को प्रदर्शित करते हैं।