HTTP 3.0과 QUIC: UDP 기반 웹 전송 계층의 변화

HTTP 3.0이 QUIC와 UDP 위에서 연결 설정, HoL 블로킹, 보안, 네트워크 전환을 처리하는 방식을 정리한다.

2026-08-14 · 최초 발행 2025-08-10

HTTP/2의 다중화가 남긴 전송 계층 문제

HTTP 1.0과 HTTP 1.1은 TCP 기반에서 연결당 단일 요청과 응답을 처리하던 초기 웹 프로토콜이다. HTTP 2.0은 다중 스트림과 헤더 압축을 도입했지만, TCP를 기반으로 한다는 제약은 남아 있었다.

HTTP 3.0은 이 지점을 전송 계층부터 바꾼다. 처음에는 HTTP-over-QUIC으로 불렸으며, UDP 기반 QUIC 위에서 동작하도록 설계됐다. 목표는 더 빠르고 안정적인 웹 경험이다.

QUIC 위에 놓인 HTTP 3.0

QUIC(Quick UDP Internet Connections)은 Google이 TCP의 한계를 넘기 위해 UDP 기반으로 설계한 프로토콜이다. HTTP 3.0은 QUIC을 이용해 애플리케이션 계층과 IP 사이의 전송 방식을 구성한다.

애플리케이션 계층HTTP 3.0QUICUDPIP기존 스택HTTP 1.1/2.0TCP

연결 설정과 스트림 처리가 달라지는 지점

Zero-RTT로 재연결 지연 줄이기

기존 TCP와 TLS 연결에는 여러 왕복(RTT)이 필요했지만, HTTP 3.0은 이를 줄인다. 최초 연결은 1-RTT로 약 100ms가 소요되며, 재연결은 Zero-RTT로 0ms에 처리된다.

서버클라이언트서버클라이언트초기 연결 (1-RTT)재연결 (0-RTT)클라이언트 Hello + 전송 파라미터서버 Hello + 인증서 + 전송 파라미터데이터 전송 시작세션 재개 + 데이터 (즉시 전송)

패킷 손실이 모든 요청을 멈추지 않게 하는 방식

Head-of-Line(HoL) 블로킹은 네트워크 큐의 첫 패킷이 지연될 때 뒤의 패킷까지 함께 지연되는 현상이다.

TCP 기반 HTTP 2.0도 하나의 연결에서 여러 스트림을 다중화하지만, 패킷이 손실되면 모든 스트림이 영향을 받는다. QUIC 기반 HTTP 3.0에서는 스트림을 독립적으로 처리하므로 한 스트림의 패킷 손실이 다른 스트림으로 번지지 않는다.

HTTP/3 (QUIC 기반)해당 스트림만 영향정상 진행정상 진행스트림 A의 패킷 손실스트림 A 지연스트림 B스트림 B 계속스트림 C스트림 C 계속HTTP/2 (TCP 기반)모든 스트림 차단모든 스트림 차단모든 스트림 차단패킷 1 손실스트림 A 지연스트림 B 지연스트림 C 지연

TLS 1.3을 통합한 보안 처리

HTTP 3.0은 설계 단계부터 보안을 핵심 요소로 삼는다. TLS 1.3을 최신 암호화 프로토콜로 통합하며, 모든 패킷의 헤더와 페이로드에 인증과 암호화를 적용해 패킷 변조를 막는다.

AEAD(Authenticated Encryption with Associated Data) 알고리즘으로는 AES-GCM(Galois/Counter Mode)과 ChaCha20-Poly1305를 사용한다.

IP가 바뀌어도 이어지는 연결

모바일 기기가 Wi-Fi에서 셀룰러 네트워크로 넘어가면 TCP 연결은 끊어진다. QUIC은 Connection ID를 통해 연결 연속성을 유지할 수 있다.

Wi-Fi: IP1전환동일 Connection ID 유지모바일 기기서버셀룰러: IP2

클라이언트에서 네트워크 전환이 발생하면 새 IP 주소에서도 같은 Connection ID로 패킷을 전송한다. 서버는 연결을 유지한 채 응답할 수 있다.

포트와 스트림 제어 방식

HTTP 3.0의 표준 포트는 HTTPS와 같은 443이다. 다만 QUIC은 UDP를 사용하므로 TCP 443 포트와 구분된다.

스트림은 양방향과 단방향으로 나뉜다. 양방향 스트림은 클라이언트와 서버 모두 시작할 수 있고, 단방향 스트림은 시작한 엔드포인트만 데이터를 보낸다. 각 스트림에는 독립적인 흐름 제어가 적용된다.

브라우저와 서버의 지원 범위

Chrome은 버전 85부터 기본 지원하며, Firefox는 버전 88부터 기본 지원한다. Safari는 iOS 14와 macOS Big Sur부터 지원하고, Edge는 Chromium 기반 전환 후 지원한다.

CDN과 서버 측에서도 지원이 이어졌다. Cloudflare는 조기 채택자로 광범위하게 지원하며, Fastly는 HTTP/3와 QUIC을 지원한다. Akamai은 점진적으로 도입 중이고, Nginx는 실험적 모듈로 지원을 시작했다. LiteSpeed는 초기부터 완전한 지원을 제공한다.

운영 환경에서 함께 확인할 조건

HTTP/3는 모바일 환경에서 특히 성능 개선 효과를 낼 수 있으며, 네트워크 조건이 불안정한 환경에서는 신뢰성을 높이고 페이지 로드 시간을 줄일 수 있다.

반면 일부 기업 네트워크는 UDP 트래픽을 차단할 수 있다. 방화벽과 로드 밸런서 같은 미들박스도 QUIC 처리에 제약을 가질 수 있으며, 서버 측 구현 복잡성도 증가한다.

도입할 때는 HTTP/2와 HTTP/3를 병행 지원하는 방식이 가능하다. Alt-Svc 헤더로 클라이언트에 HTTP/3 가용성을 알리고, 실제 환경에서의 개선 효과를 성능 모니터링으로 측정해야 한다.

Facebook과 Cloudflare의 적용 사례

Facebook은 모바일 앱에서 HTTP/3를 도입해 평균 페이지 로드 시간을 15% 줄였다. 네트워크 상태가 좋지 않은 지역에서는 최대 30%의 성능 향상이 있었고, 연결 설정 시간은 75% 감소했다.

Cloudflare는 전 세계 CDN 네트워크에 HTTP/3를 배포했다. 고객사 웹사이트의 TTFB(Time To First Byte)는 평균 12% 개선됐으며, 네트워크 전환 시 연결 유지율은 20% 향상됐다.

UDP 기반 전송으로 넓어지는 웹의 선택지

HTTP/3의 변화는 단순한 프로토콜 버전 교체가 아니다. 웹의 기본 전송 계층을 TCP에서 UDP 기반으로 옮기는 패러다임 변화다.

앞으로는 QUIC 프로토콜의 진화와 표준화 완성, 서버 푸시 기능의 개선과 최적화, 에지 컴퓨팅 환경과의 통합, IoT 기기처럼 제약된 환경에서의 적용이 이어질 수 있다. HTTP/3는 5G 네트워크, 증가하는 모바일 트래픽, 실시간 웹 애플리케이션 확산에 대응하는 기술적 진보다.

HTTP 3.0QUIC웹 프로토콜UDP웹 성능