বিশাল পরিমাণ TIME_WAIT সংযোগগুলি নেটস্পট বলে

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 কনফিগার আছে তাই এর কারণ কী হতে পারে তা আমার কোনও ধারণা নেই। কোন ধারনা?

ধন্যবাদ,

Tamas

সম্পাদনা করুন: 'নেটস্ট্যাট-আনপ' এর আউটপুট:

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" পোর্টম্যাপারের সাথে কী যোগাযোগ করছে তা সন্ধান করতে সহায়তা করতে পারে।

— সিস্টামস

উইন্ডোজ অধীনে বিলম্ব সামঞ্জস্য করার উপায় খুঁজতে গিয়ে যারা এখানে তাদের পথ খুঁজে পান, তাদের জন্য এটি একটি রেজিস্ট্রি সেটিংয়ের মাধ্যমে করা যেতে পারে ।

— সিনিটেক

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

এছাড়াও, আপনি আরপিসি পরিষেবা বা এনএফএস ব্যবহার না করলে আপনি কেবল এটি বন্ধ করতে পারেন:

/etc/init.d/nfsd stop

এবং এটি পুরোপুরি বন্ধ করুন

chkconfig nfsd off

Comments

হ্যাঁ আমার ipconfig স্ক্রিপ্টটি ইতিমধ্যে এটি 30 এ নামিয়েছে I আমার কাছে /etc/init.d/ এ এনএফএসডি নেই, তবে আমার পোর্টম্যাপ চলছে, এটি বন্ধ করে দেওয়া হয়েছে, এখন টিআইএমE_ওয়াইআইটিগুলি কয়েকটি ইভেন্টে নামানো হয়েছে (1-5)। ধন্যবাদ।

— কেটামাস

আহ, tcp_fin_timeout সময়_উইট অবস্থায় সকেটগুলির সাথে কিছু করার নেই। এটি ফিন_উইট_2 -কে অনুভব করে।

— ডিআইকি

ডায়িকের মন্তব্যের জন্য +1। তারা সম্পর্কিত নয়।

— এমএকিউথ

সঠিক ... আপনি সকেটগুলি 60 থেকে নিচে দেখতে পাবেন এমনকি tcp_fin_Toutout ব্যবহার করে পরিবর্তন করা হয়েছেss --numeric -o state time-wait dst 10.0.0.100

— গ্রেগ ব্রে

Answer 2

TIME_WAIT স্বাভাবিক। কোনও সকেট বন্ধ হয়ে যাওয়ার পরে, কার্নেল দ্বারা প্যাকেটগুলি ট্র্যাক করে রাখার জন্য ব্যবহার করা হয়েছিল যা হারিয়ে গেছে এবং পার্টিতে দেরীতে পরিণত হয়েছে। TIME_WAIT সংযোগের একটি সংখ্যক সংক্ষিপ্ত জীবন সংযোগ পাওয়ার লক্ষণ, উদ্বেগের কিছু নেই nothing

Comments

এই উত্তরটি সংক্ষিপ্ত এবং মিষ্টি। এটি অনেক সাহায্য করে। শেষ বাক্যটি আমাকে কিছুটা বিভ্রান্ত করেছিল, তবে আমি মনে করি মূল বিষয়টি হ'ল এত সংযোগ কেন তৈরি হচ্ছে তা আপনার বুঝতে হবে। আপনি যদি এমন কোনও ক্লায়েন্ট লিখছেন যা প্রচুর অনুরোধ উত্পন্ন করে, আপনি সম্ভবত এটি নিশ্চিত করতে চান যে প্রতিটি অনুরোধের জন্য নতুন তৈরি করার পরিবর্তে এটি বিদ্যমান সংযোগগুলি পুনরায় ব্যবহার করতে কনফিগার করা হয়েছে।

— নভেম্বর

সংক্ষিপ্ত ঘাম, সম্পূর্ণ নয়। TIME_WAITs প্রসঙ্গে নির্ভর করে। আপনার যদি তাদের অনেকগুলি থাকে তবে এটি হতে পারে যে কেউ আপনার সার্ভারটিতে আক্রমণ করছে।

— মিনডাগাস বার্নাটাভিয়াস

Answer 3

এটা গুরুত্বপূর্ণ নয়। সমস্ত কিছুই প্রমাণ করে যে আপনি প্রচুর সান আরসিপি টিসিপি সংযোগগুলি খুলছেন এবং বন্ধ করছেন (এর মধ্যে প্রতি 2-4 মিনিটে 1500-2500)। TIME_WAITরাষ্ট্র তারা যদি পারে সকেট খুব দ্রুত পুনঃব্যবহৃত করা হয়েছে, এবং অন্যান্য দরকারী উদ্দেশ্যে একটি দম্পতি জন্য ভুল অ্যাপ্লিকেশনের জন্য আসার থেকে বার্তা প্রতিরোধ, কি একটি সকেট যখন এটি বন্ধ মধ্যে যায় হয়। এটি সম্পর্কে চিন্তা করবেন না।

(অবশ্যই, যদি না আপনি আসলে এমন কোনও কিছু চালাচ্ছেন না যা অনেকগুলি আরসিপি অপারেশন প্রসেসিং করা উচিত Then তবে, চিন্তা করুন))

Comments

আমি বেশিরভাগ ক্ষেত্রে কুরিয়ার-ইমপ এবং পোস্টফিক্স চালাই।

— কেটিমাস

Answer 4

আপনার সিস্টেমে কিছু আপনার সিস্টেমে প্রচুর আরপিসি (রিমোট প্রক্রিয়া কল) করছে (উত্স এবং গন্তব্য উভয়ই লোকাল হোস্ট লক্ষ্য করুন)। এটি প্রায়শই এনএফএস মাউন্টগুলির জন্য লকডের জন্য দেখা যায় তবে আপনি এটি আরপিসি.স্ট্যাটডি বা আরপিসি.স্প্রে এর মতো অন্য আরপিসি কলগুলির জন্যও দেখতে পাবেন।

এই সকেটগুলি কারা খোলা আছে এবং এটি কী করছে তা দেখতে আপনি "lsof -i" ব্যবহার করার চেষ্টা করতে পারেন। এটা সম্ভবত নিরীহ।

Comments

সেখানে অস্বাভাবিক কিছু নয়, আমি পোর্টম্যাপের জন্য একটি টিসিপি *: সানরপিসি (LISTEN) দেখতে পাচ্ছি তবে অনুমান করি এটি স্বাভাবিক is

— কেটামাস

কারা সংযোগটি খুলছে তা না দেখা পর্যন্ত বারবার এটি চালিয়ে যান।

— পল টমলিন

netstat -epn --tcp আপনাকে একই তথ্য প্রদর্শন করবে। আপনি যদি এনএফএস ব্যবহার না করেন তবে আপনার কাছে সম্ভবত পোর্টম্যাপ ব্যবহারের খুব কম কারণ রয়েছে। আপনি এটি অপসারণ করতে পারে।

— ডেভিড প্যাশলে

আমি প্রকৃতপক্ষে এনএফএস ব্যবহার করি না, তবে এপটি-গেট রিমুভ পোর্টম্যাপটি 'ফ্যাম' মুছে ফেলতে চায় যা সম্ভবত স্বয়ংক্রিয়ভাবে লিবিফাম0 দ্বারা ইনস্টল করা হয়েছিল যা কুরিয়ার-ইম্যাপ দ্বারা ইনস্টল করা হয়েছিল। apt-cache বলে 'ফ্যাম' libfam0 এর জন্য প্রস্তাবিত প্যাকেজ।

— কেটামাস

Answer 5

tcp_fin_timeoutTIME_WAITবিলম্ব নিয়ন্ত্রণ করে না আপনি কাউন্টডাউন টাইমারগুলি দেখতে এস-এস বা নেটস্ট্যাট ব্যবহার করে দেখতে পারেন:

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_timeoutout 3 এ সেট করার পরেও TIME_WAIT এর কাউন্টডাউনটি এখনও 60 থেকে শুরু হয় However তবে আপনার যদি নেট.ipv4.tcp_tw_reuse 1 (এ সেট করা থাকে echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse) তবে কার্নেলটি TIME_WAIT এ সকেটগুলি পুনরায় ব্যবহার করতে পারে যদি এটি নির্ধারণ করে যে টিসিপিতে কোনও সম্ভাব্য দ্বন্দ্ব নেই won't বিভাগের নম্বর।

Answer 6

আমি খুব একই সমস্যা ছিল। কি চলছে তা জানতে আমার কয়েক ঘন্টা ব্যয় করেছে। আমার ক্ষেত্রে এর কারণ হ'ল নেটস্পট আইপি-র সাথে সম্পর্কিত হোস্টনামটি অনুসন্ধান করার চেষ্টা করে (আমি ধরে নিই যে এটি গেথস্টব্যাডডিআর এপিআই ব্যবহার করছে)। আমি একটি এম্বেড থাকা লিনাক্স ইনস্টলেশন ব্যবহার করছিলাম যার কোনও /etc/nsswitch.conf নেই। আমার আশ্চর্যের বিষয় হল, সমস্যাটি কেবল তখনই বিদ্যমান যখন আপনি প্রকৃতপক্ষে নেটস্পট করছেন - (ভার্বোস এবং ডিবাগ মোডে পোর্টম্যাপ চালিয়ে এটি খুঁজে পেয়েছেন)।

এখন যা ঘটেছে তা হ'ল: পূর্বনির্ধারিত অনুসারে, অনুসন্ধানের ফাংশনগুলি হোস্ট নেমটির অনুসন্ধানের জন্য ypbind ডেমন (সান ইয়েলো পেজ, যা এনআইএস নামে পরিচিত) এর সাথে যোগাযোগ করার চেষ্টা করে। এই পরিষেবাটি জিজ্ঞাসা করতে, এই পরিষেবাটির জন্য পোর্টটি পেতে পোর্টম্যাপার পোর্টম্যাপের সাথে যোগাযোগ করতে হবে। এখন আমার ক্ষেত্রে পোর্টম্যাপার টিসিপির মাধ্যমে যোগাযোগ করেছিলেন। এর পরে পোর্টম্যাপার libc ফাংশনটিকে বলে যে এরূপ কোনও পরিষেবা উপস্থিত নেই এবং টিসিপি সংযোগ বন্ধ হয়ে যায়। যেমনটি আমরা জানি, বন্ধ টিসিপি সংযোগগুলি কিছু সময়ের জন্য একটি TIME_WAIT রাজ্যে প্রবেশ করে। সুতরাং নেটস্পট তালিকাবদ্ধকরণের সময় এই সংযোগটি ধরবে এবং একটি নতুন আইপি সহ এই নতুন লাইনটি একটি নতুন অনুরোধ জারি করে যা TIME_WAIT রাজ্যে এবং একটি নতুন সংযোগ উত্পন্ন করে ...

এই সমস্যাটি সমাধান করার জন্য, একটি /etc/nsswitch.conf তৈরি করুন যা আরপিসি এনআইএস পরিষেবা ব্যবহার করে না নিচের বিষয়বস্তু সহ:

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