HTTP/3와 QUIC: 손실·연결 전환을 이해하는 법
QUIC은 TCP의 전송 계층 순서 대기를 줄이지만 연결 전체의 혼잡과 흐름 제어는 공유합니다. 0-RTT는 재전송에 안전한 요청에만 선택적으로 쓸 수 있습니다.
발행·오류 제보: infostoa · 편집 기준
이 글의 개별 작성자와 전문 검토자 정보는 제공되지 않습니다.
HTTP/3는 UDP 위에서 동작하는 QUIC을 사용해 HTTP/2와 TCP의 전송 계층 헤드 오브 라인 블로킹을 줄입니다. 다만 손실된 한 스트림의 영향이 다른 스트림으로 전혀 번지지 않는다는 뜻은 아닙니다. QUIC 스트림은 순서 보장을 서로 독립적으로 받지만, 같은 연결의 혼잡 제어와 연결 단위 흐름 제어를 공유합니다. IETF RFC 9000 Cloudflare 엔지니어 Alessandro Ghedini의 QUIC 해설
패킷 손실 때 무엇이 달라지나
HTTP/2는 여러 요청을 한 TCP 연결에 다중화합니다. TCP는 이 데이터를 하나의 순서 있는 바이트 흐름으로 전달하므로 중간 바이트가 빠지면 뒤에 도착한 바이트도 애플리케이션에 넘기기 전에 기다립니다. 한 요청의 패킷 손실이 같은 TCP 연결의 다른 요청 전달까지 지연시킬 수 있습니다.
HTTP/3에서는 각 요청이 QUIC 스트림을 사용합니다. 예를 들어 페이지가 HTML, 이미지, 스타일시트를 동시에 받다가 이미지 스트림의 일부 패킷을 잃으면 그 스트림의 빠진 데이터는 복구를 기다립니다. 이미 도착한 다른 스트림의 연속된 데이터는 그 이미지의 바이트 순서를 기다릴 필요가 없습니다. 이것이 QUIC이 줄이는 전송 계층 HoL 차단입니다. Alessandro Ghedini의 설명도 이 독립성 옆에 연결이 혼잡 상태를 공유한다는 점을 함께 적습니다.
그러므로 “나머지 스트림은 지연 없이 도착한다”는 보장은 아닙니다. 연결 전체의 혼잡 윈도와 연결 단위 흐름 제어가 전송량을 제한할 수 있고, 손실이 심하면 공유된 혼잡 제어가 모든 스트림의 처리 속도에 영향을 줍니다. QUIC의 이점은 한 스트림의 바이트 순서 대기가 다른 스트림을 직접 막지 않는 데 있습니다.
첫 연결의 1-RTT와 재방문의 0-RTT
QUIC은 TLS 1.3을 연결 수립에 통합합니다. 보통 처음 연결하는 클라이언트는 암호화된 애플리케이션 데이터를 주고받기 전에 핸드셰이크 왕복이 필요합니다. 이미 서버와 통신해 재개 정보를 가진 경우에는 서버가 허용하면 첫 전송에 0-RTT 조기 데이터를 실을 수도 있습니다. 이는 모든 연결에서 가능한 기능이 아니며, 서버 설정과 이전 세션 정보에 달려 있습니다.
0-RTT 데이터는 연결 간 재생될 수 있습니다. TLS 1.3은 클라이언트가 재생되어도 안전하다고 판단한 데이터만 조기에 보내도록 요구하고, HTTP/3도 replay 방어를 적용하도록 규정합니다. RFC 8446의 0-RTT 보안 설명 RFC 9114의 Early Data 절
실무 예를 들어 상품 목록을 읽는 요청은 대체로 다시 수행해도 상태 변경이 없도록 설계할 수 있지만, 결제·주문 생성·쿠폰 사용 요청은 중복 실행 시 피해가 생길 수 있습니다. HTTP 메서드 이름만 보고 안전성을 결정하지 마세요. GET이라도 서버가 부수 효과를 일으키도록 잘못 구현됐다면 재생 위험이 있습니다. 0-RTT를 켤지 결정할 때는 해당 애플리케이션 동작의 재생 안전성, 서버의 anti-replay 처리, 거부 시 재시도 동작을 함께 검토합니다.
네트워크가 바뀔 때 연결 ID가 하는 일
QUIC은 IP 주소와 포트의 조합만으로 연결을 식별하지 않도록 Connection ID(CID)를 둡니다. Wi-Fi에서 셀룰러로 바뀌어 경로의 주소가 달라져도, 연결 양쪽이 새 경로를 검증하고 서버가 해당 이동을 허용하면 기존 QUIC 연결을 이어갈 수 있습니다. 따라서 “IP가 바뀌어도 다운로드가 반드시 끊기지 않는다”가 아니라, 이동을 지원하는 연결에서 재연결 비용을 줄일 수 있다고 이해해야 합니다. Cloudflare의 연결 이동 해설
CID는 고정된 64비트나 128비트 숫자가 아닙니다. RFC 9000의 NEW_CONNECTION_ID 프레임은 1~20바이트 길이의 ID를 전달하며, 패킷 형식에는 길이 0인 CID를 쓰는 경우도 정의돼 있습니다. 길이와 값은 연결·구현에 따라 달라질 수 있고, CID가 주소를 대신해 모든 이동을 자동으로 보장하지는 않습니다. 경로 검증, 서버의 상태와 라우팅, 새 네트워크의 UDP 접근성이 여전히 중요합니다.
운영에서 확인할 것
- 같은 웹페이지에서 HTTP/2와 HTTP/3를 비교할 때는 손실률·왕복시간·클라이언트 기기·요청 크기를 함께 기록합니다. 한 환경의 결과를 전체 사용자에게 일반화하지 않습니다.
- UDP 트래픽이 차단되거나 품질이 나쁜 네트워크에서는 HTTP/3 연결이 실패할 수 있습니다. 브라우저와 서버가 지원하는 대체 경로로 다시 연결되는지 실제 환경에서 확인합니다.
- QUIC의 독립 스트림은 같은 연결의 공유 혼잡 제어를 없애지 않습니다. 처리량이나 지연을 설명할 때 “한 스트림의 손실 영향이 완전히 고립된다”라고 쓰지 않습니다.
- 0-RTT는 성능 옵션이면서 보안 선택입니다. 재생 가능 데이터의 피해와 서버의 중복 요청 처리를 설계 검토에 포함합니다.