TCP 타이머가 전송과 연결 수명에 미치는 영향

ACK를 기다리는 동안 재전송 타이머가 하는 일

TCP는 세그먼트를 보낸 뒤 ACK를 받을 때까지 재전송 타이머를 운용한다. 타이머가 만료되면 해당 세그먼트가 손실됐다고 보고 다시 보내며, ACK를 받으면 타이머를 멈춘다. 신뢰성 있는 전송에서 가장 직접적인 복구 장치다.

재전송 간격은 RTT(Round Trip Time)를 기준으로 동적으로 조정된다. 초기 RTO(Retransmission Timeout)는 일반적으로 3초이며, 네트워크 상태에 따라 지수적 백오프(exponential backoff)를 적용한다. Karn 알고리즘과 Jacobson 알고리즘 등은 RTT 측정과 RTO 계산에 사용된다.

대용량 파일을 내려받는 중 네트워크 혼잡으로 일부 패킷이 손실됐다고 가정해 보자. 처음에는 3초 후 재전송을 시도하고, 실패가 계속되면 6초, 12초처럼 간격을 늘려 재시도한다.

⤢✕

제로 윈도우에서 송수신이 멈추지 않게 하는 영속성 타이머

수신자가 윈도우 크기를 0으로 알리면 송신자는 더 이상 데이터를 보낼 수 없다. 이때 영속성 타이머가 동작한다. 타이머가 끝나면 송신자는 윈도우 프로브(Window Probe) 패킷을 보내 수신 측의 현재 윈도우 크기 업데이트를 확인한다.

이 장치는 윈도우 업데이트 패킷 자체가 유실됐을 때의 교착 상태를 막는다. 네트워크 자원을 과도하게 쓰지 않으면서 연결이 다시 전송 가능한 상태인지 확인할 수 있다.

예를 들어 클라이언트가 서버에 대용량 데이터를 전송하다 서버 버퍼가 가득 차면, 서버는 윈도우 크기 0을 담은 ACK를 보낸다. 이후 버퍼 공간이 생겨 윈도우 업데이트를 보냈는데 그 패킷이 손실되면, 영속성 타이머가 없는 클라이언트는 계속 기다리게 된다. 영속성 타이머는 프로브를 보내 이 상태를 벗어나게 한다.

⤢✕

연결을 닫은 뒤에도 TIME_WAIT가 남는 이유

활성 종료(Active Close)를 수행한 쪽은 FIN-ACK 교환 뒤 TIME_WAIT 상태에 들어간다. 이 상태는 일반적으로 2MSL(Maximum Segment Lifetime) 동안 유지된다. MSL은 세그먼트가 네트워크에 존재할 수 있는 최대 시간이며, 일반적으로 30초~2분 사이로 설정한다.

TIME_WAIT는 이전 연결에서 지연된 패킷이 새 연결에 섞이는 일을 막는다. 또한 원격 호스트가 FIN에 대한 ACK를 받지 못해 FIN을 다시 보낼 경우에도 대응할 수 있어 연결 종료의 완결성을 보장한다.

HTTP 통신이 끝난 뒤 클라이언트가 먼저 FIN을 보내 연결 종료를 시작한 경우를 생각할 수 있다. 클라이언트는 서버 FIN에 대한 ACK를 보낸 뒤에도 2MSL 동안 TIME_WAIT 상태를 유지한다. 서버가 마지막 ACK를 받지 못했다면 FIN을 재전송할 수 있고, 클라이언트는 이를 처리할 수 있다.

⤢✕

유휴 연결의 생존 여부를 확인하는 Keepalive

Keepalive 타이머는 오랫동안 유휴 상태인 연결이 여전히 유효한지 점검한다. 기본적으로 비활성화되어 있으며 애플리케이션에서 활성화할 수 있다. 일반적으로 2시간 동안 비활성 상태가 이어진 뒤 작동하고, 75초 간격으로 최대 9번 프로브 패킷을 보낸다. 응답이 없으면 연결을 종료한다.

이 메커니즘은 네트워크 오류나 시스템 크래시로 남은 좀비 연결을 제거하고, 방화벽이나 NAT 장치의 연결 상태 테이블을 유지하며, 물리적 연결 장애를 감지하는 데 도움이 된다. 반대로 추가 트래픽을 발생시키고 모바일 장치의 배터리 소모를 늘릴 수 있다. 일시적인 네트워크 장애 때문에 불필요한 연결 종료가 일어날 가능성도 있다.

데이터베이스 서버와 애플리케이션 서버 사이에서 트랜잭션이 드문 시간대에 Keepalive를 사용할 수 있다. 애플리케이션 서버가 예기치 않게 종료되면 데이터베이스 서버는 프로브 응답 부재를 통해 이를 감지하고 연결 리소스를 해제할 수 있다.

⤢✕

연결 생명주기 전반에서 맞물리는 타이머

재전송, 영속성, TIME_WAIT, Keepalive 타이머는 각각 독립적으로 작동하지만 TCP 연결의 전체 생명주기에서는 서로 보완한다. 재전송 타이머는 전달 실패를 복구하고, 영속성 타이머는 제로 윈도우 교착을 피하며, TIME_WAIT는 종료 절차를 마무리한다. Keepalive는 유휴 연결의 상태를 확인한다.

타이머 값이 지나치게 작으면 불필요한 재전송과 네트워크 혼잡이 생길 수 있다. 반대로 값이 너무 크면 패킷 손실을 늦게 감지해 성능이 저하된다. 네트워크 특성에 맞춘 조정이 필요하다.

구현은 OS 커널 레벨에서 이뤄지며, 타이머 정밀도와 시스템 오버헤드의 균형도 고려 대상이다. 가상 환경에서는 타이머 정확성 문제가 발생할 수 있다. CDN(Content Delivery Network)은 최적화된 재전송 타이머로 콘텐츠 전송을 가속화하고, 금융 거래 시스템은 빠른 재전송과 엄격한 연결 관리로 신뢰성을 확보한다. IoT 환경에서는 제한된 리소스 안에서 효율적으로 타이머를 운용해 배터리 수명을 최적화한다.

타이머 관점에서 보는 연결 장애 진단

TCP 타이머 문제는 패킷 전송 지연, 연결 종료, 포트 고갈처럼 서로 다른 증상으로 나타날 수 있다. 과도한 재전송에는 네트워크 혼잡 제어 매개변수 조정을 검토하고, 연결 설정 지연에는 초기 RTO 값 최적화를 고려한다. 불필요한 연결 종료는 Keepalive 간격과 관련이 있으며, TIME_WAIT 상태가 누적돼 포트가 고갈될 때는 tcp_tw_reuse, tcp_tw_recycle 설정을 확인할 수 있다.

Wireshark는 패킷 수준에서 타이머 동작을 분석하는 데 쓰인다. tcpdump는 커맨드 라인 기반 패킷 캡처와 분석에 적합하고, netstat와 ss는 연결 상태 및 타이머 정보를 확인하는 데 사용할 수 있다. iptraf는 실시간 네트워크 통계 모니터링 도구다.

재전송, 영속성, 시간대기, 연결유지 타이머를 함께 이해하면 TCP 연결이 왜 재시도되고, 왜 멈춤에서 회복하며, 왜 종료 후에도 일정 시간 남는지 추적할 수 있다. 네트워크 엔지니어와 시스템 관리자는 이 동작을 바탕으로 성능 문제와 연결 장애를 진단한다.