HTTP 3

HTTP는 성능 병목을 해결하기 위해 노력해왔습니다. 주요 문제 중 하나는 HOL(Head‑of‑Line) Blocking이며, HTTP/3는 QUIC 위에서 이 문제를 완화하는 것을 목표로 설계되었습니다.

본 문서는 HOL blocking의 개념을 정리하고, HTTP/1.1→HTTP/2→HTTP/3로 이어지는 해결 전략과 HTTP/3만의 고유 특징을 비교하고 정리합니다.

HOL Blocking이란?

• 정의: 동일한 전송 경로(라인)를 공유하는 여러 메시지 중 맨 앞(Head)에 있는 패킷이 손실 또는 지연되면 뒤따르는 모든 패킷 전달이 지연되는 현상.
• 영향 범위: 손실 복구가 끝날 때까지 연결 전체가 멈춤 → 지연 시간 증가 및 Throughput 감소.

HTTP/1.1에서의 HOL Blocking

구분	메커니즘	결과
연결	다수의 동시 요청 지원 불가 ⇒ 브라우저는 병렬 TCP 연결을 여러 개 생성	OS/네트워크 간 혼잡 제어·버퍼 비효율 ↑
전송	TCP는 바이트 스트림 하나 → 한 패킷이 손실되면 재전송 완료까지 모든 바이트 재정렬 대기	애플리케이션 전체가 HOL Blocking

HTTP/2에서의 HOL Blocking

개선점	한계
하나의 TCP 연결 위에 프레임/스트림 멀티플렉싱 제공 → 애플리케이션 레벨 동시성 ↑	TCP 자체의 HOL Blocking은 그대로 → 패킷 손실 시 모든 스트림이 정지
HPACK 압축 도입 → 헤더 오버헤드 감소	압축 정보가 손실되면, 복구될 때까지 모든 데이터 전송이 멈춤

HTTP/3(QUIC)의 HOL Blocking 해결 전략

Per‑Stream Reliability

• QUIC은 UDP 위 사용자 공간 프로토콜로, 스트림마다 별도 재전송·플로우 컨트롤 수행.
• → 패킷 수준 손실이 발생해도 해당 스트림만 지연, 다른 스트림은 계속 진행.

패킷 손실 시 진행 흐름 비교

TCP (HTTP/2)
┌──Packet Loss──┐
│ 재전송 완료 전 │ ➊ 모든 스트림 멈춤
└──────────────┘

QUIC (HTTP/3)
┌──Packet Loss on Stream #7──┐
│ Stream 7 재전송 대기        │ ➊ *다른 스트림 1‑6,8‑N은 지속*
└──────────────────────────┘

QPACK vs HPACK

• HPACK은 인‑오더 전송 전제 → 패킷 손실 시 압축 상태 동기화 실패 ⇒ 전체 블로킹.
• QPACK은 Encoder/Decoder 각각의 전용 Unidirectional Stream 사용 + 참조 포인트 명시 → 헤더 의존성으로 인한 HOL Blocking가 해소됨.

HTTP/3만의 특징 요약

1. UDP 기반 QUIC – 사용자 공간에서 구현, 커널 업데이트 없이 진화 가능.
2. TLS 1.3 통합 핸드쉐이크 – 0‑RTT/1‑RTT 연결 수립, 지구 반대편에서도 <~~1 RTT 요청 가능.
3. 스트림 레벨 플로우 컨트롤‧재전송 – HOL blocking 최소화.
4. 연결 마이그레이션 – 클라이언트 IP 변경(모바일 ↔ Wi‑Fi) 중에도 연결 유지.
5. 암호화된 패킷 헤더 – 중간 장비에 덜 의존, 프로토콜 진화(버전 협상) 용이.
6. QPACK 헤더 압축 – 비차단형 동기화, 압축 효율·성능 균형.
7. 서버 Push 개선 – MAX_PUSH_ID·CANCEL_PUSH로 세밀한 제어.

---

맺음말

HOL Blocking은 HTTP 성능 최적화에서 큰 걸림돌이었습니다. HTTP/1.1은 동시성 부족을, HTTP/2는 애플리케이션 레벨 멀티플렉싱으로 일부를 해결했으나, 전송 계층(TCP)의 구조적 한계를 뛰어넘지 못했습니다.

HTTP/3는 QUIC, QPACK, 0‑RTT 등 최적화를 통해 웹 애플리케이션의 지연을 줄였습니다. 앞으로 실시간 및 대용량 서비스에서는 이러한 HOL blocking 문제가 완화될 것으로 예상됩니다.