TCP Tahoe vs Reno vs Cubic: 네트워크 효율을 결정하는 혼잡 제어의 진화

현대 인터넷 통신에서 데이터가 유실 없이 빠르고 안정적으로 전달되는 배경에는 TCP(Transmission Control Protocol)의 정교한 혼잡 제어(Congestion Control) 알고리즘이 있습니다. 네트워크의 상태를 감지하고 전송 속도를 조절하는 이 메커니즘은 지난 수십 년간 Tahoe에서 Reno를 거쳐 현재의 Cubic에 이르기까지 비약적인 발전을 이루어왔습니다. 본 포스팅에서는 각 알고리즘의 핵심 동작 원리와 차이점을 심층 비교하여, 현대 네트워크 환경에서 최적의 성능을 끌어내는 원리를 분석해 보겠습니다.

1. TCP 혼잡 제어의 근본적인 목적

네트워크 상의 모든 호스트가 최대 속도로 데이터를 전송하려 하면, 라우터의 버퍼가 넘치고 패킷 유실이 발생하는 ‘혼잡 붕괴(Congestion Collapse)’ 현상이 나타납니다. TCP 혼잡 제어는 ‘네트워크가 수용할 수 있는 최대 대역폭을 탐색하면서도, 혼잡을 유발하지 않도록 조절하는 것’을 목표로 합니다. 이를 위해 혼잡 윈도우(cwnd)라는 개념을 사용하여 전송량을 동적으로 제어합니다.

2. 클래식의 시작: TCP Tahoe (1988)

TCP Tahoe는 반 제이콥슨(Van Jacobson)에 의해 제안된 최초의 표준 혼잡 제어 알고리즘입니다. 오늘날 우리가 알고 있는 현대 TCP의 근간이 되는 ‘Slow Start’와 ‘Congestion Avoidance’ 개념을 정립했습니다.

2.1 주요 동작 방식

• Slow Start: 연결 초기 cwnd를 1 MSS에서 시작하여 매 RTT마다 2배씩 지수 함수적으로 증가시킵니다.
• Congestion Avoidance: cwnd가 임계치(ssthresh)에 도달하면 선형적으로 1씩 증가시킵니다.
• 단점: 패킷 손실(타임아웃 또는 3-Duplicate ACK)이 감지되면 무조건 cwnd를 1로 초기화하고 다시 Slow Start부터 시작합니다. 이는 전송 효율을 급격히 떨어뜨리는 요인이 됩니다.

3. 효율의 개선: TCP Reno (1990)

TCP Reno는 Tahoe의 치명적인 단점인 ‘전송 중단’ 현상을 해결하기 위해 등장했습니다. 핵심은 ‘패킷 손실의 유형’을 구분하기 시작했다는 점입니다.

3.1 빠른 재전송과 빠른 회복 (Fast Recovery)

Reno는 타임아웃이 아닌 ‘3-Duplicate ACK’로 인해 패킷 손실을 감지하면, 네트워크가 완전히 마비된 것은 아니라고 판단합니다.

• 동작: cwnd를 1로 줄이지 않고 현재의 절반(cwnd/2)으로 줄인 뒤, 임계치도 그 값으로 설정합니다.
• 결과: Slow Start를 거치지 않고 곧바로 Congestion Avoidance 단계에서 전송을 재개하므로 Tahoe보다 훨씬 높은 처리량(Throughput)을 유지합니다.

4. 현대의 표준: TCP Cubic (2006)

오늘날 리눅스(Linux), 안드로이드(Android), 윈도우(Windows) 등 대부분의 운영체제에서 기본으로 채택하고 있는 알고리즘이 바로 Cubic입니다. 고속 대역폭과 긴 지연 시간(LFN, Long Fat Network) 환경에 최적화되어 있습니다.

4.1 3차 함수 기반의 윈도우 조절

Cubic의 가장 큰 특징은 시간이 아닌 ‘마지막 혼잡 발생 이후 경과 시간’에 따른 3차 함수(Cubic Function) 곡선을 사용하여 cwnd를 조절한다는 점입니다.

• 오목한 영역(Concave): 혼잡 발생 직후에는 이전의 안정적이었던 윈도우 크기까지 빠르게 회복합니다.
• 평탄한 영역(Plateau): 이전 혼잡 지점 근처에서는 네트워크 상태를 조심스럽게 탐색하기 위해 증가 폭을 최소화합니다.
• 볼록한 영역(Convex): 새로운 대역폭 여유가 있다고 판단되면 다시 공격적으로 전송량을 늘립니다.

5. Tahoe vs Reno vs Cubic 핵심 비교표

각 알고리즘의 주요 차이점을 한눈에 파악할 수 있도록 정리한 비교표입니다.

구분	TCP Tahoe	TCP Reno	TCP Cubic
증가 방식	지수/선형 (시간 기반)	지수/선형 (ACK 기반)	3차 함수 (경과 시간 기반)
손실 감지 시 (3-ACK)	cwnd = 1 (초기화)	cwnd = cwnd / 2 (빠른 회복)	Multiplicative Decrease (0.7배)
고속 망 적응성	매우 낮음	낮음 (느린 회복)	매우 높음 (빠른 탐색)
주요 특징	가장 보수적이고 단순함	빠른 회복(Fast Recovery) 도입	대역폭 활용의 공정성 및 효율성
현재 상태	교육용/특수 환경	많은 변종의 기본 모델	현대 OS의 표준 알고리즘

6. 왜 현대 네트워크는 Cubic을 선택했는가?

과거 Reno 방식은 대역폭이 넓은 기가비트 네트워크에서 혼잡 발생 후 다시 최대 속도에 도달하기까지 너무 많은 시간이 걸리는 문제가 있었습니다. 반면 Cubic은 네트워크의 절대적인 속도보다는 ‘마지막 안정적 지점까지의 시간’을 계산하므로, 지연 시간이 긴 위성 통신이나 초고속 광대역망에서도 대역폭을 낭비 없이 꽉 채워 사용할 수 있습니다. 또한, 다른 TCP 흐름들과 대역폭을 나누어 쓰는 ‘공정성(Fairness)’ 측면에서도 Reno보다 뛰어난 성능을 보여줍니다.

결론: 인프라에 맞는 알고리즘의 이해

TCP Tahoe에서 Cubic에 이르는 진화 과정은 네트워크 공학자들이 한계 대역폭을 얼마나 효율적으로 사용하기 위해 고민해 왔는지를 보여주는 증거입니다. 일반적인 웹 서비스 운영자라면 OS의 기본값인 Cubic을 사용하는 것으로 충분하지만, 초저지연이 필요한 금융 시스템이나 패킷 손실이 극심한 위성 환경이라면 Google BBR이나 다른 특화된 알고리즘을 고려해야 할 수도 있습니다. 프로토콜의 하부 메커니즘을 이해하는 것은 서비스 최적화와 트러블슈팅의 가장 강력한 무기가 될 것입니다.

서버가 속한 네트워크의 RTT(왕복 시간)가 100ms 이상인 글로벌 서비스라면, Reno보다는 무조건 Cubic이나 그 이상의 알고리즘을 선택해야 대역폭 낭비를 막을 수 있습니다.