[네트워크] TCP Taehoe VS TCP Reno

TCP의 혼잡 제어 방식의 발전

TCP의 제어 방법에는 수신자의 버퍼가 넘치지 않도록 데이터의 전송을 조절하는 **흐름 제어(Flow Control)**와 네트워크 혼잡에 따라 데이터의 양을 조절하는 혼잡 제어(Congestion Control) 등이 있습니다.

 

먼저 TCP의 특징에 대해서 알아봅시다

1. 모든 프로세스가 전송자와 수신자가 될 수 있습니다
2. 송신하는 측과 연결을 먼저 한 후 통신합니다
3. 전송자는 수신자가 받을 수 있는 데이터 양을 초과해서 보내지 않습니다

 

TCP는 애초에 하나의 모델만 존재했을까요?

TCP는 처음부터 하나의 모델만 존재했던 것이 아니라, 네트워크 환경과 요구사항에 따라 여러 혼잡 제어 알고리즘이 개발되었습니다. 초기 TCP 구현에서는 혼잡 제어 기능이 없었지만, 1980년대 후반부터 혼잡 제어 기법이 추가되었고, 이후 다양한 TCP 모델이 등장했습니다.

초기 TCP (Tahoe, Reno, NewReno)는 아래와 같습니다

• TCP Tahoe (1988): Slow Start, Congestion Avoidance, Fast Retransmit 도입
• TCP Reno (1990): Fast Recovery 추가
• TCP NewReno (1999): Partial Acknowledgment 지원

이 중에서 저희는 Tahoe와 Reno에 대해서 알아보도록 하겠습니다. 이 둘의 차이는 혼잡 제어 방식의 발전을 설명하는 대표적인 사례입니다.

 

TCP Taehoe

Tahoe TCP는 두 가지 알고리즘(느린시작, 혼잡회피)을 사용합니다.

 

TCP Reno

위에서 설명했듯이 Fast Recovery(빠른 복구) 기법은 TCP Tahoe의 단점을 보완하기 위해 TCP Reno에서 도입되었습니다.

 

왜 Fast Recovery가 필요했을까?

TCP Tahoe의 문제점: 패킷 손실 시 너무 보수적인 대응

• TCP Tahoe에서는 패킷 손실이 발생하면 즉시 Slow Start로 돌아감.
• 손실이 감지되면 cwnd(Congestion Window, 혼잡 윈도우)를 1로 줄이고 다시 천천히 증가시키므로,네트워크 대역폭을 제대로 활용하지 못하는 문제가 발생.
• 특히 단순한 일시적 손실(예: 네트워크 혼잡이 아니라 일시적인 패킷 유실)에도 성능이 크게 떨어짐.

해결책: Fast Recovery 도입 (TCP Reno)

• Fast Retransmit(빠른 재전송) 기법을 사용하면 3개의 중복 ACK를 받으면 손실을 감지할 수 있음.→ 하지만 TCP Tahoe에서는 Fast Retransmit 이후 바로 Slow Start로 돌아가므로 속도 저하가 발생.
• 이를 개선하기 위해 TCP Reno는 Fast Recovery를 도입.
• Fast Recovery 기법:
  1. 손실 감지: 3개의 중복 ACK를 받으면 cwnd를 절반으로 감소 (즉시 Slow Start로 가지 않음).
  2. 빠른 재전송: 손실된 패킷을 재전송함.
  3. Congestion Avoidance 단계로 이동: Slow Start 대신 기존보다 낮은 cwnd에서 다시 증가.

 

TCP Tahoe vs TCP Reno

Tahoe와 Reno의 그래프를 비교하면 혼잡 윈도우(cwnd)와 임계값(ssthresh)의 변화 차이를 확인할 수 있습니다.

1. TCP Tahoe
   • 패킷 손실이 발생하면 cwnd가 초기 상태(1)로 감소하고 Slow Start로 돌아감.
   • ssthresh(임계값)는 변하지 않음.
   • 결과적으로 네트워크 대역폭 활용이 급격히 감소.
2. TCP Reno
   • 패킷 손실이 발생하면 cwnd가 초기값이 아닌 절반으로 감소.
   • ssthresh가 감소된 cwnd 값으로 조정됨.
   • Duplicate ACK가 발생했다는 증거이며, Fast Recovery 기법이 적용되었음을 의미.
   • cwnd가 완전히 초기화되지 않으므로 Tahoe보다 빠르게 패킷을 전송할 수 있음.

 

특히, 9초 이후의 그래프를 보면 TCP Reno가 Tahoe보다 패킷을 더 빠르게 전달할 수 있음을 확인할 수 있습니다. 이는 Fast Recovery 덕분에 불필요한 Slow Start를 피하고, 네트워크 대역폭을 더 효율적으로 활용하기 때문입니다.