TCP TIME_WAIT 상태가 대량 접속 서버의 포트 고갈을 일으키는 원리

TCP 통신과 TIME_WAIT 상태의 이해

인터넷을 통해 데이터를 주고받을 때 우리는 매 순간 TCP라는 통신 규약을 사용합니다. TCP는 연결 지향형 프로토콜로, 데이터를 안전하게 전달하기 위해 통신을 시작할 때 핸드셰이크 과정을 거치고 통신이 끝날 때도 연결을 정리하는 절차를 수행합니다. 이때 연결을 종료하는 과정에서 발생하는 상태가 바로 TIME_WAIT입니다.

많은 분이 서버를 운영하거나 네트워크 설정을 다룰 때 갑자기 연결이 거부되는 현상을 경험합니다. 이때 서버 상태를 확인해보면 수많은 연결이 TIME_WAIT 상태로 머물러 있는 것을 볼 수 있습니다. 왜 서버는 통신이 끝난 연결을 즉시 삭제하지 않고 잠시 붙들고 있을까요? 이는 네트워크의 신뢰성을 보장하기 위한 필수적인 안전장치이기 때문입니다.

TIME_WAIT가 존재하는 이유와 원리

TCP 연결을 종료할 때 클라이언트와 서버는 서로에게 연결을 끊겠다는 신호를 보냅니다. 마지막으로 연결을 종료하는 쪽, 즉 능동적으로 종료 절차를 수행한 쪽은 연결 정보를 즉시 삭제하지 않고 일정 시간 동안 TIME_WAIT 상태를 유지합니다.

유지 시간은 운영체제와 TCP 구현에 따라 다르지만 일반적으로 수십 초에서 수분 정도 지속될 수 있습니다.

TIME_WAIT가 필요한 이유는 크게 두 가지입니다. 첫 번째는 지연된 패킷을 처리하기 위해서입니다. 네트워크 환경이 불안정하면 연결이 종료된 뒤 이전 연결에서 전송된 패킷이 늦게 도착할 수 있습니다.

이전 연결의 흔적을 즉시 지우고 동일한 주소와 포트 조합으로 새로운 연결을 맺으면, 뒤늦게 도착한 과거의 데이터가 새로운 연결의 데이터로 잘못 인식될 가능성이 있습니다. TIME_WAIT는 이전 연결에서 발생한 패킷이 네트워크상에서 충분히 사라질 때까지 기다리는 역할을 합니다.

두 번째는 연결 종료를 확정하기 위해서입니다. 마지막으로 보낸 종료 확인 패킷이 상대방에게 제대로 전달되지 않으면 상대방은 종료 패킷을 다시 전송할 수 있습니다. 이때 응답하려면 이전 연결에 대한 정보를 일정 시간 유지해야 합니다.

처음 서버의 연결 상태를 확인했을 때 TIME_WAIT가 수천 개씩 쌓여 있는 모습을 보면 문제가 발생한 것처럼 느껴질 수 있습니다. 그러나 개수 자체만으로 장애라고 판단하기보다는 새로운 연결이 정상적으로 생성되는지, 임시 포트가 얼마나 남아 있는지를 함께 확인하는 편이 정확합니다.

포트 고갈 문제의 실체

서버가 감당할 수 있는 연결 수는 무한하지 않습니다. TCP 연결은 출발지 IP, 출발지 포트, 목적지 IP, 목적지 포트라는 네 가지 요소의 조합으로 식별됩니다.

서버가 특정 포트에서 서비스를 제공하고 있다면 클라이언트의 IP와 포트가 달라질 때마다 서로 다른 연결로 구분할 수 있습니다. 하지만 서버가 외부 API를 호출하거나 마이크로서비스 사이에서 요청을 보낼 때는 서버 자체가 클라이언트 역할을 하게 됩니다.

이때 서버는 외부 연결을 생성하기 위해 임시 포트(Ephemeral Port)를 사용합니다. 사용할 수 있는 임시 포트의 범위는 운영체제 설정에 따라 제한되어 있으며, 리눅스 환경에서는 32768번부터 60999번 사이로 설정된 경우가 많습니다.

초당 수천 건의 요청을 처리하는 서버가 요청마다 새로운 연결을 만들고 바로 종료하면, 종료된 연결들이 TIME_WAIT 상태로 남아 임시 포트를 점유합니다. 이 과정이 반복되면 새로운 연결에 할당할 포트가 부족해지고 결국 외부 API나 다른 서비스에 접속하지 못하는 포트 고갈 현상이 발생할 수 있습니다.

장애를 점검할 때 CPU와 메모리 사용률이 정상인데도 외부 연결만 간헐적으로 실패하는 경우가 있습니다. 이때 애플리케이션 로그만 보면 상대 서버의 문제처럼 보일 수 있지만, 서버 내부의 TIME_WAIT 수와 임시 포트 범위를 확인하면 원인이 포트 고갈에 있었던 상황도 발견할 수 있습니다.

포트 고갈을 유발하는 주요 상황

단기 연결을 반복하는 마이크로서비스 구조

서비스 사이의 요청마다 새로운 TCP 연결을 생성하고 종료하면 TIME_WAIT 소켓이 빠르게 증가할 수 있습니다. 호출 빈도가 높은 구조일수록 연결 재사용 여부가 중요합니다.

외부 API 호출마다 연결을 새로 만드는 경우

결제, 인증, 메시지 전송과 같은 외부 API를 호출할 때 HTTP 클라이언트를 요청마다 새로 생성하면 연결도 반복적으로 만들어질 수 있습니다.

서버에서 외부로 대량의 요청을 보내는 경우

크롤링, 데이터 수집, 알림 전송처럼 서버가 클라이언트 역할로 대량의 연결을 만드는 작업에서도 임시 포트가 빠르게 소모될 수 있습니다.

임시 포트 범위가 지나치게 좁은 경우

운영체제에서 사용할 수 있는 임시 포트 범위가 좁게 설정돼 있다면 비교적 적은 연결만으로도 포트 고갈이 발생할 수 있습니다.

포트 고갈 문제를 해결하는 실용적인 방법

포트 고갈 문제를 해결하려면 단순히 TIME_WAIT 시간을 줄이기보다 연결을 생성하고 종료하는 방식부터 점검해야 합니다. 가장 효과적인 방법은 기존 연결을 재사용하는 것입니다.

연결 풀링 사용하기

데이터베이스 연결이나 외부 API 호출 시 매번 새로운 연결을 생성하지 말고 미리 만들어둔 연결을 재사용하는 커넥션 풀(Connection Pool)을 사용하는 것이 좋습니다.

기존 연결을 재사용하면 TCP 연결의 생성과 종료 횟수가 줄어들고, TIME_WAIT 상태로 들어가는 소켓의 수도 크게 감소합니다. 연결을 반복해서 만드는 데 필요한 CPU 부하와 지연 시간도 함께 줄일 수 있습니다.

다만 연결 풀의 크기를 무조건 크게 설정해서는 안 됩니다. 너무 많은 연결을 계속 유지하면 상대 서버와 로드밸런서에 부담을 줄 수 있으므로 실제 동시 요청량과 대기 시간을 기준으로 조정해야 합니다.

HTTP Keep-Alive 설정

웹 서버와 클라이언트 사이의 통신이라면 HTTP Keep-Alive 기능을 활용해야 합니다. 하나의 TCP 연결을 통해 여러 번의 HTTP 요청과 응답을 처리할 수 있어 연결 생성과 종료 횟수를 크게 줄일 수 있습니다.

Keep-Alive가 활성화돼 있어도 애플리케이션이 HTTP 클라이언트를 요청마다 새로 만들면 연결 재사용이 제대로 이루어지지 않을 수 있습니다. 설정만 확인하지 말고 실제 코드에서 클라이언트 객체와 연결 풀이 재사용되는지도 함께 살펴봐야 합니다.

커널 파라미터 최적화

리눅스 서버 환경에서는 운영체제 수준에서 TIME_WAIT 소켓과 임시 포트 범위를 관리하는 파라미터를 조정할 수 있습니다. 다만 커널 설정 변경은 애플리케이션의 연결 구조를 점검한 뒤 보조적인 수단으로 사용해야 합니다.

net.ipv4.tcp_tw_reuse는 일정한 조건에서 TIME_WAIT 상태의 소켓을 새로운 외부 연결에 재사용하도록 허용하는 설정입니다. 포트 고갈을 완화하는 데 도움이 될 수 있지만, 커널 버전과 네트워크 환경에 따라 동작 방식이 다를 수 있으므로 적용 전 검증이 필요합니다.

net.ipv4.ip_local_port_range는 서버가 외부 연결을 만들 때 사용할 수 있는 임시 포트 범위를 지정합니다. 포트 범위를 넓히면 동시에 사용할 수 있는 연결 조합이 증가하지만, 연결을 과도하게 생성하는 구조 자체가 해결되는 것은 아닙니다.

흔한 오해와 사실 관계

많은 개발자가 TIME_WAIT를 무조건 나쁜 상태로 오해하고 이를 강제로 즉시 제거하려고 합니다. 하지만 TIME_WAIT는 TCP 통신의 무결성을 유지하기 위한 정상적인 상태입니다.

과거에 사용되던 tcp_tw_recycle 설정은 NAT 환경에서 연결 오류를 일으킬 수 있어 현재 리눅스 커널에서는 제거되었습니다. 인터넷 이용자나 여러 장비가 하나의 공인 IP를 공유하는 환경에서는 패킷 타임스탬프를 잘못 판단해 정상적인 연결까지 거부할 수 있었기 때문입니다.

또 다른 오해는 TIME_WAIT가 서버 메모리를 과도하게 점유한다는 것입니다. 현대 운영체제는 많은 수의 TIME_WAIT 소켓을 비교적 효율적으로 관리합니다. 일반적인 환경에서는 메모리 부족보다 임시 포트 고갈이나 연결 생성 비용이 먼저 문제가 될 가능성이 높습니다.

따라서 TIME_WAIT 개수를 무조건 줄이는 것보다 현재 임시 포트 사용률과 연결 재사용 여부를 먼저 확인하는 것이 효율적입니다.

전문가의 조언

대규모 트래픽을 처리하는 시스템을 설계할 때 중요한 것은 연결을 만들지 않는 것이 아니라 연결의 전체 생명주기를 효율적으로 관리하는 것입니다.

초보 개발자는 주로 요청을 보내고 응답을 받는 코드에 집중하지만, 안정적인 시스템을 운영하려면 연결이 언제 생성되고 얼마나 유지되며 어느 쪽에서 종료되는지도 함께 살펴봐야 합니다.

먼저 모니터링 도구를 사용해 서버의 임시 포트 사용률과 TIME_WAIT 소켓 개수를 주기적으로 확인해야 합니다. ss나 netstat 명령어를 이용하면 현재 연결 상태를 직접 확인할 수 있습니다.

직접 연결 상태를 점검할 때는 TIME_WAIT 숫자 하나만 보는 것보다 시간대별 증가 속도를 비교하는 편이 도움이 됐습니다. 요청량이 줄었는데도 TIME_WAIT가 계속 빠르게 증가한다면 연결 재사용이 제대로 작동하지 않거나 특정 작업이 단기 연결을 반복하고 있을 가능성이 있습니다.

포트 고갈이 의심된다면 무작정 커널 설정부터 변경해서는 안 됩니다. 애플리케이션이 연결을 정상적으로 닫고 있는지, HTTP 클라이언트와 데이터베이스 연결 풀이 재사용되고 있는지를 먼저 확인해야 합니다.

자주 묻는 질문과 답변

TIME_WAIT를 0초로 만들면 안 되나요?

TIME_WAIT를 완전히 제거하거나 지나치게 짧게 설정하면 지연된 패킷과 재전송된 종료 패킷을 정상적으로 처리하지 못할 수 있습니다. 이로 인해 새로운 연결에 이전 패킷이 섞이거나 예측하기 어려운 통신 오류가 발생할 수 있으므로 권장하지 않습니다.

포트 고갈은 서버의 서비스 포트에서 발생하나요?

주된 문제는 외부 연결을 만들 때 사용하는 클라이언트 측 임시 포트가 고갈되는 것입니다. 서버가 외부 API나 다른 마이크로서비스에 대량의 요청을 보낸다면 해당 서버가 클라이언트 역할을 하면서 자신의 임시 포트를 소모하게 됩니다.

연결 풀링을 사용하면 메모리 문제가 생기지 않나요?

유지 중인 연결은 일정한 메모리와 소켓 자원을 사용합니다. 하지만 적절한 크기의 연결 풀은 빈번한 연결 생성과 종료로 발생하는 CPU 부하, 지연 시간, 포트 고갈 위험을 줄여줍니다.

연결 풀의 최대 크기와 유휴 연결 유지 시간을 서비스의 실제 트래픽에 맞게 조정하면 자원 낭비를 줄이면서 연결 재사용의 장점을 얻을 수 있습니다.

비용 효율적인 시스템 운영 전략

서버 인프라를 확장하려면 추가 비용이 필요합니다. 하지만 TCP 연결 관리 방식을 최적화하면 새로운 서버를 추가하지 않고도 기존 자원의 처리 효율을 높일 수 있습니다.

불필요한 연결 생성을 줄이고 재사용성을 높이는 구조는 서버의 CPU 사용률을 낮추고 응답 속도를 개선합니다. 이는 클라우드 인스턴스와 네트워크 자원의 낭비를 줄여 비용 절감과 서비스 품질 향상에 모두 도움이 됩니다.

마지막으로 네트워크 설정은 항상 테스트 환경에서 먼저 검증해야 합니다. 운영체제의 커널 파라미터를 변경한 뒤에는 충분한 부하 테스트를 진행하고, 연결 실패율과 포트 사용량, 응답 시간을 함께 확인해야 합니다.

네트워크 기초를 이해하고 연결의 생성부터 종료까지 관리하는 것이 대규모 서버를 안정적으로 운영하기 위한 핵심입니다.