Tcp_tw_recycle / reuse को 1 पर सेट करने के क्या प्रभाव हैं?

10

मैंने अपनी कॉन्फ़िगरेशन फ़ाइल में दोनों tcp_tw_recycle / reuse को 1 पर सेट किया है।

ऐसा करने के क्या नियम हैं?

यदि एक tcp सॉकेट का फिर से उपयोग किया जाता है, तो क्या यह सुरक्षा जोखिम पैदा करता है? यानी 2 अलग कनेक्शन दोनों संभावित रूप से डेटा भेजने में सक्षम हैं?

क्या यह पुनरुत्थान के मुकदमे के साथ अल्पकालिक कनेक्शन के लिए उपयुक्त है?

ubuntu tcp socket

— codecompleting
स्रोत

स्पष्ट प्रश्न यह है कि इस परिवर्तन से आपको क्या लाभ होने की उम्मीद है?

— रॉबर्ट मंटीनू

1

— @RobertMunteanu

24

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

जब आप सक्षम करते हैं tcp_tw_reuse, तो TIME_WAITराज्य में सॉकेट्स का उपयोग समाप्त होने से पहले किया जा सकता है, और कर्नेल यह सुनिश्चित करने की कोशिश करेगा कि टीसीपी अनुक्रम संख्याओं के बारे में कोई टक्कर नहीं है। यदि आप tcp_timestamps(उर्फ PAWS, सुरक्षा के खिलाफ रैपिड अनुक्रम अनुक्रम के लिए) सक्षम करते हैं, तो यह सुनिश्चित करेगा कि उन टकराव नहीं हो सकते। हालाँकि, आपको दोनों छोर पर सक्षम होने के लिए टीसीपी टाइमस्टैम्प चाहिए (कम से कम, यही मेरी समझ है)। Gory विवरण के लिए tcp_twsk_unique की परिभाषा देखें।

जब आप सक्षम करते हैं tcp_tw_recycle, तो कर्नेल अधिक आक्रामक हो जाता है, और दूरस्थ मेजबानों द्वारा उपयोग की जाने वाली टाइमस्टैम्प पर धारणाएं बना देगा। यह अंतिम टाइमस्टैम्प को ट्रैक करेगा जिसका उपयोग प्रत्येक दूरस्थ होस्ट द्वारा TIME_WAITराज्य में एक कनेक्शन है ), और टाइमस्टैम्प सही ढंग से बढ़ने पर सॉकेट को फिर से उपयोग करने की अनुमति देता है। हालाँकि, यदि होस्ट द्वारा उपयोग किया जाने वाला टाइमस्टैम्प बदल जाता है (अर्थात समय में वापस आ जाता है), तो SYNपैकेट चुपचाप गिरा दिया जाएगा, और कनेक्शन स्थापित नहीं होगा (आपको "कनेक्ट टाइमआउट" के समान त्रुटि दिखाई देगी)। यदि आप कर्नेल कोड में गोता लगाना चाहते हैं, तो tcp_timewait_state_process की परिभाषा एक अच्छा प्रारंभिक बिंदु हो सकती है।

अब, टाइमस्टैम्प को समय में वापस नहीं जाना चाहिए; जब तक:

होस्ट को रिबूट किया गया है (लेकिन फिर, जब तक यह वापस आता है, तब तक TIME_WAITसॉकेट संभवतः समाप्त हो जाएगा, इसलिए यह एक गैर मुद्दा होगा);
आईपी पते को कुछ और द्वारा पुन: उपयोग किया जाता है ( TIME_WAITकनेक्शन थोड़े रहेंगे, लेकिन अन्य कनेक्शन संभवतः टकरा TCP RSTजाएंगे और इससे कुछ जगह खाली हो जाएगी);
नेटवर्क एड्रेस ट्रांसलेशन (या स्मार्टी-पैंट फ़ायरवॉल) कनेक्शन के बीच में शामिल है।

बाद के मामले में, आप एक ही आईपी पते के पीछे कई होस्ट कर सकते हैं, और इसलिए, टाइमस्टैम्प के विभिन्न अनुक्रम (या, कहा जाता है कि टाइमस्टैम्प को फ़ायरवॉल द्वारा प्रत्येक कनेक्शन पर यादृच्छिक किया जाता है)। उस स्थिति में, कुछ होस्ट यादृच्छिक रूप से कनेक्ट करने में असमर्थ होंगे, क्योंकि वे एक पोर्ट पर मैप किए जाते हैं, जिसके TIME_WAITलिए सर्वर की बाल्टी में एक नया टाइमस्टैम्प होता है। इसीलिए डॉक्स आपको बताता है कि "NAT डिवाइस या लोड बैलेंसर सेटिंग के कारण ड्रॉप फ्रेम शुरू कर सकते हैं"।

कुछ लोग अकेले छोड़नेtcp_tw_recycletcp_tw_reusetcp_timewait_len की सलाह देते हैं, लेकिन सक्षम और कम । मैं सहमत हूँ :-)

— jpetazzo
स्रोत

शानदार व्याख्या

— yanglei

6

मेरा बस यही मुझे काट रहा था, इसलिए शायद किसी को मेरे दर्द और तकलीफ का फायदा हो। सबसे पहले, बहुत सारी जानकारी के साथ एक जुड़ा हुआ लिंक: http://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux.html

विशेष रूप से:

दस्तावेज़ीकरण की इस कमी का एकमात्र परिणाम यह है कि हम इन दोनों सेटिंग्स को 1 में सेट करने की सलाह देते हुए कई ट्यूनिंग गाइड पाते हैं, जो टाइम-वॉइट राज्य में प्रविष्टियों की संख्या को कम करने के लिए है। हालाँकि, जैसा कि tcp (7) मैनुअल पेज द्वारा कहा गया है, net.ipv4.tcp_tw_recycle विकल्प सार्वजनिक-सामना करने वाले सर्वरों के लिए काफी समस्याग्रस्त है क्योंकि यह एक ही NAT डिवाइस के पीछे दो अलग-अलग कंप्यूटरों से कनेक्शन को संभाल नहीं पाएगा, जो एक समस्या कठिन है। पता लगाने और आप को काटने की प्रतीक्षा में:

मैं उन लोगों का उपयोग करने में सक्षम था, जो संभवत: कम विलंबता प्रदान करने में सक्षम थे, क्लाइंट से MySql NDB क्लस्टर के लिए hproxy कनेक्टिविटी। यह एक निजी बादल में था, और किसी भी तरह से किसी भी तरह के मिश्रण में किसी भी प्रकार का NAT नहीं था। उपयोग के मामले में समझदारी, रेडियस के ग्राहकों के लिए विलंबता को एनडीबी को हाईप्रोफाइल के माध्यम से जितना संभव हो उतना कम संभव बनाया गया है। इसने ऐसा किया।

मैं फिर से एक सार्वजनिक haproxy प्रणाली का सामना कर रहा था, लोडिंग वेब ट्रैफ़िक को लोड कर रहा था, वास्तव में प्रभाव का अध्ययन किए बिना (गूंगा, ठीक है ?!) और बहुत समस्या निवारण और भूत का पीछा करने के बाद पता चला है कि:

यह NAT के माध्यम से जुड़ने वाले ग्राहकों के लिए तबाही पैदा करेगा।
यह पहचानना लगभग असंभव है क्योंकि यह पूरी तरह से यादृच्छिक, रुक-रुक कर चल रहा है, और लक्षण ग्राहक ए को मारेंगे, ग्राहक बी आदि की तुलना में पूरी तरह से अलग (या नहीं) बार।

ग्राहक की ओर से, वे समय की अवधि देखेंगे जहां उन्हें अब SYN पैकेट पर प्रतिक्रिया नहीं मिलती है, कभी-कभी यहां-वहां और कभी-कभी लंबे समय तक। फिर से, यादृच्छिक।

यहाँ लघु कहानी, मेरे हालिया, दर्दनाक, अनुभव में, इन / सार्वजनिक विकलांग सर्वर पर अक्षम है, भूमिका की परवाह किए बिना!

— मैक
स्रोत

4

'मैन 7 टीसीपी' से आप इसे देखेंगे:

   tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
          Enable fast recycling of TIME_WAIT sockets.  Enabling this option is not recommended since this causes problems when working with NAT
          (Network Address Translation).

   tcp_tw_reuse (Boolean; default: disabled; since Linux 2.4.19/2.6)
          Allow  to  reuse  TIME_WAIT  sockets  for  new connections when it is safe from protocol viewpoint.  It should not be changed without
          advice/request of technical experts.

वहां ज्यादा मदद नहीं मिली। इस यूरेशन की कुछ अच्छी जानकारी भी है:

/programming/6426253/tcp-tw-reuse-vs-tcp-tw-recycle-which-to-use-or-both

लेकिन पुनरावृत्ति की तुलना में पुन: उपयोग क्यों किया जाता है, इस बारे में विशेष जानकारी सुरक्षित नहीं है। मूल उत्तर यह है कि tcp_tw_reuse किसी को एक ही सॉकेट का उपयोग करने की अनुमति देगा, यदि पहले से ही TIME_WAIT में समान TCP मापदंडों के साथ एक है और वह ऐसी स्थिति में है जहाँ आगे कोई ट्रैफ़िक होने की उम्मीद नहीं है (मुझे विश्वास है कि जब एक फ़ाइनल भेजा गया है )। दूसरी ओर tcp_tw_recycle बस उन सॉकेट्स का पुनः उपयोग करेगा जो TIME_WAIT में राज्य की परवाह किए बिना समान मापदंडों के साथ हैं, जो स्टेटफुल फ़ायरवॉल को भ्रमित कर सकते हैं जो अलग-अलग पैकेट की उम्मीद कर सकते हैं।

tcp_tw_reuse को चुनिंदा रूप से SO_REUSEADDR सॉकेट विकल्प सेट करके किया जा सकता है, man 7 socketइस तरह से प्रलेखित :

   SO_REUSEADDR
          Indicates that the rules used in validating addresses supplied in a bind(2) call should allow reuse of local addresses.  For  AF_INET
          sockets  this means that a socket may bind, except when there is an active listening socket bound to the address.  When the listening
          socket is bound to INADDR_ANY with a specific port then it is not possible to bind to this port for any local address.   Argument  is
          an integer boolean flag.

— SpamapS
स्रोत

1

क्या आप वाकई इससे SO_REUSEADDRजुड़े हुए हैं tcp_tw_reuse? जहां तक मुझे पता है, SO_REUSEADDRकेवल तब ही लागू होता है जब आप चाहते हैं bind(), जबकि tcp_tw_reuseकर्नेल को TIME_WAITराज्य में एक स्थानीय सॉकेट के पोर्ट का पुन: उपयोग करने के लिए निर्देश देगा यदि उसे एक नया आउटगोइंग कनेक्शन बनाने की आवश्यकता होती है।

— jpetazzo

नहीं मुझे यकीन नहीं है :-P

— SpamapS