TIME_WAIT कनेक्शन की विशाल राशि netstat कहती है

Question

ठीक है, यह मुझे परेशान कर रहा है - मैं इनमें से लगभग 1500-2500 देखता हूं:

root@wherever:# netstat

Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 localhost:60930         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60934         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60941         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60947         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60962         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60969         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60998         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60802         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60823         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60876         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60886         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60898         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60897         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60905         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60918         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60921         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60673         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60680         localhost:sunrpc        TIME_WAIT  
[etc...]

root@wherever:# netstat | grep 'TIME_WAIT' |wc -l
1942

वह संख्या तेजी से बदल रही है।

मेरे पास एक बहुत तंग iptables कॉन्फिग है, इसलिए मुझे नहीं पता कि यह क्या कारण हो सकता है। कोई विचार?

धन्यवाद,

तमस

संपादित करें: 'netstat -anp' का आउटपुट:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:60968         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60972         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60976         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60981         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60980         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60983         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60999         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60809         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60834         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60872         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60896         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60919         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60710         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60745         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60765         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60772         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60558         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60564         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60600         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60624         127.0.0.1:111           TIME_WAIT   -               

Comments

क्या आपके पास उसी मशीन पर कुछ एनएफएस घुड़सवार है जो इसे निर्यात कर रहा है?

— पॉल टॉम्बलिन

@ पाओल टॉम्बलिन: नहीं

— केटामस

ठीक है, आपको यह पता लगाने के लिए स्थापित कनेक्शनों को देखना चाहिए कि यह कौन सा कार्यक्रम है। "rcpinfo -p" यह भी पता लगाने में मदद कर सकता है कि पोर्टमैप के साथ क्या संचार हो रहा है।

— cstamas

उन लोगों के लिए जो विंडोज के तहत देरी को समायोजित करने का तरीका खोजने की कोशिश करते हुए यहां अपना रास्ता ढूंढते हैं, यह एक रजिस्ट्री सेटिंग के माध्यम से किया जा सकता है ।

— सिंटेक

Answer 1

संपादित करें: tcp_fin_timeout TIME_WAIT अवधि को नियंत्रित नहीं करता है , यह 60 के दशक में हार्डकोड है

जैसा कि दूसरों ने उल्लेख किया है, कुछ कनेक्शन होने TIME_WAITपर टीसीपी कनेक्शन का एक सामान्य हिस्सा है। आप परीक्षण करके अंतराल देख सकते हैं /proc/sys/net/ipv4/tcp_fin_timeout:

[root@host ~]# cat /proc/sys/net/ipv4/tcp_fin_timeout
60

और उस मान को संशोधित करके इसे बदलें:

[root@dev admin]# echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

या स्थायी रूप से इसे /etc/sysctl.conf में जोड़कर

net.ipv4.tcp_fin_timeout=30

इसके अलावा, यदि आप RPC सेवा या NFS का उपयोग नहीं करते हैं, तो आप इसे बंद कर सकते हैं:

/etc/init.d/nfsd stop

और इसे पूरी तरह से बंद कर दें

chkconfig nfsd off

Comments

हाँ, मेरी ipconfig स्क्रिप्ट पहले से ही इसे 30 तक कम कर देती है। मेरे पास /etc/init.d/ में nfsd नहीं है, लेकिन मैंने पोर्टमैप रन किया है, इसे रोक दिया है, अब TIME_WAITs को कुछ उदाहरणों (1-5) से नीचे कर दिया गया है। धन्यवाद।

— केटामस

उह, tcp_fin_timeout का time_wait राज्य में सॉकेट्स से कोई लेना-देना नहीं है। यह fin_wait_2 को प्रभावित करता है।

— दीव

Diq की टिप्पणी के लिए +1। वे संबंधित नहीं हैं।

— mcauth

सही ... आप 60 से नीचे की गिनती को देख सकते हैं, भले ही tcp_fin_timeout का उपयोग करके परिवर्तित किया गया होss --numeric -o state time-wait dst 10.0.0.100

— ग्रेग ब्रे

Answer 2

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

Comments

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

— nobar

छोटा पसीना, पूरा नहीं। TIME_WAITs संदर्भ पर निर्भर करते हैं। यदि आपके पास उनमें से बहुत सारे हैं तो हो सकता है कि कोई आपके सर्वर पर हमला कर रहा हो।

— मिन्दुगास बर्नटाविकियस

Answer 3

यह महत्वपूर्ण नहीं है। यह सब दर्शाता है कि आप बहुत सारे Sun RCP TCP कनेक्शन खोल रहे हैं और बंद कर रहे हैं (हर 2-4 मिनट में उनमें से 1500-2500)। TIME_WAITराज्य की तरह वे अगर हो सकता है सॉकेट बहुत जल्दी पुन: उपयोग किया गया है, और अन्य उपयोगी प्रयोजनों के एक जोड़े के लिए गलत अनुप्रयोगों के लिए पहुंचने से संदेश को रोकने के लिए, क्या एक सॉकेट जब यह बंद कर देता है में चला जाता है। इसके बारे में चिंता मत करो।

(जब तक, निश्चित रूप से, आप वास्तव में कुछ भी नहीं चला रहे हैं जो कि कई आरसीपी संचालन को संसाधित करना चाहिए। फिर, चिंता करें।)

Comments

मैं ज्यादातर कूरियर-इमैप और पोस्टफिक्स चलाता हूं।

— केटामस

Answer 4

आपके सिस्टम पर कुछ आपके सिस्टम के भीतर बहुत सारे RPC (रिमोट प्रोसीजर कॉल्स) कर रहा है (नोटिस दोनों स्रोत और गंतव्य लोकलहोस्ट है)। यह अक्सर एनएफएस माउंट के लिए लॉकड के लिए देखा जाता है, लेकिन आप इसे अन्य आरपीसी कॉल जैसे कि rpc.statd या rpc.spray के लिए भी देख सकते हैं।

आप "lsof -i" का उपयोग करके यह देखने का प्रयास कर सकते हैं कि उन लोगों के पास कौन से कुर्सियां ​​खुली हैं और देखें कि यह क्या कर रहा है। यह शायद हानिरहित है।

Comments

असामान्य कुछ भी नहीं है, मुझे पोर्टमैप के लिए एक टीसीपी *: सनरपीसी (लिस्टेन) दिखाई देता है लेकिन लगता है कि सामान्य है।

— केटामस

इसे बार-बार करते रहें जब तक आप यह न देख लें कि कनेक्शन कौन खोल रहा है।

— पॉल टॉम्बलिन

netstat -epn --tcp आपको समान जानकारी दिखाएगा। जब तक आप NFS का उपयोग नहीं कर रहे हैं, आपके पास पोर्टमैप का उपयोग करने के लिए बहुत कम कारण हैं। आप इसे हटा सकते हैं।

— डेविड पशले

मैं वास्तव में एनएफएस का उपयोग नहीं करता हूं, हालांकि एप्ट-गेट रिमूव पोर्टमैप चाहता है कि 'फैम' को हटा दिया जाए जो कि संभवत: libfam0 द्वारा स्थापित किया गया था जो कि कूरियर-इमैप द्वारा स्थापित किया गया था। apt-cache का कहना है कि 'fam' libfam0 के लिए एक अनुशंसित पैकेज है।

— केटामस

Answer 5

tcp_fin_timeoutTIME_WAITदेरी को नियंत्रित नहीं करता है । आप इसे देखने के लिए ss या netstat का उपयोग करके देख सकते हैं।

cat /proc/sys/net/ipv4/tcp_fin_timeout
3

# See countdown timer for all TIME_WAIT sockets in 192.168.0.0-255
ss --numeric -o state time-wait dst 192.168.0.0/24

NetidRecv-Q  Send-Q    Local Address:Port    Peer Address:Port                             
tcp  0       0         192.168.100.1:57516   192.168.0.10:80    timer:(timewait,55sec,0)   
tcp  0       0         192.168.100.1:57356   192.168.0.10:80    timer:(timewait,25sec,0)   
tcp  0       0         192.168.100.1:57334   192.168.0.10:80    timer:(timewait,22sec,0)   
tcp  0       0         192.168.100.1:57282   192.168.0.10:80    timer:(timewait,12sec,0)   
tcp  0       0         192.168.100.1:57418   192.168.0.10:80    timer:(timewait,38sec,0)   
tcp  0       0         192.168.100.1:57458   192.168.0.10:80    timer:(timewait,46sec,0)   
tcp  0       0         192.168.100.1:57252   192.168.0.10:80    timer:(timewait,7.436ms,0) 
tcp  0       0         192.168.100.1:57244   192.168.0.10:80    timer:(timewait,6.536ms,0)

यहां तक ​​कि tcp_fin_timeout से 3 पर सेट TIME_WAIT के लिए उलटी गिनती अभी भी 60 से शुरू होती है। हालांकि, यदि आपके पास net.ipv4.tcp_tw_reuse 1 पर सेट है ( echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse) है, तो कर्नेल TIME_WAIT में सॉकेट को फिर से सेट कर सकता है यदि यह निर्धारित करता है कि टीसीपी में कोई संभावित संघर्ष नहीं होगा। खंड संख्या।

Answer 6

मुझे भी यही समस्या थी। मुझे यह पता लगाने में कई घंटे लगते हैं कि क्या हो रहा है। मेरे मामले में, इसका कारण यह था कि netstat IP के अनुरूप hostname को देखने की कोशिश करता है (मुझे लगता है कि यह gethostbyaddr API का उपयोग कर रहा है)। मैं एक एम्बेडेड लिनक्स इंस्टॉलेशन का उपयोग कर रहा था जिसमें कोई /etc/nsswitch.conf नहीं था। मेरे आश्चर्य करने के लिए, समस्या केवल तब होती है जब आप वास्तव में एक netstat -a कर रहे होते हैं (वर्बोज़ और डिबग मोड में पोर्टमैप चलाकर इसका पता लगाते हैं)।

अब जो हुआ वह निम्न था: प्रति डिफ़ॉल्ट, लुकअप फ़ंक्शन एक होस्टनाम के लिए क्वेरी करने के लिए ypbind डेमन (सन येलो पेज, जिसे एनआईएस भी कहा जाता है) से संपर्क करने की कोशिश करते हैं। इस सेवा को क्वेरी करने के लिए, पोर्टमैपर पोर्टमैप को इस सेवा के लिए पोर्ट प्राप्त करने के लिए संपर्क करना होगा। अब मेरे मामले में पोर्टमैपर का टीसीपी के माध्यम से संपर्क हो गया। पोर्टमैपर तब लिबक फ़ंक्शन को बताता है कि ऐसी कोई सेवा मौजूद नहीं है और टीसीपी कनेक्शन बंद हो जाता है। जैसा कि हम जानते हैं, कुछ समय के लिए बंद टीसीपी कनेक्शन TIME_WAIT स्थिति दर्ज करते हैं। लिस्ट करते समय नेटस्टैट इस कनेक्शन को पकड़ लेता है और नए IP के साथ यह नई लाइन एक नया अनुरोध जारी करता है जो TIME_WAIT राज्य में एक नया कनेक्शन उत्पन्न करता है और इसी तरह ...

इस समस्या को हल करने के लिए, एक /etc/nsswitch.conf बनाएं, जो कि निम्न सामग्री के साथ rpc NIS सेवाओं का उपयोग नहीं कर रहा है:

passwd:         files
group:          files
hosts:          files dns
networks:       files dns
services:       files
protocols:      files
netmasks:       files