[Daily morning study] QUIC 프로토콜 개념과 특징
#daily morning study
QUIC이란
QUIC(Quick UDP Internet Connections)은 구글이 2012년에 제안하고, 이후 IETF가 표준화(RFC 9000, 2021)한 새로운 전송 계층 프로토콜이다. UDP 위에서 동작하면서 TCP의 신뢰성과 TLS의 보안을 통합적으로 제공한다. HTTP/3의 기반 프로토콜이기도 하다.
기존 TCP + TLS의 문제점을 해결하기 위해 설계되었으며, 특히 모바일 환경과 불안정한 네트워크에서 성능을 크게 향상시킨다.
TCP + TLS의 한계
연결 수립 비용
TCP는 연결을 맺는 데 1-RTT(Round-Trip Time), TLS 1.3은 추가로 1-RTT가 필요하다. 새로운 연결을 맺을 때마다 최소 2-RTT의 지연이 발생한다.
TCP 3-way handshake: 1-RTT
TLS 1.3 handshake: 1-RTT
─────────────────────────────
첫 요청 가능: 2-RTT 이후
Head-of-Line Blocking (HOL)
TCP는 스트림이 하나뿐이다. 패킷 하나가 손실되면 그 뒤에 오는 모든 데이터가 재전송을 기다린다. HTTP/2에서 멀티플렉싱을 도입했지만, TCP 레벨에서는 여전히 단일 스트림이라 패킷 손실 시 모든 HTTP 스트림이 블로킹된다.
연결 마이그레이션 불가
TCP 연결은 4-tuple(소스 IP, 소스 포트, 목적지 IP, 목적지 포트)로 식별된다. Wi-Fi에서 LTE로 전환되면 소스 IP가 바뀌므로 연결이 끊기고 재연결해야 한다.
QUIC의 핵심 특징
1. 0-RTT / 1-RTT 연결 수립
QUIC은 TLS 1.3을 프로토콜 내부에 통합한다. 처음 연결 시에는 1-RTT, 이미 통신한 서버에 재연결할 때는 0-RTT로 데이터를 바로 전송할 수 있다.
최초 연결:
Client → Server: QUIC Initial (TLS ClientHello 포함)
Server → Client: QUIC Handshake (TLS ServerHello + 인증서)
Client → Server: 완료 + 첫 데이터
─────────────────────────────────────────────────────
데이터 가능 시점: 1-RTT
재연결 (0-RTT):
Client → Server: 이전 세션 키로 암호화된 데이터 바로 전송
─────────────────────────────────────────────────────
데이터 가능 시점: 0-RTT (서버 응답 전에 전송)
0-RTT는 replay attack 위험이 있어 멱등성(idempotent) 요청에만 사용하도록 설계한다.
2. 스트림 레벨 멀티플렉싱
QUIC은 단일 연결 안에서 독립적인 여러 스트림을 운영한다. 각 스트림은 독립적으로 흐름 제어되므로, 한 스트림에서 패킷 손실이 발생해도 다른 스트림은 영향받지 않는다.
TCP + HTTP/2: QUIC + HTTP/3:
┌───────────────────┐ ┌───────────────────────────┐
│ 단일 TCP 스트림 │ │ Stream 1 Stream 2 Stream 3│
│ Stream 1 │ │ ↓ ↓ ↓ │
│ Stream 2 │ │ 패킷 손실이 해당 스트림만 │
│ Stream 3 │ │ 영향, 나머지는 정상 진행 │
│ ← 패킷 손실 시 │ └───────────────────────────┘
│ 전체 블로킹 │
└───────────────────┘
3. 연결 ID 기반 식별
TCP는 IP/포트로 연결을 식별하지만, QUIC은 Connection ID라는 별도의 식별자를 사용한다.
- Wi-Fi → LTE 전환 시 IP가 바뀌어도 Connection ID가 유지되면 연결을 끊지 않고 이어갈 수 있다.
- 이를 Connection Migration(연결 마이그레이션)이라 한다.
Wi-Fi (IP: 192.168.1.10) ──┐
├── Connection ID: 0xABCD1234 ──→ 서버
LTE (IP: 10.0.0.5) ──┘
4. 기본 암호화
QUIC은 모든 패킷을 TLS 1.3으로 암호화한다. 헤더 일부만 평문이고 나머지는 모두 암호화된다. TCP처럼 미들웨어(공유기, 방화벽)가 패킷 내부를 들여다보거나 수정하기 어렵다. 이는 프로토콜 진화를 쉽게 만드는 부수 효과도 있다.
5. 향상된 손실 복구
QUIC은 독자적인 패킷 번호 체계를 사용한다. TCP는 재전송 패킷과 신규 패킷이 같은 시퀀스 번호를 공유하여 RTT 추정이 어렵지만(재전송 모호성), QUIC은 재전송 시에도 새로운 패킷 번호를 부여하므로 RTT 계산이 정확하다.
QUIC 패킷 구조
QUIC 패킷은 크게 두 종류로 나뉜다.
| 종류 | 설명 |
|---|---|
| Long Header Packet | 연결 수립 단계 (Initial, Handshake, 0-RTT) |
| Short Header Packet | 연결 수립 후 데이터 전송 단계 (1-RTT) |
Short Header Packet의 구조:
┌─────────────────────────────────────────────┐
│ Header Form (1bit) │ Fixed Bit │ Key Phase │
│ Packet Number Length │ ... │ │
├─────────────────────────────────────────────┤
│ Destination Connection ID │
├─────────────────────────────────────────────┤
│ Packet Number │
├─────────────────────────────────────────────┤
│ Payload (암호화됨, AEAD) │
└─────────────────────────────────────────────┘
QUIC vs TCP 비교
| 항목 | TCP | QUIC |
|---|---|---|
| 기반 프로토콜 | 자체 전송 계층 | UDP |
| 연결 수립 지연 | 2-RTT (TCP+TLS) | 1-RTT / 0-RTT |
| 멀티플렉싱 | 단일 스트림 | 다중 독립 스트림 |
| HOL Blocking | 있음 (전송 레벨) | 없음 |
| 암호화 | 선택 (TLS 별도) | 기본 (통합 TLS 1.3) |
| 연결 마이그레이션 | 불가 | Connection ID로 가능 |
| 구현 위치 | 커널 | 유저 스페이스 가능 |
| OS 업그레이드 필요 | 필요 | 불필요 (라이브러리) |
UDP 기반이지만 신뢰성 보장
QUIC이 UDP 위에 구현됐다고 해서 신뢰성이 없는 게 아니다. QUIC 자체가 신뢰성 메커니즘을 구현한다.
- 패킷 재전송: 손실된 패킷을 감지하고 재전송
- 흐름 제어: 스트림 단위, 연결 단위 두 레벨의 흐름 제어
- 혼잡 제어: TCP와 유사한 혼잡 제어 알고리즘 (New Reno, CUBIC 등 선택 가능)
- 순서 보장: 스트림 내에서 데이터 순서 보장
UDP를 선택한 이유는 커널 우회가 가능하고, 유저 스페이스에서 빠르게 개선·배포할 수 있기 때문이다.
실제 활용 현황
- HTTP/3: QUIC을 전송 계층으로 사용. 2022년 RFC 9114로 표준화
- Google 서비스: YouTube, Gmail, Google Search 등에서 적극 사용
- CDN: Cloudflare, Fastly 등이 QUIC을 지원
- 브라우저: Chrome, Firefox, Edge, Safari 모두 지원
# curl로 HTTP/3 요청 테스트 (curl 7.66+ 필요)
curl --http3 https://www.cloudflare.com
# 실제 사용 프로토콜 확인
curl -v --http3 https://www.google.com 2>&1 | grep "< HTTP"
정리
QUIC은 TCP의 구조적 한계를 해결하기 위해 UDP 위에 새로 설계된 전송 프로토콜이다.
- 연결 수립 비용을 0-RTT/1-RTT로 줄임
- 스트림 레벨 멀티플렉싱으로 HOL Blocking 제거
- Connection ID로 모바일 환경에서도 연결 유지
- TLS 1.3 통합으로 기본 암호화 보장
- 유저 스페이스 구현으로 빠른 프로토콜 진화 가능
현재 전체 웹 트래픽의 상당 부분이 이미 QUIC/HTTP/3로 전송되고 있으며, 특히 모바일이나 불안정한 네트워크 환경에서 TCP 대비 눈에 띄는 성능 향상을 보여준다.
