TCP Congestion Control이란
TCP Congestion Control(혼잡 제어)은 송신 측이 네트워크의 혼잡 상태를 판단해서 데이터 전송 속도를 스스로 조절하는 메커니즘입니다. 인터넷은 여러 사용자가 동시에 대역폭을 공유하는 구조이기 때문에, 누군가 무작정 빠르게 데이터를 보내면 라우터의 버퍼가 넘치면서 패킷 손실과 지연이 발생합니다. TCP는 이런 문제를 막기 위해 ‘얼마나 많은 데이터를 한 번에 보낼지’를 나타내는 congestion window(cwnd)라는 값을 두고, 상황에 따라 이 값을 늘리거나 줄입니다.
비유하자면 고속도로 진입 램프의 신호등과 비슷합니다. 도로가 한산하면 차를 빠르게 진입시키지만, 정체가 감지되면 진입 속도를 줄여서 전체 흐름이 막히지 않도록 조절하는 것입니다.
동작 원리: Slow Start와 AIMD
TCP 혼잡 제어는 크게 두 단계로 동작합니다.
- Slow Start(느린 시작): 연결 초기에는 cwnd를 작게 시작해서, ACK를 받을 때마다 지수적으로 두 배씩 늘립니다. 네트워크 상태를 모르는 상태에서 안전하게 속도를 탐색하는 과정입니다.
- Congestion Avoidance(혼잡 회피): cwnd가 일정 임계값(ssthresh)을 넘으면 증가 속도를 선형으로 늦춰서 조심스럽게 늘려갑니다.
- AIMD(Additive Increase, Multiplicative Decrease): 패킷 손실이 없으면 cwnd를 조금씩(더하기) 늘리고, 패킷 손실이 감지되면 cwnd를 절반으로(곱하기) 줄입니다.
예를 들어 패킷 손실이나 타임아웃이 발생하면 TCP는 ‘네트워크가 혼잡하다’고 판단하고 cwnd를 급격히 줄인 뒤, 다시 천천히 늘려가며 최적의 전송 속도를 찾아갑니다. 이런 방식을 구현한 대표적인 알고리즘으로 Reno, CUBIC, 최근 구글이 개발한 BBR 등이 있습니다. CUBIC은 리눅스의 기본 알고리즘으로, cwnd 증가를 3차 함수 곡선 형태로 조절해 안정성과 처리량을 동시에 확보합니다.
실무에서 왜 중요한가
혼잡 제어는 개발자가 직접 코드를 작성하는 영역은 아니지만, 서비스 성능과 직결되는 개념입니다.
- 서버 응답이 느려지는 원인을 분석할 때 네트워크 혼잡 여부를 의심해볼 수 있습니다.
- 대용량 파일 전송, 스트리밍 서비스에서 어떤 혼잡 제어 알고리즘(CUBIC vs BBR)을 쓰느냐에 따라 체감 속도가 달라집니다.
- 클라우드 인프라나 CDN을 운영할 때, TCP 튜닝 옵션을 이해하고 있으면 네트워크 병목을 진단하는 데 큰 도움이 됩니다.
결국 TCP Congestion Control은 ‘모두가 함께 쓰는 도로에서 다 같이 잘 달리기 위한 규칙’이라고 이해하면 됩니다. 개별 연결의 속도를 최대화하는 것이 아니라, 네트워크 전체가 안정적으로 동작하도록 만드는 것이 핵심 목표입니다.