टीसीपी शून्य-खिड़की के बाद टीसीपी रख-जिंदा शामिल हो जाता है और कनेक्शन को गलती से बंद कर देता है

Question

हम देख रहे हैं कि यह पैटर्न दो आरएचईएल 6 बक्से के बीच बहुत कुछ होता है जो एक टीसीपी कनेक्शन के माध्यम से डेटा स्थानांतरित कर रहे हैं। क्लाइंट एक टीसीपी विंडो फुल जारी करता है, 0.2 के बाद क्लाइंट टीसीपी कीपैलीव भेजता है, जिस पर सर्वर सही आकार के प्रतिक्रियाओं की तरह दिखता है। क्लाइंट इस से असंतुष्ट है और टीसीपी रखरखाव भेज रहा है जब तक कि अंततः लगभग 9 एस के बाद आरएसटी के साथ कनेक्शन बंद नहीं हो जाता।

यह डिफ़ॉल्ट टीसीपी keepalive configuratation

net.ipv4.tcp_keepalive_time = 7200 
net.ipv4.tcp_keepalive_probes = 9 
net.ipv4.tcp_keepalive_intvl = 75 

जिसमें यह घोषणा की है कि यह केवल मौन के 2hrs तक होने चाहिए होने RHEL बक्से के बावजूद है। क्या मैं अपना पीसीएपी गलत पढ़ रहा हूं (अनुरोध पर उपलब्ध प्रासंगिक पैकेट)?

नीचे मेरे स्वयं के पैकेट नोट्स के साथ, पैटर्न के वायरशर्क स्रीनशॉट नीचे है।

एम

Answer 1

ग्राहक से होने वाले प्रतिक्रिया पैकेट में गंतव्य और स्रोत IP पते से मेल नहीं खाते पैकेट, जो इंगित करता में स्रोत और गंतव्य IP पते वहाँ के बीच में कुछ उपकरण है कि एनएटी कर रहे बक्से। यह समझना भी महत्वपूर्ण है कि पैकेट कहाँ पर कब्जा कर लिया गया है। शायद ग्राहक पर एक पैकेट कैप्चर इस मुद्दे को समझने में मदद करेगा।

कृपया ध्यान दें कि क्लाइंट टीसीपी रखरखाव उत्पन्न कर सकता है अगर उसे दो घंटे या उससे अधिक के लिए डेटा पैकेट प्राप्त नहीं होता है। आरएफसी 1122 के अनुसार, यदि ग्राहक सहकर्मी से रखरखाव प्रतिक्रिया प्राप्त नहीं करता है तो ग्राहक रखरखाव को पुनः प्रयास करता है। अंततः निरंतर पुनः प्रयास विफलता के बाद यह डिस्कनेक्ट हो जाता है।

एनएटी डिवाइस आमतौर पर चल रहे कनेक्शन की स्थिति को बनाए रखने के लिए कनेक्शन कैश को लागू करते हैं। यदि कनेक्शन का आकार सीमा तक पहुंच जाता है, तो नए कनेक्शन की सेवा के लिए एनएटी डिवाइस पुराने कनेक्शन छोड़ देता है। इससे इस तरह के परिदृश्य भी हो सकते हैं।

दिया गया पैकेट कैप्चर इंगित करता है कि उच्च संभावना है कि पैकेट क्लाइंट तक नहीं पहुंच रहे हैं, इसलिए क्लाइंट मशीन पर पैकेट को कैप्चर करना उपयोगी होगा।

Answer 2

मैं कुछ अलग ढंग से पता लगाने पढ़ें: भेजने वाले और अधिक डेटा की तुलना में रिसीवर संभाल कर सकते हैं भेजता है और zerowindow प्रतिक्रिया प्रेषक खिड़की जांच भेजता हो जाता है (keepalives नहीं यह तरीका है करने के लिए जल्द ही उस के लिए) और आवेदन नहीं के साथ 10 सेकंड के बाद देता है प्रगति और कनेक्शन बंद कर देता है, रीसेट इंगित करता है कि टीसीपी sendbuffer में लंबित डेटा है। यदि एप्लिकेशन सॉकेट में बड़े ब्लॉकिज़िंग लेखन का उपयोग करता है तो यह tcpdump में 10 सेकंड से अधिक के लिए कोई प्रगति नहीं देखी हो सकती है।

इस एक सीधे कनेक्शन (कोई प्रॉक्सी आदि) का सर्वाधिक संभावित कारण अप प्राप्त करना बंद प्राप्त करने के लिए (या इस & आंकड़ा संचरण की तुलना में धीमी है) है, तो

Answer 3

यह पैकेट संख्या 249,522 की तरह मुझे लग रहा है कनेक्शन को रद्द करने के लिए आवेदन 10.120.67.113 को उकसाया। सभी विंडो जांचों को शून्य से एक विंडो विंडो प्रतिक्रिया प्राप्त होती है (बिना पेलोड के) और फिर .132 63 बाइट्स (और अभी भी 0 विंडो दिखा रहा है) के साथ 249522 (अनचाहे) पैकेट भेजता है। पीएसएच ध्वज से पता चलता है कि यह 63 बाइट एप द्वारा लिखित संपूर्ण डेटा है .132 पर। फिर .113 उसी मिलीसेकंड में एक आरएसटी के साथ प्रतिक्रिया करता है। मैं किसी भी कारण से नहीं सोच सकता कि क्यों टीसीपी स्टैक डेटा प्राप्त करने के तुरंत बाद आरएसटी भेज देगा (अनुक्रम संख्या सही हैं)। मेरे विचार में यह लगभग निश्चित है कि .113 पर ऐप द्वारा भेजे गए 63 बाइट संदेश के आधार पर छोड़ने का फैसला किया गया है।132.