netstat에 따르면 TIME_WAIT 연결의 엄청난 양

좋아, 이것은 나를 오싹하고있다-나는 약 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   -               

편집 : tcp_fin_timeout 은 TIME_WAIT 기간을 제어 하지 않으며 60 초에 하드 코딩됩니다.

다른 사람들이 언급했듯이 일부 연결 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 연결을 열고 닫는 것입니다 (2-4 분마다 1500-2500 개). TIME_WAIT그들이 소켓이 너무 빨리 재사용 및 기타 유용한 목적으로 몇되었다 수있는 경우와 같은 상태는 잘못된 애플리케이션에 도착하는 메시지를 방지하기 위해, 소켓이 닫힐 때 들어가는 것입니다. 걱정하지 마십시오.

(물론, 실제로 많은 RCP 작업을 처리해야하는 작업을 실행하지 않는 한 걱정할 필요는 없습니다.)

시스템의 무언가가 시스템 내에서 많은 RPC (원격 프로 시저 호출)를 수행하고 있습니다 (소스와 대상이 모두 localhost임을 알 수 있습니다). NFS 마운트에 대해 잠금 상태 인 경우가 종종 있지만 rpc.statd 또는 rpc.spray와 같은 다른 RPC 호출에서도 볼 수 있습니다.

"lsof -i"를 사용하여 누가 소켓을 열 었는지, 무슨 일을하는지 볼 수 있습니다. 아마 무해합니다.

tcp_fin_timeoutTIME_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)로 설정하면 커널은 TCP에서 충돌이 없을 것으로 판단되면 TIME_WAIT에서 소켓을 재사용 할 수 있습니다 세그먼트 넘버링.

나도 같은 문제가 있었다. 무슨 일인지 알기 위해 몇 시간이 걸렸습니다. 필자의 경우 netstat가 IP에 해당하는 호스트 이름을 찾으려고 시도했기 때문입니다 (gethostbyaddr API를 사용한다고 가정합니다). /etc/nsswitch.conf가없는 임베디드 Linux 설치를 사용하고있었습니다. 놀랍게도 실제로 netstat -a를 수행 할 때만 문제가 발생합니다 (verbose 및 디버그 모드에서 portmap을 실행하여이를 발견했습니다).

이제는 다음과 같은 상황이 발생했습니다. 기본적으로 조회 기능은 호스트 이름을 조회하기 위해 ypbind 데몬 (Sun Yellow Pages, NIS라고도 함)에 접속하려고합니다. 이 서비스를 쿼리하려면이 서비스의 포트를 얻기 위해 portmapper 포트 맵에 접속해야합니다. 이제 필자의 경우 portmapper가 TCP를 통해 연결되었습니다. 그런 다음 portmapper는 libc 함수에 해당 서비스가 없으며 TCP 연결이 닫 혔음을 알려줍니다. 아시다시피, 닫힌 TCP 연결은 얼마 동안 TIME_WAIT 상태가됩니다. 따라서 netstat는 나열 할 때이 연결을 포착하고 새로운 IP가있는이 새로운 라인은 TIME_WAIT 상태 등에서 새로운 연결을 생성하는 새로운 요청을 발행합니다 ...

이 문제를 해결하려면 rpc NIS 서비스를 사용하지 않는 /etc/nsswitch.conf를 작성하십시오 (예 : 다음 내용).

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