H/W가 조용하다 싶더니,,
이번에는 네트워크에 문제가 생겼습니다.

close_wait 상태의 특정 포트가 만 건이 넘게 생성되버려서 탑재되어 있는 시스템의
통신이 중간 중간 끊기는 문제가 발생하였습니다. 이상한건 포트 생성날짜가 모두 동일하다는거..

서버와 클라이언트 통신 중에 클라이언트가 비정상적으로 종료되면 서버가 이를 인지하지 못하고
해당 포트를 계속 붙잡고 있는듯 하네요.. 툴을 이용하여 close_wait 상태의 포트를 모두 닫아 급히
해결은 하였는데,, 동일한 문제가 또 발생할까봐.. 걱정입니다.




출처:
http://twopairs.tistory.com/45


CLOSE WAIT 문제




현상
종종 서버에 close wait이 지속적으로 발생하여서 was 혹은 daemon이 panic상태에 빠지는 현상이 있다. was에서의 발생형태는 traffic이 증가함에따라 was의 모든 가용 thread 혹은 process의 network resource(socket)가 CLOSE_WAIT 상태로 변하여서 더 이상 서비스를 할 수 없는 형태가 되고 daemon에서는 daemon의 구현에 따라 다르지만 traffic이 몰릴 때 close wait이 지속적으로 무한대를 향하여 증가하거나 혹은 child process 그리고 child thread가 제한 되어 있는 경우는 가용한 process 혹은 thread의 network resource인 socket의 상태가 close wait으로 모두 변해 버린다.


원인
close wait현상이 발생할 때 가장 먼저 생각할 점은 다음과 같다.
서버에서 CLOSE WAIT이 발생한 이유는 클라이언트에서 먼저 FIN을 보냈기 때문이다.


해결책
서버에서 클라이언트로부터 예기치 못한 FIN을 받았을 때 과연 어떤 상태에 있을 수 있는지를 모든 가능성을 검사해 보아야 한다.


1번 해결책
CLOSE WAIT은 client가 먼저 fin을 보내면 서버의 os에서 ack를 보낸 이후 서버의 어플리케이션에서 close 를 호출하지 않아서 발생한다. 그러므로 예외사항이 발생할 경우 close 를 호출하지 않는지를 검사해야 한다.


2번 해결책
서버와 클라이언트 사이에 L4가 끼어 있을 경우 그리고 L4에서 성능상의 이유로 Timeout(어느 한쪽에서 FIN을 먼저 보냈다면 X초가 지난 후 세션 테이블에서 삭제한다.)을 설정하지 않았는지를 확인하자. Timeout시간이 적당하지 않으면 서버가 FIN을 보내기 전에 혹은 서버에서 FIN에 대한 응답으로 Data를 보냈다 하더라도 클라이언트에서 RST를 보내어서 연결을 종료하기 전에 L4에서 해당연결을 세션테이블에서 삭제하기 때문에 서버는 계속 Data 혹은 FIN을 재전송하려하고 클라이언트에서는 FIN 을 기다리는 상황이 발생할 수도 있다.


3번...
아직까지는 이 2가지 밖에 경험해 보지 못했다.



': Network' 카테고리의 다른 글

Port Numbers  (0) 2011.01.03
TCP Port 리스트  (0) 2011.01.03
ROUTER(시스코) 명령어 모음  (0) 2011.01.03
GBIC (Gigabit Interface Converter)  (0) 2011.01.03
UTP 케이블  (0) 2011.01.03

+ Recent posts