TCP 혼잡 제어에서 Tail-Drop·RED·WRED를 선택하는 법

TCP 혼잡 제어를 지원하는 Tail-Drop, RED, WRED의 큐 관리 방식과 QoS 적용 기준을 비교한다.

2026-08-14 · 최초 발행 2025-08-10

혼잡은 TCP 전송 자체를 흔든다

대역폭이나 버퍼처럼 제한된 네트워크 리소스에 수요가 몰리면 패킷 손실과 전송 지연이 늘고 처리량은 줄어든다. TCP는 패킷 손실을 혼잡 신호로 받아들여 윈도우 크기를 조정한다. 큐 관리 방식은 이 TCP 혼잡 제어가 작동하는 조건을 만들고 보완하는 역할을 한다.

문제는 패킷을 언제, 어떤 기준으로 버리느냐에 있다. Tail-Drop은 버퍼가 찰 때까지 기다리고, RED는 평균 큐 길이를 보며 미리 확률적으로 폐기한다. WRED는 여기에 트래픽 우선순위를 더한다.

버퍼 끝에서 폐기하는 Tail-Drop

Tail-Drop은 라우터나 스위치 버퍼가 가득 찬 시점부터 새로 들어오는 패킷을 모두 폐기한다. 구현이 단순한 만큼 별도 설정 파라미터가 없고, 추가 리소스도 거의 요구하지 않는다.

아니오패킷 도착버퍼에 공간이 있는가?패킷을 버퍼에 저장패킷 폐기 - Tail-Drop패킷 처리

단순성에는 대가가 따른다. 여러 TCP 연결이 같은 시점에 손실을 감지하면 모두 함께 전송 속도를 낮추는 글로벌 동기화(Global Synchronization)가 생길 수 있다. 버퍼가 계속 가득 찬 상태에 가까워져 지연이 늘고, 버스트 트래픽에도 취약하다. 흐름이나 연결별 차등 서비스 역시 제공하지 못한다.

대규모 ISP 네트워크에서 Tail-Drop만 사용한 사례에서는 트래픽 폭주 때 다수의 TCP 연결이 동시에 속도를 줄이면서 네트워크 활용률이 50% 이하로 떨어지는 톱니바퀴(sawtooth) 패턴이 관찰됐다.

RED는 평균 큐 길이로 먼저 신호를 보낸다

RED(Random Early Detection)는 1993년 Sally Floyd와 Van Jacobson이 제안한 방식이다. 버퍼가 완전히 차기 전에 평균 큐 길이를 기준으로 일부 패킷을 확률적으로 폐기해, 모든 TCP 연결이 한꺼번에 반응하는 문제를 줄이려 한다.

평균 큐 길이(avg)가 min_th보다 작으면 패킷을 수용한다. avg가 min_th와 max_th 사이에 들어오면 확률에 따라 폐기하며, max_th를 넘으면 모든 패킷을 폐기한다.

아니오아니오패킷 도착평균 길이 계산평균 길이가 min_th보다작은가?패킷 수용평균 길이가 max_th보다작은가?확률에 따라 패킷 폐기패킷 폐기

패킷 폐기 확률(p)은 다음 공식으로 계산된다.

p = max_p * (avg - min_th) / (max_th - min_th)

여기서 max_p는 최대 폐기 확률이다.

RED는 버퍼 활용을 개선하고, 혼잡이 심해지기 전부터 대응한다. TCP 연결 전체가 동시에 손실을 겪는 상황도 완화할 수 있다. 반면 min_th, max_th, max_p, 가중치의 조정이 어렵고, 트래픽 패턴이 달라지면 일관된 성능을 보장하기 어렵다. 모든 트래픽을 동일하게 다루므로 QoS 요구에도 한계가 있으며, 짧은 버스트에는 과도하게 반응할 수 있다.

대형 콘텐츠 전송 네트워크(CDN)의 RED 구현 사례에서는 트래픽 부하가 높은 상황에서도 네트워크 활용률이 85% 이상으로 유지됐고, Tail-Drop 대비 평균 지연 시간이 30% 감소했다고 보고됐다.

WRED는 트래픽 우선순위를 큐 정책에 반영한다

WRED(Weighted Random Early Detection)는 RED의 확장 방식이다. IP 우선순위, DSCP(DiffServ Code Point), 플로우 기반 분류를 사용해 트래픽별로 다른 폐기 프로필을 적용한다. 높은 우선순위의 트래픽에는 낮은 폐기 확률을, 낮은 우선순위 트래픽에는 높은 폐기 확률을 적용한다.

아니오아니오패킷 도착패킷 우선순위 확인평균 길이 계산평균 길이가 우선순위별min_th보다 작은가?패킷 수용평균 길이가 우선순위별max_th보다 작은가?우선순위별 확률에 따라 패킷폐기패킷 폐기

WRED는 중요 트래픽을 보호하면서 RED의 글로벌 동기화 완화와 버퍼 관리 이점을 함께 가져간다. 다양한 애플리케이션의 요구를 반영할 수 있지만, 트래픽 클래스마다 파라미터를 설정해야 하므로 관리와 구현의 부담이 커진다. 분류 정확도와 처리 리소스에도 의존한다.

대형 기업 네트워크의 WRED 구현 사례에서는 VoIP 트래픽에 패킷 손실률 1% 미만, 비즈니스 크리티컬 애플리케이션에 5% 미만, 일반 웹 트래픽에 10% 미만의 차등 서비스 품질을 제공해 중요 업무 연속성과 사용자 경험을 개선했다.

큐 관리 방식의 차이

특성 Tail-Drop RED WRED
구현 복잡성 낮음 중간 높음
설정 파라미터 없음 여러 개 우선순위별 다수
글로벌 동기화 방지 없음 효과적 효과적
QoS 지원 없음 제한적 포괄적
리소스 요구사항 최소 중간 높음
성능(처리량) 낮음-중간 중간-높음 높음
지연 시간 높음 중간 낮음(우선순위별)

네트워크 조건에 따라 달라지는 선택

제한된 하드웨어에서 단순한 네트워크를 운영한다면 Tail-Drop으로도 충분할 수 있다. 트래픽이 비교적 균일한 중간 규모 환경에서는 RED가 선택지가 된다.

대규모 엔터프라이즈나 서비스 제공업체 네트워크처럼 트래픽 유형이 다양하고 실시간 애플리케이션의 우선순위가 중요하다면 WRED를 고려할 수 있다. 다만 관리 리소스가 제한된 경우에는 복잡한 정책보다 운영 가능한 메커니즘을 택해야 한다.

RED와 WRED는 트래픽 패턴을 분석한 뒤 파라미터를 설정하고, 성능을 지속적으로 모니터링하며 조정해야 한다. 네트워크 구간마다 다른 방식을 적용하는 하이브리드 구성도 가능하다. ECN(Explicit Congestion Notification) 같은 기술과 함께 사용할 때 효과를 높일 수 있다.

큐 관리가 향하는 방향

혼잡회피는 머신러닝 기반 트래픽 패턴 학습과 선제 대응, SDN(Software-Defined Networking)의 중앙집중식 제어, 애플리케이션 특성에 맞춘 정책으로 확장되고 있다. 네트워크 장비와 엔드포인트가 협력하는 종단간(End-to-End) 혼잡 제어도 함께 발전하는 영역이다.

핵심은 혼잡을 없애는 데 있지 않다. 손실과 지연, 처리량, 서비스 우선순위 사이의 균형을 네트워크 환경에 맞게 관리하는 데 있다.

TCP혼잡제어큐 관리QoS네트워크