본문으로 건너뛰기

안동민 개발노트

본문 시작

HTTP/3와 QUIC

HTTP/3가 QUIC의 독립 스트림·통합 TLS·빠른 연결·연결 이동으로 TCP의 구조적 지연을 줄이는 방식을 이해합니다.

이전 절에서 HTTP/2가 HTTP 계층의 HOL Blocking을 크게 줄였지만, TCP 계층의 HOL Blocking은 여전히 남아있다는 것을 확인했습니다.

HTTP/3는 HTTP의 의미를 QUIC 위에 매핑해 이 문제를 줄입니다.

TCP의 구조적 한계

TCP는 순서 보장을 핵심 특성으로 설계되었습니다.

패킷 3이 유실되면, 패킷 4와 5가 이미 도착해 있어도 애플리케이션에 전달하지 않습니다.

TCP는 빠진 바이트가 채워질 때까지 뒤 바이트를 넘기지 않는다

순서 보장은 강점이지만 여러 논리 stream이 한 TCP 연결을 공유하면 손실 하나가 전체 지연으로 번진다.

  1. 1
    1 byte 1

    byte 1 도착 애플리케이션 전달 가능

  2. 2
    2 byte 2

    byte 2 도착 전달 가능

  3. 3
    3 byte 3

    byte 3 손실 빈 구간 발생

  4. 4
    4 byte 4

    byte 4 먼저 도착 커널 버퍼에서 대기

  5. 5
    5 retransmit

    retransmit byte 3 재전송 순서가 복구된 뒤 전달

QUIC의 해결 방식

QUIC은 UDP 위에서 동작하는 안전한 범용 전송 프로토콜입니다.

초기에는 Google의 실험적 프로토콜에서 출발했지만, 표준 QUIC에서는 QUIC을 약어가 아니라 프로토콜 이름으로 정의합니다.

QUIC은 TCP+TLS 기능을 UDP 위 전송 계층 안으로 옮긴다

UDP datagram을 쓰지만 손실 탐지, 재전송, 흐름 제어, TLS 1.3 handshake는 QUIC이 직접 제공한다.

  1. 1

    HTTP/3 요청/응답을 QUIC stream에 매핑

  2. 2

    QUIC streams stream별 flow control과 독립 재전송

  3. 3

    QUIC packets packet number, ACK, congestion control

  4. 4

    TLS 1.3 inside QUIC handshake와 key schedule 통합

  5. 5

    UDP NAT/방화벽을 지나는 datagram 운반

UDP를 사용한다고 해서 QUIC이 신뢰성을 포기하는 것은 아닙니다.

QUIC은 UDP 위에 자체적인 전송 계층을 구축합니다.

패킷 유실 탐지, 재전송, 흐름 제어, 혼잡 제어를 QUIC이 직접 수행하고, 애플리케이션 데이터는 여러 스트림에 나뉘어 전달됩니다.

핵심은 손실의 영향 범위입니다.

TCP에서는 하나의 순서 있는 바이트 스트림이 막히지만, QUIC에서는 손실된 패킷에 들어 있던 스트림 데이터가 주로 영향을 받습니다.

단, 혼잡 제어는 연결 전체에 걸쳐 동작하고, 하나의 QUIC 패킷에 여러 스트림 데이터가 함께 들어 있으면 그 스트림들이 같이 영향을 받을 수 있습니다.

연결 수립 속도

QUIC은 전송 핸드셰이크와 TLS 1.3을 한 번에 묶는다

HTTP/3는 TCP 위에 TLS를 올리는 대신, QUIC 안에 TLS 1.3과 전송 기능을 통합합니다. 새 연결은 보통 1-RTT, 조건이 맞는 재연결은 0-RTT로 시작할 수 있습니다.

  1. ClientHello + QUIC transport params

    Initial ClientHello + QUIC transport params 클라이언트가 TLS 시작 정보와 QUIC 전송 설정을 같이 보냅니다.

  2. ServerHello와 키 확정

    1-RTT ServerHello와 키 확정 서버 응답 뒤 암호화된 애플리케이션 데이터 전송 준비가 됩니다.

  3. 재연결에서는 early data 가능

    0-RTT 재연결에서는 early data 가능 이전 세션 정보가 있고 요청이 replay-safe일 때만 사용합니다.

  4. UDP 443이 막히면 HTTP/2로 후퇴

    fallback UDP 443이 막히면 HTTP/2로 후퇴 기업망, 프록시, 방화벽 환경에서는 TCP 기반 경로가 필요할 수 있습니다.

  5. 클라이언트는 HTTP/3 가능성을 먼저 배운다

    Alt-Svc 클라이언트는 HTTP/3 가능성을 먼저 배운다 서버나 CDN이 `h3=":443"`을 광고해야 전환이 시작됩니다.

  6. 빠른 만큼 재전송 공격을 고려한다

    0-RTT 빠른 만큼 재전송 공격을 고려한다 GET처럼 멱등성이 있는 요청에 제한하는 편이 안전합니다.

  7. Connection ID가 경로 변경을 버틴다

    migration Connection ID가 경로 변경을 버틴다 Wi-Fi와 LTE 전환처럼 IP가 바뀌어도 같은 연결을 이어갈 수 있습니다.

QUIC은 전송 핸드셰이크와 TLS 1.3 핸드셰이크를 통합합니다.

패킷 손실이 없으면 새로운 보안 연결을 보통 1 RTT 안에 만들 수 있고, 같은 서버에 재접속하는 경우에는 조건이 맞을 때 0-RTT 데이터 전송도 가능합니다.

다만 0-RTT는 재전송 공격(replay) 가능성을 고려해야 하므로, 모든 요청에 안전하게 쓸 수 있는 기능은 아닙니다.

연결 마이그레이션

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

Connection ID는 IP가 바뀌어도 같은 QUIC 연결을 찾게 한다

Wi-Fi에서 LTE로 바뀌어 4-tuple이 달라져도 CID와 path validation이 맞으면 기존 연결 상태를 이어갈 수 있다.

  1. 1 path A

    path A Wi-Fi IP/port CID 7로 통신

  2. 2 move

    move 네트워크 전환 4-tuple 변경

  3. 3 path B

    path B LTE IP/port 같은 CID 제시

  4. 4 validate

    validate path 확인 도달성과 소유 확인

  5. 5 continue

    continue stream 상태 유지 연결 재수립 비용 감소

TCP 연결은 보통 4튜플(출발지 IP/포트, 목적지 IP/포트)에 강하게 묶여 있어 경로가 바뀌면 연결이 끊기기 쉽습니다.

QUIC은 Connection ID로 연결을 식별하고, 새 네트워크 경로를 검증한 뒤 같은 연결 상태를 이어갈 수 있도록 설계되어 있습니다.

실제 성공 여부는 서버, 로드 밸런서, NAT, 방화벽, UDP 허용 여부에 따라 달라집니다.

QUIC은 항상 암호화

TCP 자체는 암호화를 제공하지 않고, 보통 TLS가 그 위에 올라갑니다.

QUIC은 TLS 1.3 핸드셰이크를 전송 프로토콜 안에 통합하고, 가능한 많은 패킷 필드를 암호화와 무결성 보호 대상으로 삼습니다.

QUIC은 TLS 1.3을 전송 계층 안에 통합한다

보안은 TCP 위의 별도 층이 아니라 handshake, packet 보호, stream 암호화와 함께 전송 프로토콜에 들어간다.

  1. 1 Initial

    Initial TLS 1.3 handshake 시작 버전과 연결 파라미터 협상

  2. 2 Handshake

    Handshake 서버 인증 키 재료 확정

  3. 3 1-RTT

    1-RTT 보호된 application data HTTP/3 stream 전송

  4. 4 Key update

    Key update 장기 연결 보호 운영 중 키 갱신

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

HTTP/3는 이미 주요 브라우저, CDN, 대형 서비스에서 널리 지원되지만, 실제 사용 비율은 네트워크와 서비스 유형에 따라 차이가 큽니다.

예를 들어 Cloudflare의 2025 Year in Review는 Cloudflare 네트워크 요청 기준으로 HTTP/2가 50%, HTTP/1.x가 29%, HTTP/3가 21%였다고 보고했습니다.

이는 웹 전체의 절대 비율이라기보다 측정 지점에 따른 관측값으로 봐야 합니다.

시나리오우선 검토이유
모바일 사용자 많음HTTP/3연결 마이그레이션과 빠른 재연결 이점
고지연/고손실 네트워크HTTP/3스트림 간 HOL Blocking 완화
CDN 사용HTTP/3CDN이 지원하면 엣지 설정만으로 시작하기 쉬움
UDP 차단 환경HTTP/2기업망, 프록시, 방화벽에서 UDP 443이 막힐 수 있음
레거시 호환 필요HTTP/2오래된 클라이언트와 중간 장비 호환성이 더 넓음
내부 서비스측정 후 결정안정적 저지연 네트워크에서는 체감 이점이 작을 수 있음
http3_check.sh
# 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/3와 QUIC을 도입할 때 확인해야 하는 운영 기준을 정리합니다.

HTTP/3 도입은 Alt-Svc, UDP 경로, fallback을 함께 검증한다

HTTP/3를 켜도 모든 네트워크가 UDP를 통과시키지 않는다. 성공률과 HTTP/2 fallback을 같이 봐야 한다.

  1. 1 advertise

    advertise Alt-Svc로 h3 안내 브라우저가 대안 프로토콜 인지

  2. 2 probe

    probe UDP/443 경로 확인 방화벽과 NAT 통과

  3. 3 serve

    serve h3 요청 처리 성공 latency와 오류율 측정

  4. 4 fallback

    fallback h2로 복귀 실패가 사용자 오류가 되지 않게 함

  5. 5 monitor

    monitor 망별 성공률 ISP, 지역, 단말별 분리

HTTP/3와 QUIC에서는 프로토콜 상태, 실패 응답, 관측 도구, 복구 기준을 확인합니다.

QUIC 운영은 경로, CID, 0-RTT, fallback을 한 표에서 점검한다

성공 연결만 보지 말고 망 전환, 재접속, UDP 차단, backend 일관성까지 같은 운영 체크리스트로 관리한다.

  1. Path 망별 UDP 손실

    차단 특정 ISP나 모바일망 timeout

  2. CID migration

    backend 매핑 경로 변경 후 stream reset

  3. 0-RTT 허용 요청의 idempotency 중복

    주문, 중복 결제 위험

  4. Fallback HTTP/2 전환 시간 h3 실패

    사용자 지연으로 노출

  5. Observe qlog, handshake

    retry 지표 원인을 h2와 구분 못함

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

HTTP/2

이전 페이지

WebSocket과 실시간 통신

다음 페이지

이 페이지의 목차

TCP의 구조적 한계QUIC의 해결 방식연결 수립 속도연결 마이그레이션QUIC은 항상 암호화HTTP/3 도입 현황과 판단 기준