QUIC과 전송 계층의 진화

TCP는 인터넷의 기반이며 오랫동안 안정적으로 동작해 왔습니다.

하지만 웹이 더 짧은 지연 시간, 더 많은 동시 요청, 모바일 네트워크 전환을 요구하면서 TCP 위에 기능을 계속 덧붙이는 방식의 한계가 드러났습니다.

QUIC은 이 문제를 해결하기 위해 UDP 위에 새 전송 기능을 구현한 프로토콜입니다.

UDP를 쓰지만 단순히 “UDP 위의 TCP”는 아닙니다.

스트림 다중화, TLS 1.3 기반 보안, 손실 복구, 혼잡 제어, 연결 마이그레이션을 하나의 전송 계층으로 통합합니다.

기존 TCP 경로
진화 속도 커널과 중간 장비 영향이 커서 새 기능 배포가 느리다. HOL 하나의 TCP 바이트 스트림 손실이 여러 HTTP/2 스트림을 함께 막을 수 있다. 이동성 IP/Port 4-tuple이 바뀌면 연결 유지가 어렵다.
QUIC 경로
구현 위치 사용자 공간 라이브러리로 빠르게 배포할 수 있다. 스트림 스트림별 손실 복구로 다른 스트림의 대기를 줄인다. Connection ID 경로가 바뀌어도 같은 연결인지 식별할 수 있다.

HTTP 버전별 진화와 한계

QUIC을 이해하려면 HTTP의 진화와 전송 계층의 병목을 구분해야 합니다.

HTTP/1.1은 여러 요청을 효율적으로 병렬 처리하기 어렵고, HTTP/2는 하나의 TCP 연결 안에서 스트림을 다중화했습니다.

그러나 HTTP/2도 TCP 위에 있기 때문에 패킷 손실이 발생하면 TCP의 순서 보장 때문에 여러 HTTP/2 스트림이 함께 막힐 수 있습니다.

HTTP/1.1
TCP 연결 여러 개
keep-alive, pipelining
요청 병렬성
제한적

이 현상을 TCP 수준의 Head-of-Line Blocking이라고 부릅니다.

HTTP/2는 애플리케이션 레벨의 요청 큐 문제를 크게 줄였지만, TCP가 하나의 순서 있는 바이트 스트림이라는 사실은 바꾸지 못했습니다.

1
HTTP/1.1
요청마다 연결을 늘리거나 파이프라이닝 순서 대기를 감수한다.
2
HTTP/2
프레임 멀티플렉싱으로 요청 줄서기는 줄지만 TCP 손실은 연결 전체에 전파된다.
3
HTTP/3
QUIC 스트림 단위 복구로 한 스트림 손실이 다른 스트림을 덜 막는다.
4
개선된 점
브라우저 연결 수 제한과 요청 대기 줄이기에는 HTTP/2가 효과적이다.
5
남은 한계
TCP 순서 보장은 연결 전체 병목이므로 손실률과 RTT를 함께 봐야 한다.

상황	HTTP/2에서 보이는 현상	왜 문제인가
프레임 A2 손실	같은 TCP 연결의 뒤 프레임이 대기	스트림이 달라도 TCP 순서 복구 전까지 애플리케이션에 못 올라간다.
모바일 RTT 증가	작은 손실도 체감 지연으로 확대	재전송 왕복 시간이 길수록 전체 연결이 늦어진다.
HTTP/3 전환	손실 범위가 스트림 단위로 축소	모든 병목을 없애지는 않지만 연결 단위 멈춤은 줄인다.

QUIC의 핵심 구조

QUIC은 UDP 데이터그램 위에서 동작하지만, 애플리케이션이 쓰기 편한 전송 기능을 자체적으로 제공합니다.

RFC 9000은 QUIC을 UDP 기반의 다중화되고 안전한 전송 프로토콜로 정의합니다.

HTTP/3
HTTP semantics를 QUIC stream에 올린다.
QUIC
TLS 1.3, stream, loss recovery, congestion control
UDP
데이터그램 전달. 연결 상태는 QUIC이 관리한다.
IP
경로와 주소 지정

기능	TCP + TLS	QUIC
연결 수립	TCP handshake 뒤 TLS handshake	전송 handshake와 TLS 1.3 handshake 통합
재연결	TCP 연결과 TLS 재협상 필요	조건이 맞으면 0-RTT application data 가능
HOL Blocking	하나의 바이트 스트림 손실이 전체 전달 지연	스트림별 전달, 단 같은 스트림 안 HOL은 존재
암호화 범위	TLS가 TCP payload 보호	QUIC packet 대부분 보호, 일부 헤더는 노출
연결 식별	IP/Port 4-tuple 중심	Connection ID로 경로 변경 대응
구현 위치	주로 커널 TCP 스택	주로 사용자 공간 구현
배포 속도	OS/커널 업데이트 영향 큼	라이브러리·애플리케이션 업데이트 가능
혼잡 제어	커널 TCP 구현	QUIC 구현체가 손실 복구·혼잡 제어 수행

연결 수립 시간 비교

TCP + TLS에서는 먼저 TCP 연결을 만들고, 그 위에서 TLS 핸드셰이크를 진행합니다.

TLS 1.3 기준으로도 일반적으로 새 연결은 TCP 1 RTT와 TLS 1 RTT가 필요합니다.

QUIC은 전송과 암호화 협상을 통합해 새 연결에서 1 RTT로 application data 전송을 시작할 수 있습니다.

1
TCP + TLS 1.3
2
1 RTT
RTT TCP SYN, SYN/ACK
3
1 RTT
RTT TLS 1.3 handshake
4
Data
그 뒤 application data

재방문 또는 재연결 상황에서는 0-RTT가 가능할 수 있습니다.

0-RTT는 이전 연결에서 얻은 정보를 이용해 첫 왕복 전부터 application data를 보낼 수 있는 기능입니다.

하지만 replay attack 위험이 있으므로 멱등 요청처럼 재전송되어도 안전한 요청에 제한적으로 써야 합니다.

GET /catalog 가능 후보 읽기
요청이며 재전송돼도 상태 변경이 없다.
POST /payment 금지 중복 결제처럼 상태 변경
반복될 수 있다.
PUT /profile 정책 필요 멱등 설계
idempotency key가 있어야 검토 가능하다.

RTT가 큰 해외 서버나 모바일 네트워크에서는 이 차이가 체감 성능에 영향을 줄 수 있습니다.

다만 실제 지연 시간은 DNS, TLS 인증서 검증, 서버 처리, 네트워크 손실, UDP 차단 여부까지 함께 영향을 받습니다.

연결 마이그레이션

TCP 연결은 보통 소스 IP, 소스 포트, 목적지 IP, 목적지 포트의 4-tuple로 식별됩니다.

스마트폰이 Wi-Fi에서 LTE로 바뀌면 소스 IP와 경로가 바뀌므로 기존 TCP 연결을 유지하기 어렵습니다.

1. 기존 경로
기존 경로 Wi-Fi에서 Connection ID=8f30 으로 통신한다.
2. 경로 변경
경로 변경 LTE로 전환되어 IP와 포트가 바뀌지만 같은 Connection ID를 보낸다.
3. 검증 후 유지
검증 후 유지 서버는 path validation 뒤 같은 연결로 이어갈 수 있다.

QUIC은 Connection ID를 사용해 연결을 식별할 수 있고, 경로가 바뀌면 path validation을 통해 새 경로를 확인합니다.

이 덕분에 모바일 네트워크 전환에서 기존 연결을 유지할 가능성이 높아집니다.

단, 네트워크 정책, NAT, 방화벽, 서버 구현, path validation 결과에 따라 연결 유지 여부가 달라질 수 있습니다.

HTTP/3와 QUIC의 관계

HTTP/3는 HTTP semantics를 QUIC 전송 위에 올린 버전입니다.

HTTP/3는 HTTP/2의 개념을 이어받지만, TCP가 아니라 QUIC 스트림과 QUIC 연결을 사용합니다.

HTTP semantics GET, POST
status code, headers, cache rules는 계속 HTTP 규칙이다.
HTTP/3 framing 요청
응답을 QUIC stream에 맞는 프레임으로 실어 보낸다.
QUIC transport 스트림별 전송, TLS
1.3, 손실 복구 를 담당한다.
UDP/IP 네트워크 장비에
UDP/443 트래픽으로 보인다.

IETF 표준 기준으로 QUIC 핵심 전송은 RFC 9000(2021년), QUIC-TLS는 RFC 9001(2021년), 손실 복구와 혼잡 제어는 RFC 9002(2021년), HTTP/3는 RFC 9114(2022년)에 정의되어 있습니다.

HTTP/3 지원 확인

# curl이 HTTP/3를 지원하도록 빌드되어 있어야 함
curl -I --http3 https://www.google.com

# Alt-Svc 헤더로 HTTP/3 후보 확인
curl -sI https://www.google.com | grep -i alt-svc

# 예: h3=":443"; ma=2592000
# h3는 HTTP/3 엔드포인트를, ma는 Alt-Svc 유효 시간을 뜻함

QUIC의 현실적 고려사항

QUIC은 지연 시간과 손실 회복, 모바일 이동성에서 장점이 있지만 모든 환경에서 더 빠르다고 단정할 수는 없습니다.

UDP 차단, 관측·디버깅 도구, CPU 비용, 서버/클라이언트 구현 품질, 0-RTT 정책을 함께 고려해야 합니다.

높은 RTT handshake 왕복 절감 0-RTT
replay-safe 요청으로 제한
손실 네트워크 stream 간 HOL
감소 구현체의 손실 복구 품질 확인
기업/학교망 HTTP/3 후보 UDP/443 차단
TCP fallback 필요
저지연 LAN 체감 차
작을 수 있음 CPU와 관측 도구 비용 비교

환경	QUIC 기대 효과	주의점
높은 RTT	handshake RTT 절감 효과가 큼	0-RTT는 replay-safe 요청에 제한
손실이 있는 네트워크	스트림 간 HOL Blocking 감소	손실 복구와 혼잡 제어 구현 품질
모바일 경로 전환	Connection ID 기반 migration 가능	path validation과 정책에 좌우
저지연 LAN	TCP 대비 체감 차이가 작을 수 있음	CPU/구현 오버헤드가 더 보일 수 있음
기업·학교 네트워크	UDP/443 차단 또는 rate limit 가능	TCP fallback 필요
대용량 파일 전송	환경에 따라 TCP가 충분히 효율적일 수 있음	실제 측정으로 판단

멀티캐스트, 브로드캐스트, 애니캐스트

유니캐스트, 브로드캐스트, 멀티캐스트, 애니캐스트는 “누구에게 보내는가”를 나타내는 통신 패턴입니다.

엄밀히는 전송 계층만의 기능이라기보다 IP와 링크 계층 주소 지정, 라우팅, 애플리케이션 설계와 함께 이해해야 합니다.

통신 패턴	수신자	범위	주로 쓰는 맥락	사용 사례
유니캐스트	특정 1개	전역	TCP/UDP	웹, 이메일, 파일 전송
브로드캐스트	같은 네트워크의 모든 장치	주로 LAN	링크 계층/IPv4 일부	ARP, DHCP discovery
멀티캐스트	그룹 가입자	설정에 따라	IP multicast + UDP 등	IPTV, 일부 실시간 배포
애니캐스트	가까운 하나의 인스턴스	전역	BGP 라우팅	DNS, CDN edge

같은 데이터를 여러 수신자에게 보낼 때 멀티캐스트는 네트워크 효율을 높일 수 있습니다.

다만 공용 인터넷에서 임의 멀티캐스트가 널리 제공되는 것은 아니며, 라우팅과 네트워크 장비 지원이 필요합니다.

UDP는 연결 설정이 없고 데이터그램 단위로 보내므로 멀티캐스트·브로드캐스트와 함께 쓰이기 쉽습니다.

TCP는 연결 지향이라 기본적으로 1:1 통신에 맞춰져 있습니다.

전송 계층 면접 총정리

주제	질문	핵심 답변
QUIC	QUIC이 UDP 위에 구현된 이유?	TCP는 커널·중간장비 영향이 커서 진화가 느리고, UDP 위 사용자 공간 구현은 배포가 빠름
QUIC	0-RTT의 보안 위험?	replay attack 가능성이 있어 멱등 요청처럼 재실행 안전한 요청에 제한
QUIC	연결 마이그레이션이란?	Connection ID와 path validation으로 IP/Port 변경 후에도 연결을 이어갈 수 있는 기능
HTTP/3	HTTP/2 대비 장점?	QUIC 기반 스트림, TCP 수준 HOL Blocking 감소, 연결 설정 지연 감소
통신 패턴	유니캐스트/멀티캐스트 차이?	유니캐스트는 1:1, 멀티캐스트는 그룹 수신자에게 네트워크가 복제 전달
애니캐스트	CDN과 DNS에서 활용하는 이유?	같은 IP를 여러 위치에서 광고하고 라우팅이 가까운 인스턴스로 보냄

다음 장에서는 브라우저에 도메인 이름을 입력하면 벌어지는 일, DNS의 세계를 들여다보겠습니다.

이 페이지의 목차