QUIC 손실 회복과 패킷 암호화는 HTTP/3의 체감 성능을 좌우합니다. “UDP라 빠르다”가 아니라, 손실을 어떻게 감지·해석하고 언제 무엇을 다시 보낼지, 그리고 키를 어떻게 파생·회전하는지가 속도를 가릅니다. 아래는 운영·개발 현장에서 바로 써먹을 수 있도록 기존 소제목을 유지해 더 촘촘히 풀어쓴 가이드입니다.
1) QUIC가 빠른 진짜 이유
TCP는 커널 레벨 고정 로직과 연결 단위 HOL(헤드 오브 라인) 블로킹 탓에 한 패킷의 손실이 전체 스트림을 멈춥니다. QUIC은 사용자 공간에서 동작하고, 스트림 단위 재전송으로 손실의 영향을 해당 스트림에 국소화합니다. 또한 TLS 1.3과 핸드셰이크를 통합해 0-RTT/1-RTT에 연결을 올려, 초기 지연부터 줄입니다. 즉, 구조 자체가 “빠름”을 위한 설계입니다.
2) 암호화 레벨: Initial → Handshake → 1-RTT
QUIC은 암호화 레벨마다 독립 키를 씁니다.
- Initial: 연결 개시용. 버전별 고정 라벨에서 파생되는 임시 키로 보호하며, 중간자 조작을 억제합니다.
- Handshake: TLS 메시지 운반. 여기서 양측 비밀이 합의됩니다.
- 1-RTT: 애플리케이션 데이터용 본 키. 이후 키 업데이트로 순환합니다.
이 분리 덕분에 구간별 장애가 서로 전염되지 않고, 장기 연결에서도 무중단 재키잉이 가능합니다.
3) 키 파생: TLS 1.3 + HKDF
핵심은 HKDF(Extract/Expand) 로부터 나온 traffic secret을 두 갈래로 쓰는 것입니다.
- Payload 보호 키: AEAD(AES-GCM 또는 ChaCha20-Poly1305)로 본문을 암복호.
- Header 보호 키: 패킷 번호 필드를 가려 중간 장비의 번호 추정·필터링을 어렵게 만듭니다.
헤더 보호는 단순 보안 기능을 넘어 재전송 혼선을 줄여 손실 회복의 신뢰도를 높이는 효과가 있습니다.
4) ACK 프레임과 ACK Ranges
QUIC은 ACK Ranges로 “받은 구간과 비어 있는 구간”을 범위로 통지합니다. 이게 중요한 이유는 다음과 같습니다.
- 재정렬 구분: 순서가 바뀌어 도착한 패킷을 손실로 오인하지 않음.
- 중복 억제: 이미 받은 범위를 명확히 알려 중복 재전송을 줄임.
- 의미 있는 타이머만 가동: ack-eliciting frame(데이터·핸드셰이크 중요 프레임 등)을 보냈을 때만 손실 타이머를 건드려 불필요한 재전송을 회피합니다.
5) 타이머 모델: PTO와 재전송
TCP의 RTO보다 적극적인 모델이 PTO(Probe Timeout) 입니다.
- 계산: SRTT/RTTVAR로 추정한 왕복 기반.
- 행동: 만료 시 소수의 탐침 패킷을 보내 ACK를 유도, 손실 여부를 빠르게 확정.
- 분리: Initial, Handshake, 1-RTT 등 패킷 번호 공간별로 독립 동작해 한 구간의 문제로 전체가 멈추지 않습니다.
결과적으로 고손실 환경에서도 “무의미한 전면 재전송”이 줄어 지연 꼬리가 짧아집니다.
6) 혼잡제어와의 결합: BBR/CUBIC/HyStart++
손실 감지(로스 디텍션)와 전송률 결정(혼잡제어) 는 QUIC에서 느슨히 결합됩니다.
- BBR: 병목 대역폭·최소 RTT 모델로 손실이 높아도 대역폭이 살아있으면 불필요 감속을 피함. 고손실 모바일·와이파이에서 체감 향상 큼.
- CUBIC: 공존성·안정성 장점. 혼합 트래픽에서 무난.
- HyStart++: 초기 혼잡 회피를 더 부드럽게 해 초기 폭주를 줄임.
실전 포인트는 “손실 판단은 빠르게, 전송률 조정은 보수적으로”라는 리듬을 유지하는 것입니다.
7) 재키잉(Key Update)와 장기 연결
장기 연결은 같은 키를 오래 쓰면 분석 위험이 커집니다. QUIC은 패킷 수·시간 기준으로 키를 자동 회전시키고, 구·신 키가 잠시 공존하는 전환 창에서 자연스럽게 넘어갑니다. 이 과정은 애플리케이션에 투명하며, CPU·지연 비용도 미미합니다.
8) 실전 튜닝 포인트(운영 체크)
- PTO 상한: 기본값에서 시작해 p95 TTFB 기준으로만 소폭 조정. 너무 공격적이면 큐가 쌓이고, 너무 느리면 불필요 체류가 생깁니다.
- ACK 지연: 모바일 배터리를 아낀다며 과도하게 늘리면 손실 판단이 늦어집니다. 서버-클라이언트 균형이 핵심.
- MTU/패딩: 초기엔 보수적 MTU로 시작해 패킷 단편화를 피하고, 경로가 안정되면 점진 확장. 단편화는 재전송 폭탄의 시작입니다.
- 번호 공간별 지표: Initial/Handshake/1-RTT 손실률을 분리해서 보세요. 핸드셰이크 쪽만 유난히 높다면 중간 장비/방화벽의 간섭 가능성.
- BBR v2 + ECN: ECN 지원 장비라면 마킹으로 손실 없이 혼잡을 알리고 큐를 억제. p95 지연이 안정됩니다.
- 키 업데이트 주기: 규정·위협 모델을 고려해 기본 주기 ± 수준에서 운영. 너무 잦으면 CPU 낭비, 너무 드물면 노출면 증가.
- CPU 바인딩 완화: 암복호가 병목이면 ChaCha20-Poly1305(특히 ARM)와 배치 암복호를 검토하고, 레코드 크기를 조정해 캐시 효율을 끌어올리세요.
9) 관찰 지표: “빠르다”를 수치로 증명
- 연결·핸드셰이크: 0-RTT 성공률, 1-RTT 소요 시간
- 지연: SRTT/RTTVAR, p50/p95/p99 TTFB
- 손실/재전송: 패킷 공간별 손실률, PTO 발생률, 재전송율, 재전송 중복률
- 혼잡: Inflight 바이트, pacing rate, ECN 마크율
- 암호화 비용: 키 업데이트 이벤트 빈도, 암복호 CPU 비중
이 지표를 릴리스·라우팅 변경·캠페인 타임라인과 나란히 두면 원인-결과 상관관계가 선명해집니다.
10) FAQ로 정리하는 핵심
Q. QUIC 손실 회복이 TCP보다 항상 빠른가요?
대부분의 모바일·와이파이·혼잡/손실 혼재 환경에서 그렇습니다. 스트림 단위 복구와 PTO 영향입니다. 다만 코어망 혼잡 지배 상황에선 혼잡제어 선택과 튜닝이 더 큽니다.
Q. 0-RTT는 그냥 켜도 되나요?
읽기·캐시성에는 좋지만, 재생 공격 제한이 있어 민감 트랜잭션은 1-RTT로 확정하세요. 경로별 화이트리스트를 권장합니다.
Q. 암복호가 CPU 병목이면?
ChaCha20-Poly1305 전환(특히 ARM), 배치 처리, 레코드 크기 조정, TLS 오프로딩(가능 환경)으로 완화합니다.
Q. BBR이 공정하지 않다는 피드백이 있습니다.
BBR v2로 전환하고 ECN을 켜 보세요. 또한 pacing 상한을 낮추면 큐 빌드업이 줄어 공정성 지표가 개선됩니다.
11) 바로 적용 체크리스트
- PTO/ACK Delay 기본값에서 시작, p95 TTFB 기준으로 미세 조정
- 패킷 번호 공간별 손실 분리 모니터링(Initial/Handshake/1-RTT)
- MTU/단편화 점검, 초기 패딩 후 점진 확장
- BBR v2 + ECN 조합으로 p95 안정화 A/B
- 키 업데이트 주기 적정화, 암복호 CPU 프로파일링
- 0-RTT는 민감 API 제외 후 도입
- 대시보드에 Inflight·Pacing·ECN·재전송 중복률 추가
마무리
속도는 우연이 아닙니다. 손실을 어떻게 판단하고(ACK Ranges, PTO), 무엇을 언제 다시 보내며(스트림 단위 재전송), 키를 어떻게 굴릴지(TLS 1.3 + HKDF, Key Update) 를 이해하고 손대는 순간, HTTP/3의 성능은 한 단계 올라갑니다. 오늘은 번호 공간별 손실과 PTO/ACK Delay를 점검하고, 내일은 BBR v2 + ECN과 MTU를 다듬어 보세요. 지표는 투명하게 좋아지고, 사용자는 “빠르다”를 체감하게 됩니다.