HTTP/3와 QUIC

이전 절에서 HTTP/2가 HTTP 계층의 HOL Blocking을 크게 줄였지만, TCP 계층의 HOL Blocking은 여전히 남아있다는 것을 확인했습니다. HTTP/3는 HTTP의 의미를 QUIC 위에 매핑해 이 문제를 줄입니다.

TCP의 구조적 한계

TCP는 순서 보장을 핵심 특성으로 설계되었습니다. 패킷 3이 유실되면, 패킷 4와 5가 이미 도착해 있어도 애플리케이션에 전달하지 않습니다.

QUIC의 해결 방식

QUIC은 UDP 위에서 동작하는 안전한 범용 전송 프로토콜입니다. 초기에는 Google의 실험적 프로토콜에서 출발했지만, 표준 QUIC에서는 QUIC을 약어가 아니라 프로토콜 이름으로 정의합니다.

UDP를 사용한다고 해서 QUIC이 신뢰성을 포기하는 것은 아닙니다. QUIC은 UDP 위에 자체적인 전송 계층을 구축합니다. 패킷 유실 탐지, 재전송, 흐름 제어, 혼잡 제어를 QUIC이 직접 수행하고, 애플리케이션 데이터는 여러 스트림에 나뉘어 전달됩니다.

핵심은 손실의 영향 범위입니다. TCP에서는 하나의 순서 있는 바이트 스트림이 막히지만, QUIC에서는 손실된 패킷에 들어 있던 스트림 데이터가 주로 영향을 받습니다. 단, 혼잡 제어는 연결 전체에 걸쳐 동작하고, 하나의 QUIC 패킷에 여러 스트림 데이터가 함께 들어 있으면 그 스트림들이 같이 영향을 받을 수 있습니다.

연결 수립 속도

QUIC은 전송 핸드셰이크와 TLS 1.3 핸드셰이크를 통합합니다. 패킷 손실이 없으면 새로운 보안 연결을 보통 1 RTT 안에 만들 수 있고, 같은 서버에 재접속하는 경우에는 조건이 맞을 때 0-RTT 데이터 전송도 가능합니다. 다만 0-RTT는 재전송 공격(replay) 가능성을 고려해야 하므로, 모든 요청에 안전하게 쓸 수 있는 기능은 아닙니다.

연결 마이그레이션

모바일 환경에서 Wi-Fi와 LTE를 전환하면 IP 주소가 바뀝니다.

TCP 연결은 보통 4튜플(출발지 IP/포트, 목적지 IP/포트)에 강하게 묶여 있어 경로가 바뀌면 연결이 끊기기 쉽습니다. QUIC은 Connection ID로 연결을 식별하고, 새 네트워크 경로를 검증한 뒤 같은 연결 상태를 이어갈 수 있도록 설계되어 있습니다. 실제 성공 여부는 서버, 로드 밸런서, NAT, 방화벽, UDP 허용 여부에 따라 달라집니다.

QUIC은 항상 암호화

TCP 자체는 암호화를 제공하지 않고, 보통 TLS가 그 위에 올라갑니다. QUIC은 TLS 1.3 핸드셰이크를 전송 프로토콜 안에 통합하고, 가능한 많은 패킷 필드를 암호화와 무결성 보호 대상으로 삼습니다.

HTTP/3 도입 현황과 판단 기준

HTTP/3는 이미 주요 브라우저, CDN, 대형 서비스에서 널리 지원되지만, 실제 사용 비율은 네트워크와 서비스 유형에 따라 차이가 큽니다. 예를 들어 Cloudflare의 2025 Year in Review는 Cloudflare 네트워크 요청 기준으로 HTTP/2가 50%, HTTP/1.x가 29%, HTTP/3가 21%였다고 보고했습니다. 이는 웹 전체의 절대 비율이라기보다 측정 지점에 따른 관측값으로 봐야 합니다.

# HTTP/3 지원으로 빌드된 curl에서 확인
curl -I --http3 https://www.google.com 2>&1 | head -3
# HTTP/3 200

# Alt-Svc 헤더로 HTTP/3 지원 확인
curl -sI https://www.cloudflare.com | grep -i alt-svc
# alt-svc: h3=":443"; ma=86400

다음 절에서는 HTTP의 요청-응답 모델을 벗어나 양방향 실시간 통신을 가능하게 하는 WebSocket을 다루겠습니다.