HTTP/3(RFC 9114)는 HTTP/2의 남은 약점인 TCP head-of-line blocking을 근본적으로 없애기 위해, 전송 계층을 TCP에서 QUIC으로 통째로 바꾼 프로토콜입니다. HTTP의 의미(메서드·상태 코드)는 그대로지만, 그것을 실어 나르는 밑바닥이 완전히 달라졌습니다.
UDP 위의 QUIC
QUIC(RFC 9000)은 UDP 위에 구현된 신뢰성 전송 프로토콜입니다. UDP를 고른 이유는 라우터·방화벽 등 인터넷 중간 장비들이 이미 UDP를 통과시키므로, 새 전송 프로토콜을 커널·네트워크 전면 교체 없이 사용자 공간(user space)에서 배포할 수 있기 때문입니다. QUIC은 UDP 위에서 스트림 다중화·손실 복구·혼잡 제어·암호화를 스스로 구현합니다. 특히 TLS 1.3이 QUIC에 내장되어, 별도의 TLS 레이어 없이 전송과 암호화가 한 몸으로 동작합니다.
1-RTT와 0-RTT 핸드셰이크
TCP+TLS 조합은 TCP 3-way 핸드셰이크에 이어 TLS 핸드셰이크가 필요해 왕복이 겹쳤습니다. QUIC은 전송과 암호화 핸드셰이크를 하나로 합쳐 첫 접속을 1-RTT에 끝냅니다. 이미 접속한 적 있는 서버라면 이전 세션 정보를 이용해 0-RTT로, 첫 패킷에 곧바로 HTTP 요청을 실어 보낼 수 있습니다.
첫 접속 (1-RTT):
Client --- Initial (ClientHello) ------------> Server
Client <-- Initial+Handshake (ServerHello) --- Server
Client --- Handshake done + HTTP request -----> Server
재접속 (0-RTT):
Client --- Initial + 0-RTT HTTP request ------> Server (첫 왕복에 요청 포함)
0-RTT는 빠르지만 초기 데이터가 재전송 공격(replay)에 노출될 수 있어, 서버는 이를 멱등·안전한 요청(GET 등)에만 허용하도록 처리합니다.
스트림별 손실 복구 — TCP HoL 제거
QUIC의 결정적 이점입니다. QUIC 스트림들은 각자 독립적으로 순서·손실 복구를 관리합니다. 한 스트림의 패킷이 손실돼도 다른 스트림의 데이터는 영향받지 않고 계속 전달됩니다. HTTP/2가 하나의 TCP 스트림 위에 여러 논리 스트림을 얹어 패킷 손실이 전체를 멈추게 했던 것과 대조적으로, QUIC은 손실을 해당 스트림에만 가둡니다. 이로써 전송 계층의 head-of-line blocking이 사라집니다.
연결 마이그레이션
TCP 연결은 출발지 IP:포트 ↔ 목적지 IP:포트 4-튜플로 식별되어, Wi-Fi에서 셀룰러로 바뀌어 IP가 달라지면 연결이 끊깁니다. QUIC은 각 연결에 IP와 무관한 Connection ID를 부여해, 네트워크가 바뀌어도 같은 연결을 이어 갈 수 있습니다(연결 마이그레이션). 모바일에서 이동 중에도 다운로드나 통화가 끊기지 않게 하는 실질적 이점입니다.
QPACK과 Alt-Svc 발견
HTTP/2의 HPACK은 헤더 테이블 갱신이 순서에 의존해, 순서가 보장되지 않는 QUIC 스트림에는 그대로 쓸 수 없었습니다. QPACK(RFC 9204)은 인코더/디코더 스트림을 분리하고 blocking을 제어해 순서 독립 환경에서도 안전하게 헤더를 압축합니다. 한편 클라이언트는 서버가 HTTP/3을 지원하는지 처음엔 알 수 없으므로, 서버가 HTTP/1.1·HTTP/2 응답에 Alt-Svc 헤더로 'HTTP/3도 여기서 쓸 수 있다'고 알립니다.
HTTP/1.1 200 OK
Alt-Svc: h3=":443"; ma=86400
배포 현실
- 광범위한 지원: 주요 브라우저와 대형 CDN·서비스가 이미 HTTP/3을 제공하며, 웹 트래픽의 상당 부분이 HTTP/3으로 흐릅니다.
- UDP 차단 폴백: 일부 기업망·방화벽이 UDP 443을 막으면, 클라이언트는 조용히 HTTP/2(TCP)로 폴백합니다. 그래서 HTTP/3은 HTTP/2를 대체하기보다 함께 제공됩니다.
- 첫 방문 비용:
Alt-Svc로 발견하는 구조상 최초 접속은 보통 HTTP/2로 시작하고, 다음 접속부터 HTTP/3으로 승격됩니다. - CPU 비용: 혼잡 제어·암호화가 사용자 공간에서 돌아 서버 CPU 부담이 커질 수 있어, 대규모 배포에서는 최적화가 중요합니다.