Cloudflare가 잡아낸 QUIC CUBIC 버그, ‘idle’ 한 줄 오판이 다운로드를 죽였다

60% 확률로 실패하는 이상한 HTTP/3 테스트

• Cloudflare의 QUIC 구현체 quiche에서 CUBIC 혼잡 제어가 최소 전송량에 갇히는 버그가 나옴

  • CUBIC은 Linux 기본 혼잡 제어 알고리즘이고, TCP뿐 아니라 Cloudflare의 QUIC 구현에서도 기본값으로 쓰임
  • 문제 상황은 10MB 파일을 HTTP/3로 다운로드하는 통합 테스트에서 발견됨
  • 테스트 조건은 localhost, RTT 10ms, 시작 후 2초 동안 30% 랜덤 패킷 손실, 이후 손실 0%

• 정상이라면 초반 손실 때문에 cwnd가 줄었다가, 손실이 멈춘 뒤 다시 커져서 4~5초 안에 다운로드가 끝나야 함

  • 그런데 100회 반복 테스트에서 약 60%가 10초 타임아웃을 넘김
  • 손실은 2초 이후 완전히 사라졌는데도, 전송량이 회복되지 않음
  • Reno로 같은 테스트를 돌리면 100% 통과해서 CUBIC 쪽 문제로 좁혀짐

‘idle’이라고 생각했는데 사실은 congestion limited였음

• qlog를 까보니 CUBIC 상태가 recovery와 congestion avoidance 사이를 RTT마다 왔다 갔다 함

  • 전환 주기는 약 14ms였고, 설정된 RTT 10ms와 매우 가까웠음
  • 다운로드 방향은 서버에서 클라이언트라, 클라이언트 ACK가 서버에 도착할 때마다 서버 쪽 CUBIC 상태 머신이 움직임
  • cwnd가 2패킷까지 줄어든 상태에서는 ACK가 도착하면 bytes_in_flight가 0이 되고, 서버가 곧바로 다음 2패킷을 쏘는 패턴이 반복됨

• 문제의 출발점은 Linux 커널 CUBIC의 idle 최적화였음

  • CUBIC은 epoch_start를 기준으로 성장 곡선을 계산함
  • 앱이 한동안 idle이었다가 다시 보내면 now - epoch_start가 너무 커져서 cwnd가 비정상적으로 커질 수 있음
  • Linux에서는 idle 시간만큼 epoch를 앞으로 밀어 성장 곡선 모양은 유지하되, 갑자기 폭증하지 않게 처리함

• quiche는 이 아이디어를 QUIC에 옮기면서 on_packet_sent() 안에서 bytes_in_flight == 0이면 idle로 판단했음

  • TCP 커널에는 CA_EVENT_TX_START 같은 이벤트가 있지만, QUIC user space 구현에는 같은 방식의 콜백이 없음
  • 그래서 “보내기 직전에 비행 중인 바이트가 0이면 idle에서 재개한 것”이라는 근사 로직을 쓴 셈
  • 이 근사가 cwnd 최소값 근처에서는 완전히 다른 의미가 됨

sequenceDiagram
    participant 서버 as QUIC 서버
    participant CUBIC as CUBIC 상태머신
    participant 클라이언트 as QUIC 클라이언트
    participant 네트워크 as 손실 없는 네트워크
    서버->>클라이언트: 2패킷 전송
    클라이언트->>서버: ACK 도착
    서버->>CUBIC: bytes_in_flight = 0
    CUBIC->>CUBIC: idle로 오판하고 recovery 기준 시간을 미래로 이동
    서버->>클라이언트: 다음 2패킷 전송
    CUBIC->>서버: 아직 recovery라고 판단해 cwnd 성장 스킵

death spiral이 도는 방식

• 최소 cwnd에서는 매 RTT마다 파이프가 완전히 비는 것처럼 보임

  • 서버가 2패킷을 보내고, 한 RTT 뒤 ACK를 받으면 bytes_in_flight가 0이 됨
  • 바로 다음 패킷을 보내는 순간 on_packet_sent()는 이걸 “idle 후 재개”로 해석함
  • 하지만 실제로는 앱이 쉰 게 아니라 cwnd가 너무 작아서 congestion limited 상태였던 것

• 기존 코드는 idle 시간을 now - last_sent_time으로 계산함

  • cwnd가 2패킷이면 last_sent_time은 이전 RTT 사이클의 시작 시각에 가까움
  • 그래서 실제 idle은 거의 0에 가까운데, 계산된 idle delta는 RTT에 가까운 14ms가 됨
  • 이 부풀려진 delta가 recovery start time을 계속 미래로 밀어버림

• recovery start time이 미래로 가면 CUBIC은 계속 “아직 recovery 중”이라고 착각함

  • recovery 중인 패킷에 대해서는 cwnd 성장을 건너뜀
  • cwnd가 안 커지니 다음 ACK 때도 bytes_in_flight가 다시 0이 됨
  • 그 결과 같은 루프가 수천 번 반복되고, 다운로드는 타임아웃까지 질질 끌림

수정은 작았지만 원인 찾기가 빡셌음

• 해결책은 idle 시간을 마지막 송신 시각만 보지 말고, 마지막 ACK 시각까지 고려하는 것임

  • quiche는 CUBIC 상태에 last_ack_time을 추가함
  • 패킷을 보낼 때 idle_start를 last_ack_time과 last_sent_time 중 더 나중 시각으로 잡음
  • 이렇게 하면 cwnd가 작아 ACK 직후 다시 보내는 상황에서 RTT 전체를 idle로 착각하지 않음

• 진짜 idle 연결에 대한 기존 최적화는 유지됨

  • 앱이 실제로 오래 쉬었다면 last_ack_time도 과거에 머물러 있으니 idle duration을 정상적으로 반영함
  • 반대로 ACK를 막 받고 바로 보내는 경우에는 idle gap이 거의 0으로 계산됨
  • Cloudflare는 이 수정 뒤 quiche 테스트 스위트가 다시 100% 통과했다고 밝힘

• 교훈은 꽤 현실적임

  • “bytes_in_flight == 0”은 항상 idle이 아님
  • 작은 cwnd에서는 정상적인 ACK clock 흐름도 idle처럼 보일 수 있음
  • 커널 TCP에서 맞던 최적화를 user space QUIC에 포팅할 때는 이벤트가 발생하는 레이어와 시점을 다시 따져야 함

기술 맥락

• CUBIC의 선택은 “네트워크가 멀쩡하면 더 보내고, 손실이 나면 줄인다”는 loss-based 혼잡 제어의 대표 구현이라서 중요해요. Linux 기본값이다 보니 Cloudflare 같은 대규모 엣지 사업자가 QUIC에서도 같은 알고리즘을 쓰면 운영 경험과 튜닝 지식을 이어갈 수 있거든요.

• 이번 버그의 진짜 포인트는 TCP와 QUIC의 구현 위치가 다르다는 점이에요. TCP CUBIC은 커널 내부 이벤트를 기준으로 움직이지만, quiche는 user space에서 패킷 송수신과 ACK 처리를 직접 다뤄요. 그래서 “송신 직전 bytes_in_flight가 0”이라는 신호가 커널 TCP에서 기대한 의미와 달라질 수 있어요.

• Cloudflare가 qlog로 상태 전환을 시각화한 것도 좋은 선택이에요. 처리량 그래프만 보면 그냥 느린 테스트처럼 보이지만, recovery와 congestion avoidance가 999번 오간다는 이벤트 레벨 증거를 보면 상태 머신이 자기 발목을 잡고 있다는 게 드러나거든요.

• 수정이 작은 이유는 알고리즘 전체가 틀린 게 아니라 시간 기준 하나가 틀렸기 때문이에요. 마지막 패킷을 보낸 시각이 아니라 마지막 ACK를 받은 시각까지 고려하면, 실제 idle과 작은 cwnd에서 생기는 일시적 drain을 구분할 수 있어요.