서로 다른 혼잡 신호와 알고리즘 계보

TCP 혼잡 제어기는 송신률을 조정해 경로 용량을 이용하면서 혼잡을 다룬다. CUBIC은 혼잡 후 윈도우 증가를 시간 기반 3차 함수로 설계한 방식이며 RFC 9438이 2023년 Standards Track 규격으로 갱신했다. Google이 개발한 BBR은 병목 대역폭과 최소 RTT 추정치를 이용해 전달률을 조절하는 모델 기반 계열이다. 이를 “손실을 무시한다”거나 모든 네트워크에서 지연과 손실을 없앤다고 설명하면 부정확하다. 실제 동작은 BBR 버전과 구현, 손실·ECN 처리, 네트워크 조건에 따라 다르다.

표준 지위와 버전

CUBIC은 RFC 9438에 알고리즘이 기술되어 있고 여러 TCP 스택에서 채택되었다고 규격 자체가 설명한다. 반면 BBR의 IETF 문서는 현재 Internet-Draft이며 RFC 표준과 동일한 지위를 갖지 않는다. 초안의 버전과 각 운영체제에 포함된 코드의 버전은 일치한다고 가정하지 않는다. 특히 BBRv1 연구 결과를 BBRv2 또는 BBRv3의 성능으로 바꾸어 말하면 안 된다. 제품·커널 배포판·빌드에 실제로 포함된 혼잡 제어기를 확인한다.

Linux에서 켜는 조건

Linux에서는 커널에 관련 모듈과 설정이 포함되어 있어야 하며, 실제 선택 가능 알고리즘은 sysctl net.ipv4.tcp_available_congestion_control로 확인한다. BBR을 제공하는 커널에서 net.ipv4.tcp_congestion_control=bbr로 선택할 수 있지만, 적용 범위와 기본값은 배포판 및 소켓 설정에 달렸다. Google의 BBR FAQ는 송신 측 pacing과 fq 큐잉 규율을 통한 구현 경로를 설명하므로, 알고리즘 이름만 바꾸고 종단 간 처리량 개선을 약속하지 말아야 한다. 다른 OS의 설정은 해당 TCP 스택 문서를 따라야 한다.

전문가 측정이 보여 준 한계

Jaeger, Scholz, Raumer, Geyer, Carle의 2019년 재현 가능한 에뮬레이션 연구는 당시 평가한 BBR 구현이 다른 혼잡 제어기와 경쟁할 때 공정성 문제를 보일 수 있다고 보고했다. 저자들은 CUBIC, Reno, Vegas, Illinois 등과의 상호작용 및 BBR 흐름 간 공정성을 실험했다. 이 연구는 특정 시점의 BBR 구현과 설정을 다룬 것이므로 모든 현재 BBR 버전에 대한 결론은 아니다. 오히려 함께 흐르는 알고리즘, RTT, 병목, 버퍼 및 손실 조건을 명시한 재시험이 필요하다는 근거로 읽어야 한다.

비교 시 확인할 지표

처리량 하나만으로 승자를 고르지 말고 RTT 지연, 큐 점유, 손실·재전송, 여러 흐름 간 공정성, RTT가 다른 흐름 간 결과를 같은 병목 조건에서 측정한다. BBR의 대역폭 탐색은 일시적인 큐를 만들 수 있고, CUBIC도 구현과 경로 조건에 따라 지연·공정성 특성이 달라진다. 여기서 전문가 관점은 명시된 저자들의 재현 연구이며, 현재 운영체제의 성능 보증이 아니다.

참고 자료