TCP कनेक्शन लाइफसाइकल: हैंडशेक, टियरडाउन, और TIME_WAIT

प्रश्न और दायरा

एक Linux API क्लाइंट कनेक्शनों को फिर से उपयोग (reuse) नहीं करता है और एक अपस्ट्रीम पर प्रति सेकंड 5,000 शॉर्ट TCP कनेक्शन खोलता है। इसके बाद यह कनेक्शन टाइमआउट और बड़ी संख्या में TIME_WAIT की रिपोर्ट करता है। समझाएं कि TCP कैसे खुलता और बंद होता है, कौन सा एंडपॉइंट TIME_WAIT में प्रवेश करता है, यह स्टेट क्यों मौजूद है, और आप इस घटना का निदान और समाधान कैसे करेंगे।

स्पष्ट बेसलाइन मान्यताओं का उपयोग करें। क्लाइंट के पास एक सोर्स IP है, और अपस्ट्रीम IP तथा पोर्ट निश्चित हैं। इफेमरल-पोर्ट रेंज Linux-डॉक्युमेंटेड डिफॉल्ट 32768–60999 है, जिसमें कोई रिज़र्व पोर्ट नहीं हैं। एक पैकेट कैप्चर दिखाता है कि क्लाइंट पहला FIN भेजता है, और देखे गए TIME_WAIT एंट्रीज लगभग 60 सेकंड तक रहती हैं। अंतिम दो तथ्य परिदृश्य द्वारा प्रदान किए गए साक्ष्य हैं, कोई सार्वभौमिक ऑपरेटिंग-सिस्टम स्थिरांक (constants) नहीं।

यह प्रश्न बैकएंड, इंफ्रास्ट्रक्चर, SRE, क्लाइंट और सामान्य सॉफ्टवेयर इंजीनियरिंग साक्षात्कारों के लिए उपयुक्त है। वास्तविक कार्य "थ्री-वे हैंडशेक और फोर-वे टियरडाउन" को रटना नहीं है। इसका उद्देश्य TCP स्टेट्स, 4-टपल क्षमता और पैकेट साक्ष्यों का उपयोग करके सामान्य क्लीनअप को इफेमरल-पोर्ट समाप्ति (exhaustion), पैकेट लॉस और अपस्ट्रीम ओवरलोड से अलग करना है।

इंटरव्यूअर क्या जांच रहा है

पहला, क्या उम्मीदवार यह समझा सकता है कि हैंडशेक दोनों इनिशियल सीक्वेंस नंबरों को सिंक्रोनाइज़ करता है? एक SYN एक सीक्वेंस नंबर की खपत करता है, और एकनॉलेजमेंट अपेक्षित अगले सीक्वेंस नंबर की पहचान करता है। तीसरा मैसेज पुष्टि करता है कि आरंभकर्ता (initiator) को पीयर का इनिशियल सीक्वेंस नंबर प्राप्त हो गया है। इस उद्देश्य के बिना केवल SYN, SYN+ACK, और ACK सूचीबद्ध करना अधूरा है।

दूसरा, क्या उम्मीदवार फुल-डुप्लेक्स क्लोज़ सेमांटिक्स को स्टेट्स के साथ मैप कर सकता है? दोनों दिशाएं स्वतंत्र रूप से भेजना बंद कर सकती हैं, इसलिए एक सामान्य क्लोज़ को आमतौर पर FIN → ACK → FIN → ACK के रूप में दिखाया जाता है। एक ACK को FIN के साथ जोड़ा जा सकता है, इसलिए कैप्चर में हमेशा चार अलग-अलग पैकेट नहीं होते हैं। एक मजबूत उत्तर बताता है कि FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, LAST-ACK, और TIME-WAIT किसका इंतज़ार कर रहे हैं।

तीसरा, क्या उम्मीदवार TIME_WAIT के मालिक की पहचान कर सकता है? यह आमतौर पर वह एंडपॉइंट होता है जो एक्टिव रूप से क्लोज़ करता है और अंतिम ACK भेजता है। वह एंडपॉइंट क्लाइंट या सर्वर हो सकता है। यदि दोनों एंडपॉइंट एक ही समय में एक्टिव रूप से क्लोज़ करते हैं, तो दोनों TIME_WAIT में प्रवेश कर सकते हैं। केवल क्लाइंट और सर्वर लेबल स्टेट तय नहीं करते हैं।

चौथा, क्या उम्मीदवार प्रत्येक बड़ी संख्या में TIME_WAIT काउंट को विफलता के रूप में निदान करने से बच सकता है? कई शॉर्ट कनेक्शन स्वाभाविक रूप से कई एंट्रीज उत्पन्न करते हैं। पोर्ट समाप्ति के लिए टपल आपूर्ति, कनेक्शन निर्माण दर, एरर व्यवहार और पैकेट साक्ष्य के बीच संबंध की आवश्यकता होती है।

पांचवां, क्या उम्मीदवार जोखिम के बढ़ते क्रम में समाधान प्रस्तावित कर सकता है? सबसे पहले कनेक्शन निर्माण को कम करें, इसके बाद क्षमता और नेटवर्क पाथ का निरीक्षण करें, और कर्नेल सेटिंग्स पर सबसे अंत में विचार करें। स्टेट्स को ट्रंकेट करना, बकेट लिमिट को कम करना, या सामान्य क्लोज़ को बायपास करने के लिए RST का उपयोग करना एक स्पष्ट क्षमता समस्या को रुक-रुक कर होने वाली शुद्धता विफलताओं (intermittent correctness failures) में बदल सकता है।

पहले स्पष्ट करने योग्य प्रश्न

• कौन सा एंडपॉइंट एक्टिव रूप से क्लोज़ करता है? जो एंडपॉइंट पहला FIN भेजता है वह सामान्य रूप से एक्टिव-क्लोज़ पाथ का अनुसरण करता है। यदि अपस्ट्रीम पहले क्लोज़ करता है, तो क्लाइंट-साइड TIME_WAIT को दूसरे स्पष्टीकरण की आवश्यकता होती है।
• एरर डेटा में “कनेक्शन टाइमआउट” का क्या अर्थ है? लोकल पोर्ट आवंटन EADDRNOTAVAIL जैसी एरर्स के साथ तुरंत विफल हो सकता है। एक कनेक्शन जो SYN-SENT में रहता है और पुनः प्रेषित (retransmit) करता है, वह पाथ, फ़िल्टर, लिसन बैकलॉग दबाव, या गैर-उत्तरदायी अपस्ट्रीम की ओर अधिक संकेत करता है। एरर का प्रकार और अवधि जांच की दिशा बदल देते हैं।
• क्या प्रोटोकॉल कनेक्शनों का पुनः उपयोग कर सकता है? HTTP keep-alive, कनेक्शन पूल, HTTP/2 मल्टीप्लेक्सिंग, या कोई अन्य परसिस्टेंट ट्रांसपोर्ट अधिकांश हैंडशेक और क्लोज़ को समाप्त कर सकता है। क्षमता विस्तार केवल तभी प्रासंगिक होता है जब प्रति-कनेक्शन-एक-अनुरोध व्यवहार की वास्तव में आवश्यकता हो।
• पोर्ट की कमी कहाँ है? होस्ट के पास एक इफेमरल-पोर्ट रेंज होती है। एक NAT, प्रॉक्सी, या लोड बैलेंसर का अपना पब्लिक-एड्रेस और पोर्ट मैपिंग पूल होता है। होस्ट पर खाली पोर्ट होने से यह साबित नहीं होता कि इग्रेस डिवाइस में खाली टपल मौजूद हैं।
• क्या डेस्टिनेशन निश्चित है? एक TCP कनेक्शन की पहचान सोर्स एड्रेस, सोर्स पोर्ट, डेस्टिनेशन एड्रेस, और डेस्टिनेशन पोर्ट द्वारा की जाती है। विभिन्न डेस्टिनेशन्स के लिए समान लोकल पोर्ट का उपयोग किया जा सकता है, इसलिए मशीन-व्यापी कनेक्शन कुल की तुलना में एक अपस्ट्रीम पर एकाग्रता अधिक मायने रखती है।
• लाइव सिस्टम कॉन्फ़िगरेशन क्या है? पोर्ट रेंज, रिज़र्व पोर्ट, TCP टाइमस्टैम्प, रीयूज़ पॉलिसी और कर्नेल संस्करण क्षमता को प्रभावित करते हैं। परिदृश्य के डिफॉल्ट एक प्रारंभिक अनुमान का समर्थन करते हैं, जबकि प्रोडक्शन निष्कर्ष के लिए वास्तविक मानों को पढ़ने की आवश्यकता होती है।

30-सेकंड उत्तर रूपरेखा

"थ्री-वे हैंडशेक दोनों इनिशियल सीक्वेंस नंबरों का आदान-प्रदान और पुष्टि करता है। क्लाइंट SYN भेजता है, सर्वर का SYN+ACK क्लाइंट के नंबर को एकनॉलेज करता है और अपना स्वयं का नंबर प्रदान करता है, और क्लाइंट उस नंबर को ACK करता है। एक सामान्य क्लोज़ में दो स्वतंत्र दिशाएं होती हैं, इसलिए यह आमतौर पर FIN, ACK, FIN, ACK होता है। एक्टिव क्लोज़र जो अंतिम ACK भेजता है, वह सामान्यतः TIME_WAIT में प्रवेश करता है ताकि वह पुनः प्रेषित FIN को एकनॉलेज कर सके और पुराने कनेक्शन के विलंबित डुप्लिकेट्स को उसी टपल के नए उपयोग से दूर रख सके।

उच्च TIMEWAIT काउंट स्वचालित रूप से कोई लीक नहीं है। मैं एरर प्रकार, SYN-SENT काउंट, पैकेट कैप्चर और पोर्ट रेंज का निरीक्षण करूंगा। एक सोर्स IP से एक अपस्ट्रीम तक बताई गई डिफॉल्ट रेंज में 28,232 पोर्ट हैं। प्रति सेकंड 5,000 नए कनेक्शनों और TIMEWAIT में देखे गए लगभग 60 सेकंड के साथ, मांग लगभग 300,000 हालिया टपल्स की है, जो आपूर्ति से कहीं अधिक है। मैं पहले पूलिंग या मल्टीप्लेक्सिंग जोड़ूंगा, फिर NAT और टपल क्षमता का निरीक्षण करूंगा, और उसके बाद ही व्यापक रेंज या अधिक सोर्स एड्रेस पर विचार करूंगा। मैं TIMEWAIT को हटाकर या tcptw_reuse को आँख मूंदकर बदलकर शुरुआत नहीं करूंगा।"

चरण-दर-चरण गहन विश्लेषण

चरण 1: सीक्वेंस नंबरों के साथ हैंडशेक समझाएं

मान लें कि क्लाइंट का इनिशियल सीक्वेंस नंबर x है और सर्वर का y है:

एक SYN एक सीक्वेंस नंबर की खपत करता है, यही कारण है कि एकनॉलेजमेंट x+1 या y+1 होता है। एक शुद्ध ACK किसी सीक्वेंस स्पेस की खपत नहीं करता है। हैंडशेक प्रत्येक एंडपॉइंट को पीयर का इनिशियल सीक्वेंस नंबर और इस बात की पुष्टि देता है कि उसका अपना नंबर प्राप्त हो गया था। यह इस संभावना को भी कम करता है कि एक पुराने डुप्लिकेट कनेक्शन अनुरोध को एक नए कनेक्शन के रूप में गलत समझ लिया जाएगा।

केवल दो मैसेजेस के बाद, आरंभकर्ता ने सर्वर की पुष्टि देख ली है, लेकिन सर्वर को यह पुष्टि नहीं मिली है कि क्लाइंट ने सर्वर के इनिशियल सीक्वेंस नंबर को स्वीकार कर लिया है। "यह जांचता है कि नेटवर्क दोनों दिशाओं में काम करता है" एक सटीक समझ नहीं बल्कि एक शॉर्टकट है। TCP एकनॉलेज्ड, पुनः प्रेषित किए जाने योग्य सीक्वेंस स्पेस और साझा कनेक्शन स्टेट स्थापित कर रहा है।

चरण 2: दो स्वतंत्र दिशाओं से टियरडाउन प्राप्त करें

TCP एक फुल-डुप्लेक्स बाइट स्ट्रीम है। भेजने की एक दिशा को बंद करने का अर्थ है "मेरे पास भेजने के लिए और डेटा नहीं है," जबकि वह एंडपॉइंट उस डेटा को प्राप्त करना जारी रख सकता है जिसे पीयर ने भेजना समाप्त नहीं किया है। इसलिए एक सामान्य क्लोज़ दो दिशाओं को समाप्त करता है:

लगातार बना रहने वाला CLOSE-WAIT आमतौर पर यह दर्शाता है कि एप्लिकेशन को पीयर क्लोज़ के बारे में सूचित किया गया था लेकिन उसने अपने सॉकेट को तुरंत बंद नहीं किया। यह TIME_WAIT से भिन्न विफलता है। लगातार FIN-WAIT-2 का अर्थ है कि एक्टिव क्लोज़र के FIN को स्वीकार कर लिया गया था, लेकिन पीयर ने अपना FIN नहीं भेजा है। इन सभी को "वे कनेक्शन जिन्हें रिलीज़ नहीं किया गया" कहने से स्टेट मशीन का नैदानिक मूल्य समाप्त हो जाता है।

चार-संदेश विवरण एक उपयोगी सामान्य मामला है, कोई निश्चित पैकेट संख्या नहीं। बिना किसी शेष डेटा वाला एक पैसिव क्लोज़र अपने ACK और FIN को जोड़ सकता है। समकालिक (Simultaneous) एक्टिव क्लोज़ CLOSING का उपयोग कर सकता है और दोनों एंडपॉइंट्स को TIME-WAIT में छोड़ सकता है।

चरण 3: TIME_WAIT के दो कार्यों की व्याख्या करें

अंतिम ACK भेजने वाला एंडपॉइंट दो मुख्य कारणों से कनेक्शन को तुरंत नहीं भूल सकता है।

पहला, अंतिम ACK खो सकता है। पैसिव क्लोज़र LAST-ACK में बना रहता है और अपने FIN को पुनः प्रेषित करता है। एक एक्टिव क्लोज़र जिसके पास अभी भी TIME_WAIT स्टेट है, उस FIN को फिर से एकनॉलेज कर सकता है। यदि स्टेट तुरंत गायब हो जाती है, तो पुनः प्रेषित FIN को एक RST प्राप्त हो सकता है और सामान्य क्लोज़ अपनी विश्वसनीयता का गुण खो देगा।

दूसरा, पुराने कनेक्शन के विलंबित या डुप्लिकेट सेगमेंट अभी भी नेटवर्क में मौजूद हो सकते हैं। TCP अपने 4-टपल द्वारा एक कनेक्शन की पहचान करता है। यदि वही टपल तुरंत एक नए कनेक्शन को सौंप दिया जाता है, तो एक पुराना सेगमेंट नए सीक्वेंस स्पेस के साथ ओवरलैप हो सकता है। TCP मानक के अनुसार एक एक्टिव रूप से क्लोज़ किए गए कनेक्शन को 2 × MSL के लिए बने रहना आवश्यक है, जिससे पुराने सेगमेंट्स को समाप्त होने का समय मिल सके और पुनः प्रेषित FIN को एकनॉलेज करने की क्षमता बनी रहे। RFC 1337 बताता है कि इस सुरक्षा को जल्दी समाप्त करने से पुराना डेटा स्वीकार होने, डि-सिंक्रोनाइज़ेशन और त्रुटिपूर्ण ACK के खतरे फिर से कैसे उत्पन्न हो सकते हैं।

इसलिए TIME_WAIT एक शुद्धता तंत्र (correctness mechanism) है, मेमोरी लीक का पर्याय नहीं। पहला प्रश्न यह होना चाहिए कि एप्लिकेशन इतने सारे कनेक्शन क्यों बनाता है, क्या टपल आपूर्ति पर्याप्त है, और कौन सा एंडपॉइंट एक्टिव रूप से क्लोज़ करता है—न कि इस काउंट को शून्य कैसे बनाया जाए।

चरण 4: इफेमरल-पोर्ट दबाव का अनुमान लगाएं

Linux-डॉक्युमेंटेड डिफॉल्ट ip_local_port_range मान 32768–60999 है। परिदृश्य की कोई रिज़र्व पोर्ट न होने की धारणा के साथ, ऑटोमैटिक एलोकेशन पूल में शामिल हैं:

60999 - 32768 + 1 = 28232

एक सोर्स IP, एक डेस्टिनेशन IP, और एक डेस्टिनेशन पोर्ट के लिए, लगभग 28,232 सोर्स-पोर्ट स्लॉट होते हैं जब पुराने टपल्स को अभी तक सुरक्षित रूप से पुन: उपयोग नहीं किया जा सकता है। प्रति सेकंड 5,000 नए कनेक्शनों पर, एप्लिकेशन लगभग 5.65 सेकंड में उतने टपल्स बना लेता है:

28232 / 5000 ≈ 5.65 seconds

परिदृश्य लगभग 60 सेकंड की एक प्रेक्षित TIME_WAIT अवधि भी प्रदान करता है। हाल ही में बंद किए गए कनेक्शनों की अनुमानित मांग है:

5000 × 60 = 300000 recent connections

तीन लाख 28,232 से कहीं अधिक है, इसलिए "एक सोर्स IP, एक अपस्ट्रीम, कोई कनेक्शन पुन: उपयोग नहीं" एक स्पष्ट क्षमता जोखिम है। यह साबित नहीं करता कि विफलता ठीक 5.65 सेकंड पर होती है। सुरक्षित कर्नेल रीयूज़, इस्टैब्लिश्ड कनेक्शन, रिज़र्व पोर्ट, कनेक्शन अवधि, और NAT व्यवहार सभी लाइव परिणाम को बदलते हैं। यह अनुमान परिमाण के एक बड़े बेमेल को साबित करता है और जांचकर्ता को बताता है कि आगे कौन से साक्ष्य एकत्र करने हैं।

वही सोर्स पोर्ट विभिन्न डेस्टिनेशन्स के कनेक्शनों की सेवा कर सकता है, इसलिए मशीन-व्यापी नए-कनेक्शन के कुल योग को पोर्ट काउंट द्वारा आँख बंद करके विभाजित नहीं किया जा सकता है। NAT के साथ, दुर्लभ संसाधन डेस्टिनेशन की दिशा में पब्लिक NAT एड्रेस के मैपिंग टपल हो सकते हैं।

चरण 5: स्टेट्स, एरर्स, और पैकेट्स के साथ कारणों को अलग करें

ऐसे साक्ष्यों से शुरुआत करें जो सिस्टम के व्यवहार को नहीं बदलते हैं:

ss -s
ss -Htan state syn-sent | wc -l
ss -Htan state time-wait | wc -l
ss -Htan state close-wait | wc -l
cat /proc/sys/net/ipv4/ip_local_port_range
cat /proc/sys/net/ipv4/ip_local_reserved_ports
sysctl net.ipv4.tcp_tw_reuse

फिर साक्ष्य के आधार पर विभाजित करें:

एक कैप्चर को तीन सवालों के जवाब देने चाहिए: पहला FIN कौन भेजता है, क्या विफल कनेक्शन बिल्कुल SYN उत्सर्जित करता है, और पुनः प्रेषण (retransmission) कहाँ होता है। ss से प्राप्त कुल संख्या पोर्ट समाप्ति को साबित नहीं कर सकती है, और "timeout" शब्द युक्त एक एप्लिकेशन लॉग पैकेट लॉस को साबित नहीं कर सकता है।

चरण 6: जोखिम के बढ़ते क्रम में समाधान करें

पहला समाधान कम कनेक्शन बनाना है। एक कनेक्शन पूल, HTTP keep-alive, HTTP/2 मल्टीप्लेक्सिंग, या अन्य उपयुक्त परसिस्टेंट चैनल कॉन्फ़िगर करें ताकि अनुरोध स्थापित कनेक्शनों को साझा करें। यह हैंडशेक लेटेंसी, CPU, इफेमरल-पोर्ट उपयोग और TIME_WAIT को एक साथ कम करता है, जिससे लक्षण के बजाय कारण का समाधान होता है।

इसके बाद, कनेक्शन लाइफसाइकल को ठीक करें। प्रत्येक अनुरोध के बाद एक स्वस्थ कनेक्शन को एक्टिव रूप से क्लोज़ न करें। पूल को सीमित समवर्तीता (bounded concurrency), एक उचित आइडल टाइमआउट, अधिकतम जीवनकाल, और अपस्ट्रीम समवर्तीता सीमाएं दें। यदि सर्वर बहुत आक्रामक रूप से क्लोज़ करता है, तो इसकी keep-alive सेटिंग्स, लोड-बैलेंसर आइडल टाइमआउट और डिप्लॉयमेंट व्यवहार का निरीक्षण करें। लक्ष्य व्यर्थ के कनेक्शन चर्न को हटाना है, न कि केवल एक्टिव क्लोज़ को दूसरे एंडपॉइंट पर ले जाना।

यदि पुन: उपयोग अभी भी अपर्याप्त है, तो टपल आपूर्ति का विस्तार करें। रिज़र्व पोर्ट्स की जांच करने के बाद, व्यापक इफेमरल रेंज का मूल्यांकन करें। सिंगल-डेस्टिनेशन हॉटस्पॉट अधिक सोर्स IP या अधिक डेस्टिनेशन एड्रेस का भी उपयोग कर सकता है। यदि NAT मौजूद है, तो पब्लिक NAT एड्रेस पूल का भी विस्तार या शार्ड करें; ट्रांसलेशन के बाद एप्लिकेशन नेटवर्क के अंदर सोर्स IP जोड़ने का कोई प्रभाव नहीं हो सकता है।

केवल तभी कर्नेल रीयूज़ सेटिंग्स का मूल्यांकन करें। Linux tcp_tw_reuse को केवल तभी TIME_WAIT सॉकेट्स का पुन: उपयोग करने के रूप में डॉक्युमेंट करता है जब प्रोटोकॉल इसे सुरक्षित मानता है और बिना विशेषज्ञ सलाह के इसे बदलने के विरुद्ध चेतावनी देता है। tcp_max_tw_buckets सामान्य डिनायल-ऑफ-सर्विस स्थितियों के विरुद्ध एक रक्षात्मक सीमा है; दस्तावेज़ीकरण स्पष्ट रूप से इसे कृत्रिम रूप से कम न करने के लिए कहता है। इसे पार करने से time-wait सॉकेट्स तुरंत नष्ट हो जाते हैं और एक चेतावनी लॉग होती है। किसी भी बदलाव के लिए कर्नेल-संस्करण, टाइमस्टैम्प, पीयर-व्यवहार, लोड-टेस्ट और रोलबैक साक्ष्य की आवश्यकता होती है।

RST का उपयोग सामान्य अनुकूलन के रूप में न करें। RST कनेक्शन को निरस्त (abort) कर देता है और स्टेट को तुरंत डिस्कार्ड कर देता है; वह डेटा खो सकता है जिसका एप्लिकेशन ने सुरक्षित रूप से हिसाब नहीं रखा है। "सर्वर को पहले क्लोज़ करने दें" भी एक सार्वभौमिक समाधान नहीं है। यह TIME_WAIT दबाव को स्थानांतरित करता है और सर्वर-साइड पोर्ट, मेमोरी, या कनेक्शन-स्टेट दबाव बना सकता है।

चरण 7: समाधान सत्यापित करें

सत्यापन में क्षमता, शुद्धता और नेटवर्क साक्ष्य शामिल होने चाहिए:

1. समान ट्रैफ़िक को फिर से चलाएं और प्रति सेकंड नए TCP कनेक्शन, रीयूज़ अनुपात और अनुरोध थ्रूपुट की तुलना करें।
2. केवल एक समय पर देखने के बजाय समय के साथ SYN-SENT, TIME_WAIT, CLOSE-WAIT, फ़ाइल डिस्क्रिप्टर, और लोकल-पोर्ट उपयोग को ट्रैक करें।
3. यह पुष्टि करने के लिए विफल नमूनों को कैप्चर करें कि क्या SYN बाहर निकलता है, क्या SYN+ACK वापस आता है, और कौन सा एंडपॉइंट एक्टिव रूप से क्लोज़ करता है।
4. क्लाइंट, NAT, लोड बैलेंसर और अपस्ट्रीम ट्रांसपोर्ट मेट्रिक्स का निरीक्षण करें ताकि इग्रेस बाधा छूट न जाए।
5. एक निरंतर परीक्षण चलाएं और ट्रंकेटेड डेटा, उच्च RST काउंट, खराब टेल लेटेंसी, या पुराने पूल्ड कनेक्शनों की जांच करें।

सफलता का अर्थ है कि समान व्यावसायिक थ्रूपुट बहुत कम नए कनेक्शन बनाता है, एरर्स गायब हो जाती हैं, पोर्ट हेडरूम स्थिर रहता है, और अनुरोध की शुद्धता में कोई गिरावट नहीं आती है। कम हुआ TIME_WAIT काउंट उन सुधारों का एक परिणाम है, एकमात्र उद्देश्य नहीं।

मजबूत नमूना उत्तर

"मैं घटना से पहले दो तथ्य स्थापित करूंगा: कौन सा एंडपॉइंट पहला FIN भेजता है, और क्या 'टाइमआउट' का अर्थ तत्काल लोकल एरर है या कोई ऐसा SYN जिसे कोई प्रतिक्रिया नहीं मिलती है। TIME_WAIT सामान्य रूप से एक्टिव क्लोज़र से संबंधित होता है जो अंतिम ACK भेजता है, जबकि कई असंबंधित विफलताएं कनेक्शन टाइमआउट जैसी लग सकती हैं।

इस्टैब्लिशमेंट के दौरान, क्लाइंट इनिशियल सीक्वेंस नंबर x के साथ SYN भेजता है। सर्वर का SYN+ACK x+1 को स्वीकार करता है और अपना स्वयं का नंबर y प्रदान करता है। क्लाइंट फिर y+1 को स्वीकार करता है। दोनों एंडपॉइंट्स ने अब सीक्वेंस स्पेस का आदान-प्रदान और पुष्टि कर ली है, और प्रक्रिया पुराने डुप्लिकेट कनेक्शन प्रयासों को अस्वीकार कर सकती है। टियरडाउन दो भेजने की दिशाओं को स्वतंत्र रूप से बंद करता है, इसलिए सामान्य क्रम FIN, ACK, FIN, ACK है। एक्टिव क्लोज़र FIN-WAIT-1 और FIN-WAIT-2 से गुजरता है, पीयर के FIN को ACK करता है, और TIME_WAIT में प्रवेश करता है। वह स्टेट इसे पुनः प्रेषित FIN को फिर से ACK करने की अनुमति देती है यदि अंतिम ACK खो गया था और पुराने कनेक्शन के विलंबित डुप्लिकेट्स को उसी 4-टपल के तत्काल पुन: उपयोग को दूषित करने से रोकता है।

परिदृश्य की क्षमता संदिग्ध है। पोर्ट 32768 से 60999 तक 28,232 डिफॉल्ट इफेमरल पोर्ट मिलते हैं। एक सोर्स IP उसी डेस्टिनेशन के लिए प्रति सेकंड 5,000 कनेक्शन बनाता है, और देखी गई TIME_WAIT अवधि लगभग 60 सेकंड है, जिसका अर्थ है लगभग 300,000 हालिया क्लोज़—जो पोर्ट स्लॉट से कहीं अधिक हैं। मैं अनुमान पर ही नहीं रुकूंगा। यदि कनेक्ट बिना किसी SYN के लोकल-एड्रेस एरर के साथ तुरंत विफल हो जाता है, तो मैं होस्ट और NAT टपल आपूर्ति की जांच करूंगा। यदि कई सॉकेट्स SYN-SENT में रहते हैं और पुनः प्रेषित होते हैं, तो मैं पाथ, ACL, लिसन बैकलॉग, और अपस्ट्रीम की जांच करूंगा।

मैं नए कनेक्शनों को कम करने के लिए पहले पूलिंग, keep-alive, या HTTP/2 मल्टीप्लेक्सिंग जोड़ूंगा। फिर मैं पूल आइडल टाइमआउट, अपस्ट्रीम क्लोज़ व्यवहार और NAT क्षमता की जांच करूंगा। यदि वर्कलोड को अभी भी उच्च इस्टैब्लिशमेंट दर की आवश्यकता है, तो मैं व्यापक इफेमरल रेंज, अधिक सोर्स एड्रेस, या डेस्टिनेशन वितरण पर विचार करूंगा। tcptwreuse केवल प्रोटोकॉल शर्तों के तहत सुरक्षित है और Linux अनौपचारिक परिवर्तनों के खिलाफ चेतावनी देता है। मैं TIME_WAIT को छोटा करके, बकेट लिमिट को कम करके, या RST क्लोज़ को बाध्य करके शुरुआत नहीं करूंगा। अंत में, मैं समान लोड के तहत नए-कनेक्शन दर, एरर्स, प्रत्येक प्रासंगिक TCP स्टेट, पैकेट कैप्चर और NAT मेट्रिक्स को मान्य करूंगा।"

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

• हैंडशेक को "नमस्ते कहना" के रूप में वर्णित करना → यह सीक्वेंस और एकनॉलेजमेंट सेमांटिक्स को छोड़ देता है और यह नहीं समझा सकता कि दो मैसेज अपर्याप्त क्यों हैं → इसे दोनों इनिशियल सीक्वेंस नंबरों और तीसरे कन्फर्मेशन से प्राप्त करें।
• यह मान लेना कि क्लाइंट हमेशा TIME_WAIT का मालिक होता है → एक्टिव-क्लोज़ भूमिका स्टेट निर्धारित करती है, न कि क्लाइंट लेबल → पहले FIN और अंतिम ACK की पहचान करें।
• टियरडाउन को ठीक चार पैकेट मानना → ACK और FIN संयोजित हो सकते हैं, और समकालिक क्लोज़ मौजूद है → दो स्वतंत्र दिशाओं और उनके स्टेट ट्रांज़िशन का वर्णन करें।
• प्रत्येक बड़ी संख्या में TIME_WAIT काउंट को लीक कहना → शॉर्ट कनेक्शन स्वाभाविक रूप से इस स्टेट को बनाते हैं → निर्माण दर, रेंज, एरर प्रकार और पैकेट साक्ष्य को मिलाएं।
• प्रत्येक कनेक्ट टाइमआउट के लिए पोर्ट समाप्ति को दोष देना → SYN लॉस, ACLs, अपस्ट्रीम ओवरलोड, और लिसन बैकलॉग दबाव भी टाइमआउट कर सकते हैं → तत्काल लोकल विफलता को SYN पुनः प्रेषण से अलग करें।
• पहले tcpmaxtw_buckets को कम करना → सीमा से अधिक होने पर स्टेट जल्दी नष्ट हो जाती है, और Linux स्पष्ट रूप से इसे कृत्रिम रूप से कम करने के खिलाफ चेतावनी देता है → क्षमता का विस्तार करने से पहले चर्न को कम करें।
• सामान्य क्लोज़ के बजाय RST का उपयोग करना → तत्काल स्टेट विलोपन उस डेटा को त्याग सकता है जिसे सुरक्षित रूप से डिलीवर नहीं किया गया था → सामान्य समापन के लिए FIN-आधारित क्लोज़ रखें और वास्तविक निरस्त (aborts) के लिए RST आरक्षित करें।
• केवल एप्लिकेशन की पोर्ट रेंज को चौड़ा करना → वास्तविक सीमा NAT पब्लिक मैपिंग पूल हो सकती है → सोर्स होस्ट, इग्रेस डिवाइस, और अपस्ट्रीम पर टपल क्षमता की जांच करें।

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

फॉलो-अप 1: जब अंतिम ACK खो जाता है तो TIME_WAIT कैसे पुनर्प्राप्त होता है?

पैसिव क्लोज़र अपने FIN की पावती (acknowledgment) की प्रतीक्षा करते हुए LAST-ACK में बना रहता है। यदि अंतिम ACK गायब है, तो यह FIN को फिर से भेजता है। एक्टिव क्लोज़र के पास अभी भी TIME_WAIT स्टेट होती है, वह पुनः प्रेषित FIN को पहचानता है, फिर से ACK भेजता है, और प्रतीक्षा टाइमर को पुनरारंभ करता है। यदि एक्टिव एंडपॉइंट कनेक्शन को भूल गया होता, तो वह FIN एक RST ट्रिगर कर सकता था और विश्वसनीय सामान्य क्लोज़ अब संरक्षित नहीं रहता।

फॉलो-अप 2: एक बड़ा CLOSE_WAIT समूह कैसे भिन्न है?

CLOSE-WAIT का अर्थ है कि पीयर ने FIN भेजा और लोकल TCP स्टैक ने एप्लिकेशन को सूचित किया, लेकिन एप्लिकेशन ने अपनी भेजने की दिशा को बंद नहीं किया है; लोकल एप्लिकेशन अभी भी शेष डेटा भेज सकता है। यह आमतौर पर एप्लिकेशन लाइफसाइकल, एक्सेप्शन हैंडलिंग, या फ़ाइल-डिस्क्रिप्टर प्रबंधन की ओर इशारा करता है। TIME_WAIT का अर्थ है कि एक्टिव क्लोज़र ने आदान-प्रदान पूरा कर लिया है और अंतिम-ACK रिकवरी और पुराने-सेगमेंट अलगाव की रक्षा कर रहा है। दोनों क्लोज़र के दौरान दिखाई देते हैं, लेकिन उनके कारण, शेष डेटा ले जाने की क्षमता और सुधार भिन्न होते हैं।

फॉलो-अप 3: एक सोर्स पोर्ट एकाधिक कनेक्शनों से कैसे संबंधित हो सकता है?

पूर्ण 4-टपल एक कनेक्शन की पहचान करता है। यदि डेस्टिनेशन एड्रेस या डेस्टिनेशन पोर्ट भिन्न है, तो वही लोकल पोर्ट दूसरे कनेक्शन की पहचान कर सकता है। इसलिए इफेमरल-पोर्ट दबाव का विश्लेषण सोर्स IP और डेस्टिनेशन हॉटस्पॉट द्वारा किया जाना चाहिए। कई डेस्टिनेशन्स में फैला ट्रैफ़िक एक पोर्ट रेंज के सुझाव से अधिक कुल कनेक्शनों का समर्थन कर सकता है, जबकि एक अपस्ट्रीम पर एकाग्रता प्रयोग करने योग्य टपल्स को तेजी से समाप्त कर देती है।

फॉलो-अप 4: क्या क्लाइंट को दस इंस्टेंस तक स्केल करने से समाप्ति की समस्या हल हो जाएगी?

ज़रूरी नहीं। स्वतंत्र सोर्स IP होस्ट-साइड टपल आपूर्ति बढ़ाते हैं, लेकिन यदि सभी इंस्टेंस केवल कुछ पब्लिक IP वाले NAT को साझा करते हैं, तो कनेक्शन NAT के मैपिंग पूल में परिवर्तित हो जाते हैं। अपस्ट्रीम सोर्स IP द्वारा दर-सीमित (rate-limit) भी कर सकता है, और अतिरिक्त समवर्ती कनेक्शन उसके लिसन बैकलॉग, फ़ाइल डिस्क्रिप्टर, या लोड-बैलेंसर क्षमता से अधिक हो सकते हैं।

फॉलो-अप 5: tcptwreuse पर विचार करना कब उचित है?

पहले साबित करें कि कनेक्शन रीयूज़, पूल सेटिंग्स, पोर्ट रेंज और NAT क्षमता अपर्याप्त बनी हुई है। फिर सटीक कर्नेल संस्करण, TCP टाइमस्टैम्प व्यवहार और पीयर विशेषताओं की जांच करें। Linux केवल तभी पुन: उपयोग की अनुमति देता है जब यह प्रोटोकॉल के दृष्टिकोण से सुरक्षित हो और स्पष्ट रूप से सेटिंग को लापरवाही से बदलने के खिलाफ चेतावनी देता है। लोड के तहत पुनः कनेक्शन और डेटा शुद्धता का परीक्षण करें, RST, विफलताओं और लेटेंसी की निगरानी करें, और रोलबैक तैयार रखें। यह एप्लिकेशन-स्तरीय कनेक्शन पुन: उपयोग का विकल्प नहीं है।