Số lượng lớn kết nối TIME_WAIT cho biết netstat

Được rồi, điều này đang làm tôi thất vọng - tôi thấy khoảng 1500-2500 trong số này:

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

Con số đó đang thay đổi nhanh chóng.

Tôi có một cấu hình iptables khá chặt chẽ vì vậy tôi không biết điều gì có thể gây ra điều này. có ý kiến ​​gì không

Cảm ơn,

Tamas

Chỉnh sửa: Đầu ra của '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   -               

EDIT: tcp_fin_timeout KHÔNG kiểm soát thời gian TIME_WAIT, nó được mã hóa ở 60 giây

Như đã đề cập bởi những người khác, có một số kết nối TIME_WAITlà một phần bình thường của kết nối TCP. Bạn có thể thấy khoảng thời gian bằng cách kiểm tra /proc/sys/net/ipv4/tcp_fin_timeout:

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

Và thay đổi nó bằng cách sửa đổi giá trị đó:

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

Hoặc vĩnh viễn bằng cách thêm nó vào /etc/sysctl.conf

net.ipv4.tcp_fin_timeout=30

Ngoài ra, nếu bạn không sử dụng dịch vụ RPC hoặc NFS, bạn có thể tắt nó đi:

/etc/init.d/nfsd stop

Và tắt nó hoàn toàn

chkconfig nfsd off

TIME_WAIT là bình thường. Đó là trạng thái sau khi ổ cắm đã đóng, được sử dụng bởi kernel để theo dõi các gói có thể bị mất và bị trễ trong bữa tiệc. Số lượng lớn các kết nối TIME_WAIT là một triệu chứng của việc nhận được nhiều kết nối ngắn, không có gì phải lo lắng.

Nó không quan trọng. Tất cả những gì có nghĩa là bạn đang mở và đóng rất nhiều kết nối TCP RC RC (1500-2500 trong số chúng sau mỗi 2-4 phút). Các TIME_WAITnhà nước là những gì một ổ cắm đi vào khi nó đóng cửa, để ngăn chặn tin nhắn từ đến cho các ứng dụng sai như họ có thể nếu các ổ cắm được tái sử dụng quá nhanh, và cho một vài mục đích hữu ích khác. Đừng lo lắng về nó.

(Tất nhiên trừ khi bạn thực sự không chạy bất cứ thứ gì nên xử lý nhiều hoạt động RCP đó. Vậy thì, hãy lo lắng.)

Một cái gì đó trên hệ thống của bạn đang thực hiện rất nhiều RPC (Cuộc gọi thủ tục từ xa) trong hệ thống của bạn (chú ý cả nguồn và đích là localhost). Điều đó thường thấy đối với lockd cho các mount NFS, nhưng bạn cũng có thể thấy nó cho các cuộc gọi RPC khác như rpc.statd hoặc rpc.spray.

Bạn có thể thử sử dụng "lsof -i" để xem ai mở các ổ cắm đó và xem những gì đang làm điều đó. Nó có lẽ vô hại.

tcp_fin_timeoutKHÔNG kiểm soát TIME_WAITđộ trễ. Bạn có thể thấy điều này bằng cách sử dụng ss hoặc netstat với -o để xem bộ đếm thời gian đếm ngược:

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)

ngay cả với tcp_fin_timeout được đặt thành 3, việc đếm ngược cho TIME_WAIT vẫn bắt đầu ở mức 60. Tuy nhiên, nếu bạn có net.ipv4.tcp_tw_Vuse được đặt thành 1 ( echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse) thì kernel có thể sử dụng lại các socket trong TIME_WAIT nếu nó xác định sẽ không có xung đột nào trong TCP đánh số phân khúc.

Tôi cũng gặp vấn đề tương tự. Tôi mất vài giờ để tìm hiểu chuyện gì đang xảy ra. Trong trường hợp của tôi, lý do cho điều này là netstat cố gắng tra cứu tên máy chủ tương ứng với IP (Tôi giả sử nó sử dụng API gethostbyaddr). Tôi đã sử dụng một bản cài đặt Linux nhúng không có /etc/nsswitch.conf. Thật ngạc nhiên, vấn đề chỉ tồn tại khi bạn thực sự đang thực hiện một netstat -a (tìm ra vấn đề này bằng cách chạy portmap ở chế độ dài và gỡ lỗi).

Bây giờ những gì đã xảy ra như sau: Mỗi mặc định, các chức năng tra cứu cũng cố gắng liên hệ với trình nền ypbind (Trang vàng mặt trời, còn được gọi là NIS) để truy vấn tên máy chủ. Để truy vấn dịch vụ này, phải liên hệ với sơ đồ portmapper để lấy cổng cho dịch vụ này. Bây giờ portmapper trong trường hợp của tôi đã được liên lạc qua TCP. Sau đó, portmapper nói với hàm libc rằng không có dịch vụ như vậy tồn tại và kết nối TCP bị đóng. Như chúng ta đã biết, các kết nối TCP đã đóng sẽ chuyển sang trạng thái TIME_WAIT trong một thời gian. Vì vậy, netstat bắt được kết nối này khi liệt kê và dòng mới này với IP mới đưa ra một yêu cầu mới tạo ra kết nối mới ở trạng thái TIME_WAIT, v.v.

Để giải quyết vấn đề này, hãy tạo /etc/nsswitch.conf không sử dụng dịch vụ NIS rpc tức là với các nội dung sau:

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