การเชื่อมต่อ TIME_WAIT จำนวนมากบอกว่า netstat

โอเคสิ่งนี้กำลังคืบคลานออกไป - ฉันเห็นสิ่งเหล่านี้ประมาณ 1,500-25,000

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

แก้ไข: ผลลัพธ์ของ '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   -               

แก้ไข: tcp_fin_timeout ไม่ได้ควบคุมระยะเวลา TIME_WAIT มันฮาร์ดโค้ดที่ 60s

ตามที่ผู้อื่นกล่าวถึงการมีการเชื่อมต่อบางอย่างTIME_WAITเป็นส่วนปกติของการเชื่อมต่อ TCP คุณสามารถดูช่วงเวลาโดยตรวจสอบ/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

TIME_WAIT เป็นเรื่องปกติ เป็นสถานะหลังจากซ็อกเก็ตปิดใช้โดยเคอร์เนลเพื่อติดตามแพ็คเก็ตซึ่งอาจสูญหายและเปิดสายไปงานเลี้ยง จำนวนการเชื่อมต่อ TIME_WAIT จำนวนมากเป็นอาการของการเชื่อมต่อระยะสั้นจำนวนมากไม่ต้องกังวล

มันไม่สำคัญ สิ่งที่บ่งบอกว่าคุณกำลังเปิดและปิดการเชื่อมต่อ Sun RCP TCP จำนวนมาก (1500-2500 การเชื่อมต่อทุก 2-4 นาที) TIME_WAITรัฐคือสิ่งที่ซ็อกเก็ตไปลงในเมื่อมันปิดเพื่อป้องกันไม่ให้ข้อความจากที่เดินทางมาถึงสำหรับการใช้งานที่ไม่ถูกต้องเช่นที่พวกเขาอาจจะถ้าซ็อกเก็ตที่ถูกนำมาใช้ใหม่ได้อย่างรวดเร็วเกินไปและสำหรับคู่ของวัตถุประสงค์ที่มีประโยชน์อื่น ๆ ไม่ต้องกังวลกับมัน

(เว้นแต่คุณจะไม่ได้ใช้งานจริงใด ๆ ที่ควรประมวลผลการปฏิบัติการ RCP หลายอย่างแล้วไม่ต้องกังวล)

มีบางอย่างในระบบของคุณกำลังทำ RPC จำนวนมาก (การเรียกขั้นตอนระยะไกล) ภายในระบบของคุณ (สังเกตว่าทั้งต้นทางและปลายทางคือ localhost) มักจะเห็นสำหรับ lockd สำหรับการเมานต์ NFS แต่คุณอาจเห็นมันสำหรับการโทร RPC อื่น ๆ เช่น rpc.statd หรือ rpc.spray

คุณสามารถลองใช้ "lsof -i" เพื่อดูว่าใครมีซ็อกเก็ตเปิดอยู่และดูว่ากำลังทำอะไรอยู่ มันอาจไม่เป็นอันตราย

tcp_fin_timeoutไม่ได้ควบคุมTIME_WAITความล่าช้า คุณสามารถดูได้โดยใช้ ss หรือ netstat ด้วย -o เพื่อดูตัวนับถอยหลัง:

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 การกำหนดหมายเลขส่วน

ฉันมีปัญหาเดียวกันด้วย ฉันเสียค่าใช้จ่ายหลายชั่วโมงเพื่อดูว่าเกิดอะไรขึ้น ในกรณีของฉันเหตุผลนี้คือ netstat พยายามค้นหาชื่อโฮสต์ที่สอดคล้องกับ IP (ฉันถือว่ามันใช้ gethostbyaddr API) ฉันใช้การติดตั้ง Linux ในตัวซึ่งไม่มี /etc/nsswitch.conf ความประหลาดใจของฉันมีปัญหาเฉพาะเมื่อคุณกำลังทำ netstat -a เท่านั้น (พบสิ่งนี้โดยการเรียกใช้ portmap ในโหมด verbose และ debug)

ตอนนี้สิ่งที่เกิดขึ้นคือต่อไปนี้: ตามค่าเริ่มต้นฟังก์ชั่นการค้นหายังพยายามติดต่อ ypbind daemon (Sun Yellow Pages หรือที่รู้จักกันในนาม NIS) เพื่อสอบถามชื่อโฮสต์ ในการสอบถามบริการนี้ต้องมีการติดต่อ portmapper portmap เพื่อรับพอร์ตสำหรับบริการนี้ ตอนนี้ตัวจัดการพอร์ตในกรณีของฉันได้รับการติดต่อผ่าน TCP จากนั้น portmapper จะบอกฟังก์ชัน libc ว่าไม่มีบริการดังกล่าวและการเชื่อมต่อ TCP ถูกปิด อย่างที่เราทราบการเชื่อมต่อ TCP แบบปิดจะเข้าสู่สถานะ TIME_WAIT ในบางครั้ง ดังนั้น netstat จะจับการเชื่อมต่อนี้เมื่อมีรายการและบรรทัดใหม่นี้ที่มี IP ใหม่ออกคำขอใหม่ที่สร้างการเชื่อมต่อใหม่ในสถานะ TIME_WAIT และอื่น ๆ ...

เพื่อที่จะแก้ปัญหานี้ให้สร้าง /etc/nsswitch.conf ซึ่งไม่ได้ใช้บริการ rpc NIS เช่นกับเนื้อหาต่อไปนี้:

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