TCP 혼잡 제어: Reno·CUBIC·BBR과 실시간 게임 트래픽 · 해설

난이도: 중상

모범답안

1. 혼잡 제어의 기본 골격

TCP 송신자는 두 개의 윈도우로 전송량을 제한한다. **수신 윈도우(rwnd)**는 수신자 버퍼가 감당할 양(흐름 제어)이고, **혼잡 윈도우(cwnd)**는 네트워크가 감당할 양(혼잡 제어)이다. 실제 전송 가능량은 min(rwnd, cwnd). 흐름 제어는 "수신자가 느려서"이고, 혼잡 제어는 "네트워크가 막혀서"라는 점에서 원인이 다르다.

연결 초기에는 슬로우 스타트로 cwnd를 매 RTT마다 지수적으로(대략 2배씩) 늘려 가용 대역폭을 빠르게 탐색한다. cwnd가 **ssthresh(슬로우 스타트 임계값)**에 도달하면 혼잡 회피로 전환해 매 RTT마다 대략 1 MSS씩 선형 증가한다. 혼잡 신호(손실)가 감지되면 ssthresh와 cwnd를 줄인다.

2. 손실 기반 vs 모델 기반

Reno/NewReno (AIMD): 혼잡 회피에서 가법 증가(RTT당 +1 MSS), 손실 시 승법 감소(cwnd 반감). 3개의 중복 ACK를 받으면 타임아웃을 기다리지 않고 빠른 재전송(fast retransmit) 후 **빠른 회복(fast recovery)**으로 cwnd를 절반에서 재개한다. 톱니(sawtooth) 모양의 윈도우. 문제는 BDP(대역폭×지연)가 큰 링크에서 반감 후 다시 채우는 데 오래 걸려 대역폭을 못 채운다는 점.

CUBIC (리눅스 기본): 손실 이후 윈도우를 3차 함수 곡선으로 키운다. 손실 직전 크기(W_max) 근처에서는 천천히(안정), 그로부터 멀어지면 공격적으로 성장한다. 성장 시간이 RTT에 비의존적(실시간이 기준)이라 고지연 링크에서 Reno보다 공정하고 대역폭을 잘 채운다. 여전히 손실 기반이라 버퍼를 채운 뒤 손실로 물러난다.

BBR: 패킷 손실을 혼잡 신호로 쓰지 않는다. 대신 **병목 대역폭(BtlBw)**과 **왕복 전파 지연(RTprop, 최소 RTT)**을 지속 추정해 BDP = BtlBw × RTprop만큼만 파이프에 채운다. 큐가 쌓이기 전 지점(BDP)에서 동작하므로 라우터 버퍼를 덜 채우고 지연이 낮다. 주기적으로 대역폭을 재탐색(ProbeBW)하고 가끔 전송을 비워 최소 RTT를 재측정(ProbeRTT). 손실이 잦지만 대역폭은 넉넉한(예: 무선) 환경에서 손실 기반보다 처리량이 높을 수 있다.

3. 버퍼블로트와 지연

손실 기반 알고리즘은 "손실이 날 때까지" 전송을 늘리므로, 라우터의 큰 버퍼를 가득 채운 뒤에야 물러난다. 버퍼가 차 있으면 모든 패킷이 그 큐를 통과하느라 지연이 수십~수백 ms 늘어난다(버퍼블로트). 실시간 게임에서 입력→반영 지연이 커지면 조작감이 무너지므로 치명적이다. BBR/AQM은 큐를 얕게 유지해 이 지연을 줄인다.

4. 게임 서버에서의 함의

실시간 게임이 주로 UDP를 쓰는 이유는 TCP의 머리줄 막힘(head-of-line blocking) 때문이다 — 한 패킷 손실이 뒤의 모든 데이터 전달을 막아, 오래된 상태를 기다리게 만든다. 게임은 "최신 상태"가 중요하므로 유실은 무시하고 다음 스냅샷을 쓰는 편이 낫다.

그럼에도 로그인·상점 결제·매치 결과·패치 다운로드처럼 신뢰성·순서가 필수인 경로는 TCP를 쓴다. 문제는 같은 네트워크 경로에서 **대용량 TCP 전송(패치 다운로드)**이 버퍼를 채우면 실시간 UDP 트래픽까지 지연이 커진다는 것. 완화책:

트래픽 분리: 실시간과 벌크를 다른 연결/포트/경로로, 가능하면 다른 서버로.
AQM(fq_codel/CAKE): 라우터/서버 큐에서 흐름을 공정 분배하고 큐를 얕게 유지.
ECN(명시적 혼잡 통지): 손실 대신 표시로 혼잡을 알려 지연·재전송을 줄임.
혼잡 제어 선택: 대역폭·지연 특성에 맞춰 CUBIC/BBR 선택(BBR은 지연에 유리하나 공정성 논쟁이 있으니 환경별 검증 필요).
QoS/DSCP 마킹으로 실시간 트래픽 우선순위 부여(경로가 지원할 때).

핵심 요약