Reno, CUBIC, BBR

AIMD 원칙은 1980년대에 정립됐습니다. 그 이후 네트워크는 엄청나게 바뀌었습니다. 회선이 빨라졌고, 링크가 길어졌고, 무선이 보편화됐습니다. 이 변화에 맞게 혼잡 제어 알고리즘도 진화했습니다. 오늘날 쓰이는 대표 알고리즘 세 가지를 소개합니다. 수식은 접고, 핵심 아이디어와 어디서 쓰이는지를 봅니다.

TCP Reno — 오리지널

Reno는 AIMD의 교과서적 구현입니다. 3번 중복 ACK를 받으면 cwnd를 절반으로 줄이고, 타임아웃이 나면 1로 리셋합니다. 1990년대 초반 표준이 됐고 수십 년간 인터넷을 지탱했습니다.

약점은 고속·장거리(High BDP, Bandwidth-Delay Product) 링크에서 드러납니다. 서울과 뉴욕 사이처럼 왕복 지연이 150ms 이상인 링크에서 Reno는 손실이 한 번 나면 회복하는 데 너무 오래 걸립니다. 링크 용량이 수백 메가비트여도 cwnd가 충분히 커지기 전에 손실이 나서 계속 줄이는 악순환에 빠집니다.

TCP CUBIC — 현재 리눅스 기본값

CUBIC은 이 문제를 해결하기 위해 만들어졌습니다. cwnd 증가 곡선을 3차 함수(cubic) 모양으로 바꿉니다. 손실이 난 직후에는 빠르게 올라가다가, 이전에 손실이 난 지점 근처에 다가가면 조심스럽게 천천히 올라가고, 그 지점을 안전하게 넘으면 다시 빠르게 올라갑니다.

Reno보다 고속 링크에서 더 빠르게 대역폭을 회복합니다. 현재 리눅스 커널의 기본 TCP 혼잡 제어 알고리즘입니다. 서버를 운영한다면 대부분 CUBIC이 돌고 있습니다.

# 파일: 터미널
# 현재 리눅스의 혼잡 제어 알고리즘 확인
sysctl net.ipv4.tcp_congestion_control

대부분의 리눅스 서버에서 cubic이라고 출력됩니다.

TCP BBR — 접근법이 다른 구글의 알고리즘

BBR(Bottleneck Bandwidth and Round-trip propagation time)은 구글이 2016년 발표한 알고리즘입니다. Reno와 CUBIC이 패킷 손실을 혼잡의 신호로 쓰는 것과 달리, BBR은 다른 방식으로 혼잡을 측정합니다.

BBR은 두 가지 값을 지속적으로 측정합니다. 최대 대역폭과 최소 왕복 지연입니다. 이 두 값을 조합하면 현재 네트워크가 감당할 수 있는 최적의 속도를 추정할 수 있습니다. 패킷이 사라지기 전에 이 추정값을 바탕으로 속도를 조절하므로, 버퍼를 가득 채우지 않고도 최대 처리량 근처에서 운영됩니다.

특히 무선 링크처럼 손실이 혼잡이 아닌 전파 노이즈 때문에 나는 환경에서 BBR이 강점을 보입니다. Reno나 CUBIC은 무선 노이즈로 인한 손실도 혼잡으로 오해해 속도를 줄입니다. BBR은 RTT를 함께 보므로 이 상황을 더 잘 구분합니다.

구글은 YouTube 서버에 BBR을 적용해 처리량이 크게 높아진 것을 확인했습니다. 현재 많은 CDN과 클라우드 서비스가 BBR을 채택하고 있습니다.

알고리즘은 계속 진화한다

혼잡 제어는 아직 활발한 연구 분야입니다. QUIC 위에서 동작하는 새로운 혼잡 제어, 네트워크 장비가 직접 신호를 보내주는 ECN(Explicit Congestion Notification) 기반 방식 등이 함께 발전하고 있습니다. 세부 알고리즘은 바뀌지만 핵심 원칙은 변하지 않습니다. 네트워크는 여럿이 공유하는 공간이고, 각자 눈치껏 자기 속도를 조절해야 모두가 잘 쓸 수 있습니다.

다음 절에서는 Wireshark로 윈도우 변화를 실제로 관찰합니다.