TCP TIME_WAIT가 정상 종료 상태인 경우와 실제 연결·포트 고갈 문제를 어떻게 구분하고 개선하나요?

TIME_WAIT는 TCP 연결을 능동적으로 종료한 끝점에 일정 기간 남는 정상 상태입니다. 지연된 이전 세그먼트가 같은 주소·포트 조합의 새 연결에 섞이지 않게 하고, 마지막 종료 응답을 재전송할 시간을 확보합니다. TIME_WAIT는 애플리케이션이 계속 보유한 파일 디스크립터나 아직 열린 소켓이라는 뜻이 아니므로, 개수가 많다는 사실만으로 소켓 누수라고 하지 않겠습니다. 실제 문제는 연결 생성률과 임시 포트·파일 디스크립터 고갈이 서비스 오류로 이어지는지입니다.

정상 상태와 close 누락을 구분한다

짧은 HTTP 요청마다 새 TCP 연결을 만들면 능동 종료한 쪽에 TIME_WAIT가 빠르게 쌓일 수 있습니다. 어느 쪽에 많이 보인다는 사실만으로 클라이언트가 원인이라고 단정하지 않고, 양 끝점의 종료 방향과 연결 생성·종료 경로를 확인합니다. CLOSE_WAIT는 상대가 종료한 뒤 로컬 애플리케이션이 아직 close하지 않은 상태이지만, 잠시 존재한다고 무조건 누수는 아닙니다. 지속 증가하거나 정상 시간 안에 종료되지 않을 때 close 누수를 의심하겠습니다. 이를 종료 후 순서 보호 상태(TIME_WAIT)와 종료 처리 지연(CLOSE_WAIT)의 구분으로 진단합니다.

관찰할 값은 TIME_WAIT 수뿐 아니라 로컬·원격 주소 분포, 능동 종료 주체, 생성·종료율, 임시 포트 사용률, 새 연결 실패 오류, 파일 디스크립터, 연결 재사용률입니다. NAT·방화벽 상태 테이블이 먼저 찰 수도 있으므로 OS 소켓 목록 하나로 원인을 확정하지 않습니다. 새 연결 실패가 없으면 높은 TIME_WAIT 수는 관찰 대상일 뿐 장애 증거가 아닙니다.

재사용과 안전한 개선

keep-alive와 HTTP 연결 풀은 handshake·종료 횟수를 줄여 TIME_WAIT 생성률을 낮출 수 있습니다. HTTP/2 다중화도 연결 수를 줄일 수 있지만 한 연결의 손실 영향과 스트림 한도를 함께 확인합니다. 유휴 연결은 상대 서버·로드밸런서·NAT가 먼저 닫을 수 있으므로 재사용 시 첫 요청이 실패할 수 있고, 상태를 변경했을 가능성이 있는 요청을 무조건 재시도하지 않습니다.

TIME_WAIT 대기 시간을 무작정 줄이거나 위험한 재사용 옵션을 켜지 않고, 먼저 실제 연결 재사용률과 포트 고갈 증거를 확인합니다. 연결 최대·유휴 수명, 재연결 분산, 하위 서비스 연결 한도를 조정한 뒤 사용자 p99와 신규 연결 실패가 함께 개선되는지 봅니다. 목표는 TIME_WAIT를 0으로 만드는 것이 아니라 프로토콜의 종료 보호를 유지하면서 불필요한 단기 연결과 실제 자원 고갈을 줄이는 것입니다.

추가 조건과 판단

TCP 연결은 로컬 주소·포트와 원격 주소·포트의 조합으로 구분됩니다. 같은 목적지에 초당 많은 연결을 만들면 사용 가능한 로컬 임시 포트와 재사용 규칙이 한계가 될 수 있지만, TIME_WAIT 개수를 호스트 전체 포트 범위와 단순 비교해서는 안 됩니다. 목적지 분포와 NAT의 변환 자원도 결과를 바꾸기 때문입니다. 파일 디스크립터 사용량은 살아 있는 애플리케이션 소켓의 별도 지표로 측정하고 TIME_WAIT 항목마다 FD 하나가 남았다고 계산하지 않겠습니다.

정상 종료에서 마지막 ACK가 유실되면 상대가 FIN을 다시 보낼 수 있습니다. TIME_WAIT는 이 재전송에 응답하고 과거 세그먼트가 새 연결과 섞일 가능성을 줄이는 시간적 보호입니다. 동시 종료에서는 양쪽에 TIME_WAIT가 생길 수도 있으므로 누가 먼저 종료했는지 실제 상태 전이를 봐야 합니다. 재사용 정책을 바꿀 때는 플랫폼 버전과 TCP timestamp·중간 장치의 조건을 확인하되, 운영 오류가 없다면 단순히 상태 수를 줄이기 위해 위험을 추가하지 않겠습니다.