CLOSE_WAIT 과 TIME_WAIT

개요

서버의 CPU 등 리소스와는 별개로 LB, Nginx 등을 사용하다 보면 클라이언트단에서 문제가 발생하는 경우가 있을 수 있다는 것을 깨닫고 CLOSE_WAIT과 TIME_WAIT에 대해 알아보고자 합니다.

 

 

TCP Connection

TCP 상태 전이 다이어그램

 

 

위의 다이어그램에서는 Server가 CLOSE_WAIT를 보냅니다.

다만 서버가 먼저 종료하겠다고 FIN을 보내는 경우에는 클라이언트에서 CLOSE_WAIT을 가지게 됩니다.

CLOSE_WAIT을 벗어나려면 애플리케이션에 명시적으로 프로세스를 종료하는방법밖에 없습니다.

 

실제 서버에서 CLOSE_WAIT이 발생하는 원인

JVM의 THhread Dumps를 분석한 결과, 대부분의 쓰레드가 검색 결과를 받아오지 못하고 WAITING중이었습니다.

해당 결과는 로컬에서 받아와야 했고, 로컬은 행업 상태여서 검색 결과를 보내주지 못하는 상황이었습니다.

즉, 서로 보내거나 받을 수 없는 교착상태에 빠지게 되었습니다.

 

1. 파일서버가 필요해 별도 웹 서버를 구성하지 않고 톰캣의 /ROOT 이용

2. Static HTML 파일을 올려두고 톰캣에서 구독 중인 웹앱의 HTTPClient에 로컬 자기 자신을 호출해 HTML를 받아가도록 구성

3. 부하를 높이니 점점 느려지다 HTML 조차 내려주지 못하는 행업 상태발생

4. 모든 소켓이 CLOSE_WAIT 상태에 빠짐

 

CLOSE_WAIT 해결

별도 서버를 구성하여 상호 의존성 없이 호출가능하도록 구성하여 해결

 

TIME_WAIT란?

TCP의 가장 마지막 단계이며 먼저 close() 요청한 곳에서 최종적으로 남게 됩니다.

TIME_WAIT은 2*MSL(Maximum Segment Lifetime) 동안 유지됩니다.

보통 소켓을 로우레벨로 다루지 않고 추상화해서 사용하다 보니 확인할 일이 흔치 않습니다.

이러한 사유로 만약 같은 주소, 같은 포트에서 다른 소켓이 bind() 요청을 하게 되면 에러가 발생합니다.

 

TIME_WAIT 상태가 필요한 이유

첫 번째로 지연 패킷이 발생하는 경우에 이미 다른 연결이 진행되었지만 지연 패킷이 추후에 도달할 수 있습니다.

매우 드문 경우지만 SEQ까지 동일하다면 잘못된 데이터를 처리하게 됩니다.

 

두 번째로 원격 종단의 연결이 닫혔는지 확인해야 할 경우입니다.

ACK 유실 시 상대방은 LAST_ACK 상태에 빠지게 되고 새로운 SYN 패킷 전달 시 RST를 리턴합니다.

새로운 연결을 오류를 내며 실패합니다.

따라서 TIME_WAIT이 일정 시간 남아 있어 패킷의 오동작을 막아야 합니다.

 

 

 

 

참고자료

https://tech.kakao.com/2016/04/21/closewait-timewait/

CLOSE_WAIT & TIME_WAIT 최종 분석