왜 혼잡제어 선택이 문제가 되는가
대역폭이 충분한데도 처리량이 오르지 않거나, 특정 지역 사용자만 유독 느린 경험은 대부분 TCP 혼잡제어 알고리즘과 관련이 있다. Linux 기본값인 CUBIC은 패킷 손실(loss)을 혼잡 신호로 삼는다. 손실이 생기면 전송 윈도우를 절반 가까이 줄이고 다시 올린다. 문제는 현대 네트워크의 손실이 항상 혼잡 때문은 아니라는 점이다. 무선 구간, 장거리 링크, 얕은 버퍼 스위치에서는 혼잡이 없어도 손실이 발생하고, CUBIC은 그때마다 불필요하게 속도를 낮춘다.
반대로 깊은 버퍼가 있는 경로에서는 손실이 늦게 발생해 큐가 가득 찰 때까지 계속 밀어 넣는다. 이로 인해 지연이 수백 ms까지 치솟는 버퍼블로트(bufferbloat)가 생긴다.
BBR은 무엇이 다른가
BBR(Bottleneck Bandwidth and RTT)은 손실이 아니라 대역폭과 최소 RTT를 직접 추정해 전송 속도를 정한다. 병목 링크의 실제 처리량 한계에 맞춰 보내므로, 손실이 잦지만 대역폭은 넓은 경로(예: 국가 간 회선, 모바일)에서 CUBIC보다 훨씬 높은 처리량을 낸다. 큐를 일부러 비우는 구간이 있어 버퍼블로트도 덜하다.
다만 BBR은 만능이 아니다. v1은 CUBIC 흐름과 한 링크를 공유할 때 대역폭을 더 많이 가져가는 불공정성이 보고됐고, 얕은 버퍼에서는 반대로 손실을 유발하기도 한다. 커널 5.x 이상의 개선판을 쓰고, 실제 트래픽으로 검증하는 것이 전제다.
선택 기준 정리
| 상황 | 권장 | 이유 |
|---|---|---|
| 장거리·국가 간 회선 | BBR | 손실 무관하게 대역폭 채움 |
| 모바일/무선 다수 | BBR | 비혼잡 손실에 강함 |
| 데이터센터 내부(저지연·얕은 버퍼) | CUBIC/DCTCP | BBR이 손실 유발 가능 |
| 공용 회선을 다른 흐름과 공유 | 측정 후 결정 | BBR 공정성 이슈 |
적용 방법
BBR은 큐 규율로 fq(fair queue) 또는 fq_codel과 함께 쓰는 것이 안정적이다. 런타임 적용과 영구 설정을 나눠서 진행한다.
# 현재 값 확인
sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc
# 사용 가능한 알고리즘 확인 (bbr이 없으면 모듈 로드)
sysctl net.ipv4.tcp_available_congestion_control
modprobe tcp_bbr
# 영구 적용
cat >/etc/sysctl.d/99-bbr.conf <<'EOF'
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
EOF
sysctl --system
바꾸기 전에 반드시 측정
전역으로 바꾸기 전에 A/B로 비교한다. 소켓 단위로 알고리즘을 지정하면 서비스 전체를 건드리지 않고 특정 연결만 테스트할 수 있다.
import socket
TCP_CONGESTION = 13 #
def connect_with(algo: str, host: str, port: int):
s = socket.create_connection((host, port))
s.setsockopt(socket.IPPROTO_TCP, TCP_CONGESTION, algo.encode())
used = s.getsockopt(socket.IPPROTO_TCP, TCP_CONGESTION, 16)
print("적용된 알고리즘:", used.rstrip(b"\x00").decode())
return s
connect_with("bbr", "example.internal", 443)
실측은 ss -ti로 연결별 cwnd·rtt·retrans를, iperf3나 실제 응답 지연(p50/p99)을 함께 본다. 처리량만 오르고 p99 지연이 나빠지면 이득이 아니다.
주의점
- 커널 버전을 먼저 확인한다. BBR 관련 개선은 5.x 이후에 많이 들어갔고, 오래된 커널의 BBR은 권장하지 않는다.
- 데이터센터 내부처럼 RTT가 짧고 버퍼가 얕은 환경에서는 BBR이 오히려 손실과 재전송을 늘릴 수 있으니 CUBIC 유지 또는 DCTCP를 검토한다.
- 혼잡제어는 발신 측(주로 서버) 설정이 지배적이다. 다운로드 처리량을 개선하려면 콘텐츠를 내보내는 서버에서 바꿔야 한다.
- 전역 변경은 롤백 절차를 준비하고, sysctl 파일과 함께 적용 시각·측정값을 기록해 회귀 여부를 추적한다.
결론적으로 BBR과 CUBIC은 우열이 아니라 경로 특성의 문제다. 손실이 대역폭을 발목 잡는 넓고 먼 경로는 BBR이, 짧고 얕은 내부 경로는 CUBIC 계열이 유리하다. 반드시 자기 트래픽으로 측정한 뒤 결정한다.