टाइम_WAIT सेट करना TCP

हम ऐसे एप्लिकेशन को ट्यून करने का प्रयास कर रहे हैं जो टीसीपी के माध्यम से संदेशों को स्वीकार करता है और इसके कुछ आंतरिक संदेश के लिए टीसीपी का भी उपयोग करता है। लोड परीक्षण के दौरान, हमने देखा कि प्रतिक्रिया समय महत्वपूर्ण रूप से घटता है (और फिर पूरी तरह से बंद हो जाता है) क्योंकि सिस्टम के साथ एक साथ अनुरोध किए जाते हैं। इस समय के दौरान, हम TIME_WAIT की स्थिति में TCP कनेक्शन की एक बहुत कुछ देखने के लिए और किसी को TIME_WAIT वातावरण चर से यह TIME_WAIT सेटिंग अनिवार्य रूप से समय के लिए एक टीसीपी संसाधन उपलब्ध कराया गया है सेट 30.टाइम_WAIT सेट करना TCP

what I understand से करने के लिए डिफ़ॉल्ट 60 सेकंड है, को कम करने का सुझाव दिया कनेक्शन बंद होने के बाद सिस्टम को फिर से।

मैं "नेटवर्क लड़का" नहीं हूं और इन चीजों के बारे में बहुत कम जानता हूं। मुझे उस लिंक की गई पोस्ट में बहुत कुछ चाहिए, लेकिन थोड़ा "डूब गया"।

मुझे लगता है कि मुझे समझ में क्यों TIME_WAIT मूल्य 0 पर सेट नहीं किया जा सकता है, लेकिन यह सुरक्षित रूप से 5 के लिए सेट किया जा सकता है? 10 के बारे में क्या? इस मूल्य के लिए "सुरक्षित" सेटिंग क्या निर्धारित करती है?
इस मूल्य 60 के लिए डिफ़ॉल्ट क्यों है? मैं अनुमान लगा रहा हूं कि लोगों के मुकाबले बहुत ज्यादा स्मार्ट इसे उचित डिफ़ॉल्ट के रूप में चुनने का अच्छा कारण था।
मुझे इस मूल्य को ओवरराइड करने के संभावित जोखिमों और लाभों के बारे में और क्या पता होना चाहिए?

स्रोत

2008-12-03 Vinnie

इसके अलावा आप इसे बहुत अधिक सेट नहीं करना चाहते हैं: http://stackoverflow.com/questions/1803566/what-is-the-cost-of-many-time-wait-on-the- सर्वर- पक्ष – Pacerier

एक टीसीपी कनेक्शन टुपल (स्रोत आईपी, स्रोत पोर्ट, गंतव्य आईपी, गंतव्य पोर्ट) द्वारा निर्दिष्ट किया जाता है।

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

तो TIME_WAIT समय आमतौर पर पैकेट को अधिकतम आयु दोगुना करने के लिए सेट किया जाता है। यह मान अधिकतम उम्र है जब आपके पैकेट को नेटवर्क छोड़ने से पहले प्राप्त करने की अनुमति दी जाएगी।

यह गारंटी देता है कि, आपको एक ही टुपल के साथ कनेक्शन बनाने की अनुमति देने से पहले, उस टुपल के पिछले अवतारों के सभी पैकेट मर जाएंगे।

जो आमतौर पर आपके द्वारा उपयोग किए जाने वाले न्यूनतम मान को निर्देशित करता है। अधिकतम पैकेट आयु नेटवर्क गुणों द्वारा निर्धारित की जाती है, एक उदाहरण यह है कि सैटेलाइट जीवनकाल लैन जीवनकाल से अधिक है क्योंकि पैकेट के पास जाने के लिए बहुत कुछ है।

स्रोत

2008-12-03 13:46:17 paxdiablo

मैं "अधिकतम पैकेट आयु" कैसे निर्धारित कर सकता हूं? क्या यह सेट ओएस, नेटवर्क पर कुछ, या कुछ सॉफ्टवेयर सेटिंग है? बीटीडब्ल्यू, इन कनेक्शनों में से अधिकांश "जनरेटिंग" कोड एक तृतीय पक्ष मंच है जिसके लिए हमारे पास स्रोत नहीं है। महान प्रतिक्रिया के लिए धन्यवाद! – Vinnie

इसके लिए वास्तविक नाम अधिकतम सेगमेंट जीवनकाल, एमएसएल है। सुनिश्चित नहीं है कि आप इसे विंडोज़ में बदल सकते हैं या यहां तक कि यदि आपको करना चाहिए - यह नेटवर्क विशेषताओं के आधार पर सेट किया जाना है। विंडोज़ इसे 120 के दशक में सेट करता है, मुझे लगता है। सभी टीसीपी पैरा HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ Tcpip \ पैरामीटर में हैं। – paxdiablo

'सुनिश्चित नहीं है कि आप इसे विंडोज़ में बदल सकते हैं या यहां तक कि यदि आपको करना चाहिए - यह नेटवर्क विशेषताओं के आधार पर सेट किया जाना है। विंडोज़ इसे 120 के दशक में सेट करता है, मुझे लगता है। '☹ आप निश्चित रूप से [इसे लिनक्स में बदल सकते हैं] (http://serverfault.com/a/23529/14019) और 120 * रास्ता * बहुत लंबा है। मैंने पुष्टि करने के लिए परीक्षण नहीं किया है, लेकिन ऐसा लगता है कि इतनी लंबी देरी होने से अधिकांश राउटर पर अनावश्यक रूप से पी 2 पी नरक बन जाता है। – Synetech

पैक्स TIME_WAIT के कारणों के बारे में सही है, और आपको डिफ़ॉल्ट सेटिंग को कम करने के बारे में सावधान क्यों होना चाहिए।

एक बेहतर समाधान आपके सॉकेट के मूल अंत के लिए उपयोग किए जाने वाले पोर्ट नंबरों को बदलना है। एक बार ऐसा करने के बाद, आपको वास्तव में व्यक्तिगत सॉकेट के लिए समय की प्रतीक्षा करने की परवाह नहीं होगी।

सॉकेट सुनने के लिए, आप SO_REUSEADDR का उपयोग कर सकते हैं ताकि सुनने के सॉकेट को बाउंड करने के लिए TIME_WAIT सॉकेट के बावजूद बाध्य किया जा सके।

स्रोत

2008-12-03 14:05:28 Darron

+10

मैं "पैक्स सही है" वाक्यांश से शुरू होने वाले किसी भी उत्तर को ऊपर उठाऊंगा। :-) – paxdiablo

कई सक्रिय मशीनों के साथ बहुत सक्रिय मशीनों के लिए TIME_WAIT में सभी क्षणिक बंदरगाहों को जोड़ना वास्तव में संभव है। एक बार ऐसा होने पर आप कुछ और कनेक्शन नहीं खोल सकते जब तक कि कुछ सॉकेट इंतजार नहीं कर लेते। TIME_WAIT अवधि को कम करने से बहुत मदद मिल सकती है। जैसा कि लेन होल्गेट द्वारा उल्लेख किया गया है, यदि ग्राहक संभवतः सक्रिय बंद करना शुरू कर देता है, तो यह बहुत बेहतर है, क्योंकि यह TIME_WAIT कर्तव्यों के सर्वर को पूरी तरह से रोक देता है। –

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

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

यहाँ देखें: http://www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html और http://www.isi.edu/touch/pubs/infocomm99/infocomm99-web/ जानकारी के लिए (जो बाद में भी बताता है कि क्यों यह हमेशा नहीं प्रोटोकॉल डिजाइन कि ध्यान में TIME_WAIT नहीं ले करता है की वजह से संभव है)।

स्रोत

2008-12-03 15:40:34

अच्छा बिंदु, सर्वर को अभी भी अपने एफआईएन से एसीके की प्रतीक्षा करनी होगी, लेकिन इसमें कम समय लगना चाहिए। शुरुआतकर्ता को सत्र बंद करने के लिए भी अच्छा अभ्यास है क्योंकि यह केवल समाप्त होने पर ही जानता है। – paxdiablo

-1

TIME_WAIT अपराधी नहीं हो सकता है।

int listen(int sockfd, int backlog);

यूनिक्स नेटवर्क प्रोग्रामिंग Volume1 के अनुसार, बैकलॉग पूरा कनेक्शन कतार और अधूरा कनेक्शन कतार का योग होने के लिए परिभाषित किया गया है।

मान लें कि बैकलॉग 5 है। यदि आपके पास 3 पूर्ण कनेक्शन (स्थापित राज्य) हैं, और 2 अपूर्ण कनेक्शन (SYN_RCVD स्थिति) हैं, और SYN के साथ एक और कनेक्ट अनुरोध है। टीसीपी स्टैक सिर्फ एसईएन पैकेट को अनदेखा करता है, क्योंकि यह जानकर कि इसे किसी अन्य समय पर पुनः प्रेषित किया जाएगा। यह गिरावट का कारण बन सकता है।

कम से कम यही वह है जो मैं पढ़ रहा हूं। ;)

स्रोत

2008-12-03 18:04:41 yogman

मुझे पूरा यकीन है कि बैकलॉग केवल उन कनेक्शनों के लिए है जो अभी तक स्थापित नहीं हुए हैं; एक बार उनके पास, वे कतार से हटा दिए जाते हैं; वे केवल तब तक आने वाले कनेक्शन को अवरुद्ध कर रहे हैं जब तक (SYN, SYN/ACK, ACK) हैंडशेकिंग पूर्ण हो जाती है, मूल रूप से सर्वर स्वीकार करने के बाद()। – paxdiablo

(-1) नहीं, सुनो बैकलॉग पूरी तरह से कनेक्शन के लिए है जो पूरी तरह से स्थापित नहीं हैं; यानी वे टीसीपी/आईपी स्टैक पर पहुंचे हैं लेकिन अभी तक 'स्वीकार नहीं' किए गए हैं। यदि आपका सुनो बैकलॉग बहुत छोटा है तो कनेक्शन आपके कनेक्शन को अस्वीकार कर देगा यदि कनेक्शन अधिक तेज़ी से आते हैं तो इससे उन्हें स्वीकार किया जा सकता है। –

एक मामूली गलतफहमी। "पूर्ण कनेक्शन कतार। इस कतार में प्रत्येक कनेक्शन के लिए एक प्रविष्टि है जिसके लिए तीन तरह हैंडशेक पूरा हो गया है। सॉकेट स्थापित स्थिति में है। स्वीकार करने के लिए प्रत्येक कॉल() कतार की अगली प्रविष्टि को हटा देता है।" http://www.sean.de/Solaris/soltune.html – yogman

Windows में, आप can change यह through the registry:

; Set the TIME_WAIT delay to 30 seconds (0x1E) 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters] 
"TcpTimedWaitDelay"=dword:0000001E

स्रोत

2013-03-24 00:47:03 Synetech

सेटिंग tcp_fin_timeout time_wait को प्रभावित नहीं करता है - यह एक आम गलतफहमी है। यह एक पूरी तरह से अलग बात के लिए है (स्पष्ट रूप से एक एफआईएन टाइमआउट)। इस सेटिंग में गाइड और इस तरह के बिंदु के बहुत सारे हैं लेकिन वे गलत हैं। Tcp.h देखें और आप देखेंगे कि यह हार्ड-कोडेड (लिनक्स) है। – mcauth

मैं 20 धागे के साथ एक परीक्षण कार्यक्रम का उपयोग करके एक सर्वर अनुप्रयोग (linux पर) का परीक्षण लोड किया गया है।

95 9, 000 कनेक्ट/क्लोज़ चक्र में 44,000 विफल कनेक्शन और TIME_WAIT में कई हजार सॉकेट थे।

मैंने क्लोज कॉल से पहले SO_LINGER को 0 पर सेट किया था और परीक्षण कार्यक्रम के बाद के रनों में TIME_WAIT में कोई कनेक्ट विफलता और 20 सॉकेट से कम नहीं थी।

स्रोत

2016-04-28 06:54:48

और आपने डेटा खोने का जोखिम भी चलाया। यह सही समाधान नहीं है। SO_LINGER के साथ ट्राइफ करने के लिए कुछ नहीं है। सही समाधान यह सुनिश्चित करना है कि ग्राहक पहले बंद हो जाए, आमतौर पर क्लाइंट पर कनेक्शन-पूलिंग और सर्वर लिखने के लिए ताकि प्रति कनेक्शन एकाधिक अनुरोधों को संभाला जा सके। वास्तव में HTTP 1.1 की तरह। – EJP

मुझे अपनी प्रतिक्रिया में स्पष्ट होना चाहिए था। मैं विंडोज़ पर देखी गई समस्या को इंगित करने के लिए अदरक समय को 0 पर सेट करने की वकालत नहीं कर रहा हूं। लिनक्स पर यह समस्या नहीं हुई। तो यह सिस्टम निर्भर है और, शायद, इस पर निर्भर करता है कि कौन सी सिस्टम सेटिंग्स सक्रिय हैं। –

यह सिस्टम-निर्भर नहीं है। इस तरह की सॉकेट को रीसेट करने से उड़ान में सभी डेटा खो जाता है। – EJP

tcp_reuse को सेट करने से tim_wait को बदलने से अधिक उपयोगी है, जब तक आपके पास पैरामीटर (कर्नेल 3.2 और ऊपर, दुर्भाग्य से आरएचईएल और ज़ेनसेवर के सभी संस्करणों को अयोग्य घोषित करता है)।

विशेष रूप से वीपीएन जुड़े उपयोगकर्ताओं के लिए मूल्य छोड़ना, परिणामस्वरूप आउटबाउंड कनेक्शन पर प्रॉक्सी सुरंगों का निरंतर मनोरंजन हो सकता है। डिफॉल्ट नेटस्केकर (ज़ेनसेवर) कॉन्फ़िगरेशन के साथ, जो डिफ़ॉल्ट लिनक्स कॉन्फ़िगरेशन से कम है, क्रोम को कभी-कभी एक वेब पेज पुनर्प्राप्त करने के लिए प्रॉक्सी सुरंग को एक दर्जन बार फिर से बनाना होगा। वे अनुप्रयोग जो पुनः प्रयास नहीं करते हैं, जैसे मेवेन और एक्लिप्स पी 2, बस असफल हो जाते हैं।

पैरामीटर के लिए मूल उद्देश्य (डुप्लिकेशन से बचें) को एक टीसीपी आरएफसी द्वारा अनावश्यक बनाया गया था जो सभी टीसीपी अनुरोधों पर टाइमस्टैम्प समावेशन निर्दिष्ट करता है।

स्रोत

2016-06-02 19:38:10

टाइम_WAIT सेट करना TCP

उत्तर

संबंधित मुद्दे