타임아웃 재전송

타임아웃 재전송은 패킷 교환 네트워크에서 신뢰성 있는 데이터 전송을 보장하기 위한 핵심 메커니즘이다. 이는 송신자가 데이터그램이나 세그먼트를 전송한 후, 사전에 설정된 시간 내에 수신자로부터 확인응답을 받지 못하면 해당 데이터를 다시 보내는 절차를 의미한다. 이 과정은 전송 제어 프로토콜과 같은 신뢰성 있는 전송 계층 프로토콜의 근간을 이룬다.

주요 목적은 두 가지로 요약된다. 첫째는 패킷 손실에 대한 복구를 통한 데이터 무결성 보장이다. 네트워크 경로상의 라우터 혼잡, 오류, 또는 수신 측의 버퍼 오버플로우 등 다양한 이유로 패킷이 유실될 수 있다. 타임아웃 재전송은 이러한 손실을 감지하고 데이터를 재전송함으로써 애플리케이션 계층에 완전한 데이터 스트림을 전달하는 책임을 진다. 둘째는 흐름 제어 및 혼잡 제어와 연계된 네트워크 효율성 관리이다. 과도한 재전송은 네트워크에 불필요한 부하를 줄 수 있으므로, 재전송 타이머의 값을 적절히 조정하여 불필요한 재전송을 최소화하고 네트워크 혼잡을 완화하는 역할도 수행한다.

이 메커니즘은 단순히 패킷을 다시 보내는 것을 넘어, 네트워크의 현재 상태를 추정하고 그에 맞춰 동작을 조정하는 적응형 시스템의 일부로 작동한다. 따라서 그 정의는 패킷 손실 복구라는 기본 기능과 함께, 네트워크 성능을 최적화하는 지능적인 피드백 루프의 시작점이라는 포괄적인 목적을 내포한다.

재전송 타이머는 패킷이나 세그먼트 전송 후 응답(ACK)을 기다리는 시간을 측정하는 장치이다. 이 타이머가 만료되면 해당 데이터의 수신 확인을 받지 못한 것으로 판단하여 재전송 절차를 시작한다. 타이머의 만료 시간은 RTO 값으로 결정되며, 이 값은 네트워크의 왕복 지연 시간과 지터를 기반으로 동적으로 조정된다. 재전송 타이머는 신뢰성 있는 데이터 전송의 핵심 메커니즘으로, 손실된 데이터를 복구하는 책임을 진다.

재전송 타이머의 관리에는 몇 가지 중요한 원칙이 적용된다. 타이머는 각 미확인 데이터 단위에 대해 독립적으로 설정되고 시작된다. ACK를 수신하면 해당 데이터에 대한 타이머는 중지되고 리셋된다. 만약 네트워크 상태가 악화되어 RTO 값이 너무 짧게 설정되면 불필요한 재전송이 빈번히 발생하여 네트워크 혼잡을 가중시킬 수 있다. 반대로 RTO 값이 너무 길면 패킷 손실에 대한 대응이 느려져 전체 처리량이 저하되고 응답 시간이 길어지는 문제가 발생한다.

따라서 재전송 타이머의 역할은 단순히 시간을 재는 것을 넘어, 네트워크 상태를 반영한 지능적인 시간 관리에 있다. 효율적인 RTO 계산 알고리즘을 통해 타이머는 네트워크의 변화에 적응하며, 데이터 전송의 신뢰성과 효율성 사이의 균형을 유지하는 데 기여한다.

지수 백오프(Exponential backoff)는 네트워크 프로토콜에서 타임아웃이 발생한 후 재전송을 시도하는 간격을 점진적으로 늘려가는 알고리즘이다. 이 기법의 핵심 목적은 반복적인 재전송 시도가 네트워크 혼잡을 악화시키는 것을 방지하는 것이다. 패킷 손실의 원인이 일시적인 장애보다는 네트워크 혼잡일 가능성이 높다고 가정하고, 재전송 주기를 기하급수적으로 증가시켜 네트워크에 추가 부하를 완화한다.

구체적인 동작 방식은 다음과 같다. 첫 번째 재전송 타임아웃(RTO)이 발생하면, 송신자는 패킷을 재전송하고 대기 시간을 두 배로 늘린다. 이 과정이 반복될수록 재전송 간격은 1배, 2배, 4배, 8배와 같이 지수적으로 증가한다. 예를 들어, 초기 재전송 대기 시간(RTO)이 1초라면, 연속적인 타임아웃 발생 시 재전송 시도는 약 1초, 2초, 4초, 8초, 16초 후에 이루어진다. 이는 네트워크 상태가 회복될 시간을 주고, 과도한 재전송 트래픽으로 인한 혼잡 붕괴를 방지한다.

지수 백오프는 TCP를 비롯한 많은 신뢰성 있는 전송 프로토콜의 핵심 메커니즘이다. 그러나 무한정 대기 시간이 증가하는 것을 방지하기 위해 일반적으로 최대 재전송 횟수나 최대 대기 시간 상한을 설정한다. 또한, Karn의 알고리즘과 결합되어, 재전송된 패킷에 대한 RTT(왕복 시간) 샘플링을 하지 않음으로써 잘못된 RTO 계산을 피한다. 이 알고리즘은 네트워크의 공정성과 안정성을 유지하는 데 중요한 역할을 한다.

Karn의 알고리즘은 TCP의 재전송 타이머 관리에서 발생하는 모호한 ACK 문제를 해결하기 위해 제안된 알고리즘이다. 이 문제는 송신자가 패킷을 재전송한 후, 수신자로부터 도착하는 응답(ACK)이 원래 전송된 패킷에 대한 것인지, 아니면 재전송된 패킷에 대한 것인지 구분할 수 없을 때 발생한다. 이러한 모호성은 RTT 샘플 측정을 방해하여, 부정확한 RTT 추정과 그에 따른 비효율적인 RTO 설정으로 이어진다.

알고리즘의 핵심 원칙은 두 가지 규칙으로 구성된다. 첫째, 재전송된 세그먼트에 대한 RTT 샘플을 측정하지 않는 것이다. 재전송 후 수신된 ACK가 원본 전송을 참조하는지 재전송을 참조하는지 알 수 없으므로, 이 ACK를 기반으로 한 RTT 측정은 신뢰할 수 없다. 따라서 이러한 샘플은 지수 이동 평균과 같은 RTT 추정 계산에서 완전히 배제된다. 둘째, 재전송이 발생하면, 다음 전송까지 RTO 값에 지수 백오프를 적용한다. 이는 네트워크 상태가 불확실할 때 보수적으로 접근하여 혼잡을 악화시키지 않도록 하기 위함이다.

Karn의 알고리즘은 간단하지만 효과적인 규칙을 통해 RTT 추정의 정확성을 유지하고, 불필요한 재전송으로 인한 네트워크 혼잡을 완화하는 데 기여한다. 이 알고리즘은 이후 RFC 6298을 비롯한 TCP 표준에 반영되어 현대 TCP 혼잡 제어 메커니즘의 중요한 기초가 되었다.

TCP의 재전송 정책은 RTO 값을 동적으로 계산하여 네트워크 상태에 맞춰 재전송 시점을 결정하는 핵심 메커니즘이다. RTO 계산의 기본은 RTT 측정에 기반한다. TCP는 데이터 세그먼트를 전송하고 이에 대한 ACK를 받는 데 걸리는 시간을 샘플 RTT로 측정한다. 이후, 이 샘플 값을 사용하여 평균 RTT와 RTT의 변동성을 추정하는 스무딩된 RTT 및 RTT 편차 값을 지속적으로 갱신한다. 초기 표준 알고리즘은 이러한 추정치를 바탕으로 RTO = SRTT + 4 * RTTVAR 공식으로 RTO 값을 설정한다[2].

RTO 계산은 네트워크 지연의 변화에 적응하도록 설계되었다. RTT가 증가하면 SRTT와 RTTVAR 값이 점진적으로 조정되어 RTO도 함께 증가한다. 이는 불필요한 재전송을 방지한다. 반대로 RTT가 감소하면 RTO 값도 줄어들어 패킷 손실에 더 빠르게 대응할 수 있다. 그러나 재전송 모호성 문제로 인해 재전송된 세그먼트에 대한 ACK가 도착했을 때, 이 ACK가 원본 전송에 대한 응답인지 재전송에 대한 응답인지 구분하기 어렵다. 이 경우 샘플 RTT 측정을 하지 않는 것이 일반적이다[3].

주요 RTO 계산 관련 파라미터는 다음과 같다.

RTO 값에는 하한과 상한이 적용된다. 대부분의 구현에서 RTO는 최소 1초[5] 이상으로 유지되어 급작스러운 지연 변동에 의한 과도한 재전송을 막는다. 상한은 일반적으로 60초 또는 120초로 제한된다. 이 정책은 지수 백오프와 결합되어 네트워크 혼잡이 심각할 경우 재전송 부하를 점진적으로 줄이는 역할을 한다.

TCP는 신뢰성 있는 데이터 전송을 보장하기 위해 타임아웃 재전송 메커니즘을 핵심적으로 사용한다. 이 메커니즘은 송신자가 세그먼트를 전송한 후, 해당 세그먼트에 대한 확인응답을 일정 시간 내에 수신하지 못하면 데이터가 손실되었다고 판단하고 동일한 세그먼트를 다시 전송하는 방식으로 동작한다. 이때 데이터 손실을 판단하는 기준 시간을 재전송 타임아웃 값이라고 한다.

RTO 값은 네트워크의 왕복 지연 시간을 기반으로 동적으로 계산된다. TCP는 SRTT와 RTTVAR을 지속적으로 측정하여 RTO 값을 갱신한다. 초기 표준 알고리즘은 일반적으로 RTO = SRTT + 4 * RTTVAR과 같은 공식을 사용한다[7]. 이 동적 조정은 네트워크 상태 변화에 적응하여 불필요한 재전송을 줄이고 손실에 빠르게 대응하는 데 목적이 있다.

TCP의 재전송 정책은 단순한 타임아웃 기반 재전송 외에도 빠른 재전송과 같은 보완 메커니즘을 포함한다. 빠른 재전송은 수신자로부터 중복된 ACK를 세 번 연속 받으면 타임아웃을 기다리지 않고 즉시 데이터를 재전송하는 방식이다. 이는 단일 패킷 손실에 대한 복구 시간을 크게 단축시킨다. 또한, 선택적 확인응답을 사용하는 경우, 수신자는 연속되지 않은 세그먼트 수신을 정확히 알릴 수 있어 재전송 효율이 더욱 높아진다.

TCP의 타임아웃 재전송은 혼잡 제어와 밀접하게 연동되어 작동한다. 재전송이 발생하면 TCP는 네트워크에 혼잡이 발생했다고 가정하고 혼잡 창 크기를 급격히 줄인다. 이는 전송 속도를 낮추어 네트워크 과부하를 완화시키는 역할을 한다. 따라서 타임아웃 재전송은 데이터의 신뢰적 전달뿐만 아니라 네트워크의 안정성을 유지하는 데도 기여한다.

UDP는 기본적으로 신뢰성 없는 전송을 제공하지만, 상위 계층 프로토콜에서 타임아웃 재전송 메커니즘을 구현하여 신뢰성을 보장할 수 있다. 대표적인 예는 QUIC 프로토콜이다. QUIC는 TCP의 핸드셰이크와 혼잡 제어, 재전송 로직을 UDP 위에 재구성하여, 연결 설정 지연을 줄이고 다중 스트림 지원, 향상된 보안 등의 장점을 제공한다.

QUIC의 재전송 메커니즘은 TCP의 개념을 계승하지만 몇 가지 중요한 차이점이 있다. 첫째, 패킷 번호가 암호화되어 있으며 전송마다 단조 증가하여, 중간 네트워크 장치에 의한 패킷 재정렬 오탐지 문제를 방지한다. 둘째, 데이터 스트림별로 독립적인 신뢰성 보장이 가능하다. 하나의 패킷 손실이 다른 스트림의 데이터 전달을 차단하지 않는 헤드 오브 라인 블로킹 완화에 기여한다.

재전송 정책 측면에서 QUIC는 초기 RTO 값을 더 보수적으로 설정하고, 지수 백오프를 적용하는 등 TCP의 알고리즘을 활용한다. 그러나 연결 식별자와 암호화된 패킷 번호를 사용함으로써, NAT 재바인딩이나 클라이언트 IP 주소 변경 후에도 기존 연결을 유지할 수 있어, 모바일 환경에서 재전송 효율성을 높인다.

이러한 설계로 인해 QUIC는 UDP를 사용하면서도 TCP 수준의 신뢰성 있는 타임아웃 재전송을 구현하며, 현대 웹의 빠른 전송과 복원력 요구사항을 더 잘 충족한다.

타임아웃 재전송 메커니즘은 네트워크 혼잡을 감지하고 대응하는 핵심 수단 중 하나이다. 패킷 손실은 주로 네트워크 혼잡으로 인한 라우터의 버퍼 오버플로우 때문에 발생한다. 따라서, 타임아웃이 발생하여 패킷을 재전송하는 행위는 단순한 오류 복구를 넘어, 현재 네트워크 경로가 포화 상태일 가능성이 높음을 송신자에게 알리는 신호 역할을 한다. 이 신호를 받은 TCP와 같은 프로토콜은 혼잡 제어 알고리즘을 동작시켜 전송 속도를 급격히 낮춘다. 이는 추가적인 패킷 손실과 네트워크 정체의 악순환을 방지하기 위한 필수적인 조치이다.

반면, 부적절하게 설정된 재전송 정책은 네트워크 혼잡을 악화시킬 수 있다. 재전송 타임아웃(RTO) 값이 지나치게 짧으면, 패킷이 단순히 지연되었을 뿐인 상황에서도 불필요한 재전송이 발생한다. 이로 인해 네트워크에 중복 패킷이 추가로 유입되어 혼잡을 가중시키고, 대역폭을 비효율적으로 소모한다. 이 현상을 '재전송 폭풍'이라고 부르기도 한다. 따라서, 정확한 RTT(왕복 시간) 측정과 이를 바탕으로 한 RTO 계산은 네트워크의 안정성을 유지하는 데 결정적이다.

요약하면, 타임아웃 재전송과 네트워크 혼잡은 밀접한 상호작용 관계에 있다. 타임아웃은 혼잡을 나타내는 지표로 작용하며, 이에 따른 전송 속도 조절은 혼잡을 완화한다. 그러나 잘못된 재전송 행위는 오히려 혼잡의 원인이 될 수 있으므로, 프로토콜 설계 시 이 관계를 정교하게 고려해야 한다.

타임아웃 재전송은 패킷 손실을 복구하는 핵심 메커니즘이지만, 네트워크 성능의 두 가지 핵심 지표인 지연 시간과 처리량에 직접적인 영향을 미친다. 패킷 손실이 발생하면, 송신자는 재전송 타이머가 만료될 때까지 기다린 후 데이터를 다시 보내야 한다. 이 대기 시간은 최종 사용자가 경험하는 응답 지연을 증가시키는 주요 요인이다. 특히 왕복 시간이 길거나 변동성이 큰 네트워크에서는 재전송 시간 초과 값이 보수적으로 설정될 수밖에 없어, 불필요한 대기 시간이 더욱 길어질 수 있다.

처리량 측면에서 타임아웃 재전송은 효율성을 크게 저하시킨다. 재전송이 발생하는 동안 송신 윈도우의 진행이 멈추거나, 혼잡 윈도우 크기가 급격히 줄어들어 데이터 전송률이 떨어진다. 지수 백오프 알고리즘은 연속적인 손실 시 재전송 대기 시간을 기하급수적으로 증가시켜 네트워크 자원의 유휴 상태를 초래한다. 이는 전체적인 링크 활용도를 낮추고, 이론적 대역폭에 비해 실제 달성 가능한 처리량을 현저히 감소시킨다.

지연과 처리량에 대한 영향은 다음 표를 통해 요약할 수 있다.

따라서 타임아웃 재전송 매커니즘의 설계와 RTO 계산의 정확성은 단순한 신뢰성 확보를 넘어서, 애플리케이션의 전반적인 성능과 사용자 경험을 결정하는 중요한 요소이다. 현대 프로토콜들은 빠른 재전송과 같은 메커니즘을 도입하거나, QUIC처럼 연결 다중화를 통해 타임아웃에 의한 지연 영향을 완화하려고 노력한다.

RTO 값을 정확하게 설정하는 것은 네트워크 혼잡을 유발하지 않으면서도 불필요한 지연을 최소화하는 데 중요하다. 초기 TCP 구현에서는 RTO를 고정값으로 설정했지만, 이는 다양한 네트워크 조건에 적응하지 못하는 문제가 있었다. 이후 자커슨 알고리즘과 카네 알고리즘이 도입되어 RTT를 지속적으로 측정하고 이를 바탕으로 RTO를 동적으로 조정하는 방식이 표준이 되었다. 핵심은 스무딩된 RTT와 RTT 변이를 함께 고려하여 계산하는 것이다.

최적화 기법 중 하나는 패킷 페어 샘플링과 같은 방법으로 보다 정확한 RTT 샘플을 수집하는 것이다. 재전송된 패킷에 대한 응답은 재전송 모호성 문제를 일으키기 때문에, 카른의 알고리즘에 따라 이 샘플을 RTT 계산에서 제외하는 것이 일반적이다. 그러나 TCP 타임스탬프 옵션을 사용하면 재전송된 패킷과 원본 패킷을 구별할 수 있어, 재전송 상황에서도 유효한 RTT 측정이 가능해지고 RTO 추정의 정확도를 높일 수 있다.

고속 네트워크나 위성 링크와 같이 지연이 크거나 변동성이 높은 환경에서는 표준 RTO 계산 공식이 너무 보수적으로 작동할 수 있다. 이를 위해 RFC 6298에서는 RTO의 최소값을 1초로 권고하지만, 특정 제어된 환경에서는 이 값을 더 낮춰 응답성을 높일 수 있다. 반대로 무선 네트워크처럼 일시적인 패킷 손실이 빈번한 환경에서는 RTO를 과도하게 줄이면 불필요한 재전송으로 인한 혼잡을 가중시킬 위험이 있다.

최근에는 머신 러닝을 적용한 적응형 RTO 조정 연구도 진행되고 있다. 역사적인 RTT 데이터와 네트워크 상태 지표를 학습하여 보다 정교하게 RTO를 예측하는 방식이다. 또한 BBR과 같은 최신 혼잡 제어 알고리즘은 대역폭과 지연을 직접 측정하여 패킷 전송 속도를 결정함으로써, 전통적인 패킷 손실 기반의 재전송 메커니즘에 대한 의존도를 낮추는 접근법을 보인다.

재전송 관련 문제는 네트워크 성능 저하의 주요 원인 중 하나이다. 일반적인 문제로는 패킷 손실이 과도하게 발생하거나, 왕복 지연 시간(RTT)이 불안정하여 재전송 타임아웃(RTO) 값이 실제 상황과 맞지 않는 경우가 있다. 또한, 네트워크 혼잡으로 인한 손실과 무선 링크의 비트 오류로 인한 손실을 구분하지 못하면, 혼잡 제어 알고리즘이 부적절하게 동작하여 처리량이 급감할 수 있다.

문제를 진단하기 위해선 먼저 네트워크 트래픽을 분석해야 한다. 와이어샤크나 tcpdump 같은 도구를 사용해 SYN 패킷과 ACK 패킷의 흐름을 확인하고, 중복된 ACK 또는 RTO 시간 초과 후의 재전송 패킷을 관찰한다. 다음 표는 일반적인 재전송 패턴과 그 원인을 요약한 것이다.

효과적인 진단을 위해서는 종단 시스템의 통계 정보를 확인하는 것이 중요하다. netstat -s 또는 ss -i 명령어를 통해 특정 연결의 재전송 횟수와 손실률을 확인할 수 있다. RTT의 평균과 변동치(표준편차)를 모니터링하여 RTO 계산 공식(SRTT, RTTVAR)에 입력되는 값이 정상적인지 평가해야 한다. 만약 RTT 샘플링이 부정확하다면, Karn의 알고리즘을 준수하지 않아 재전송 패킷의 RTT를 측정했거나, 타임스탬프 옵션을 사용하지 않아 발생한 문제일 수 있다.

문제의 근본 원인이 네트워크 경로상에 있는지 확인하기 위해, 트레이스루트(traceroute)를 사용해 지연이 발생하는 홉을 찾거나, 지속적인 패킷 손실이 있는지 핑(ping) 테스트를 수행할 수 있다. 애플리케이션 계층에서의 과도한 버퍼링이나 느린 처리도 ACK 전송을 지연시켜 재전송을 유발할 수 있으므로, 애플리케이션 프로파일링도 병행하는 것이 좋다.