QUIC은 UDP를 타고도 전송 계층 프로토콜이다

QUIC은 UDP 안에서도 전송 계층(transport layer) 기능을 직접 맡습니다. 신뢰성 있는 전달과 순서 보장, 흐름 제어(flow control)를 처리합니다. 혼잡 제어(congestion control)도 맡고, UDP는 포트 번호(port number)를 제공합니다. 저는 UDP라는 바깥 포장보다 QUIC이 실제 맡는 일이 더 오래 남습니다. 둘을 같은 역할로 보면 데이터 복구와 속도 조절의 담당자를 놓치기 쉽습니다.

브라우저에 WebTransport가 들어왔습니다. 하지만 동적 QUIC 스트림(dynamic QUIC stream)을 서버로 넘길 역방향 프록시(reverse proxy)가 부족합니다. 그래서 보급이 제한됩니다. UDP 안에서 QUIC이 실제 전송 기능을 맡는다는 점을 이해하면, 프록시가 단순히 UDP 포트만 전달해서는 충분하지 않은 이유도 보입니다.

새 IP 프로토콜은 라우터나 방화벽에서 막힐 수 있지만, TCP와 UDP는 많은 네트워크에서 허용됩니다. QUIC은 이 익숙한 운반 경로 위에서 UDP 자체가 보장하지 않는 전달과 순서, 속도 조절을 맡습니다.

다만 QUIC에는 IANA 프로토콜 번호가 없고 IP 바로 위에 놓이지 않습니다. 패킷에서의 위치를 기준으로 삼으면 애플리케이션 프로토콜(application protocol)이라는 부름도 나옵니다. QUIC은 신뢰성 있는 전달과 순서·속도 조절을 직접 맡으며, RFC 9000도 전송 프로토콜로 설명합니다. 패킷 경로를 볼 때 UDP만 적혀 있다고 해서 복구와 속도 조절까지 UDP가 한다고 여기면, 실제 담당자를 잘못 짚게 됩니다.

HTTP/3 → QUIC → UDP → IP로 이어지는 네트워크 설명을 하나 찾아보십시오. 각 단계에서 포트 지정과 재전송·순서 보장을 누가 맡는지 표시해 보십시오. UDP라는 이름에 기대 기능의 담당자를 잘못 짚는지 확인할 수 있습니다.

프로토콜의 계층을 확인할 때, 패킷 안에서의 위치와 맡은 기능 중 무엇부터 살펴보십니까?