QUIC vs WebRTC: 왜 QUIC으로 돌아왔나?
WebRTC의 복잡함에 지쳐 QUIC으로 전환한 실전 사례
QUIC은 Google이 설계하고 HTTP/3의 기반이 된 전송 프로토콜입니다. TCP의 3가지 고질적 문제 — 느린 연결 수립(2~3 RTT), Head-of-Line Blocking(패킷 하나 유실 시 전체 대기), IP 변경 시 연결 끊김 — 를 UDP 위에서 해결했습니다. 실제로 원격 데스크톱 프로젝트(ulalaca → Noctiluca)에서 WebRTC를 시도했다가 한계에 부딪힌 사례가 있습니다. WebRTC는 Chromium 소스 수정 필요, 시그널링/STUN/TURN 구성 복잡, 포트 고정 불가, SCTP DataChannel의 HOL Blocking 문제가 있었습니다. QUIC으로 전환하자 UDP 포트 하나만 열면 끝, 스트림 독립성으로 HOL 해결, WiFi AP 전환 시에도 Connection Migration으로 연결 유지 — 이 모든 문제가 즉시 해결되었습니다.
구조 다이어그램
동작 흐름
클라이언트가 서버의 UDP 포트로 Initial 패킷 전송 (TLS 1.3 ClientHello 포함)
서버가 Handshake 패킷으로 응답 — 암호화 협상 + 연결 수립이 1-RTT에 완료
재방문 시 0-RTT: 이전 세션 키로 첫 패킷부터 데이터 전송 가능
독립적 스트림 다중화: 비디오·오디오·입력을 별도 스트림으로 전송, 하나가 유실돼도 나머지 영향 없음
Connection ID 기반 연결 관리: WiFi → LTE 전환 시 IP가 바뀌어도 연결 유지 (Connection Migration)
내장 흐름 제어 + 혼잡 제어로 네트워크 상태에 적응적 전송
장점
- ✓ 0-RTT / 1-RTT 연결 수립 (TCP+TLS 대비 1~2 RTT 절약)
- ✓ Head-of-Line Blocking 완전 해결 (스트림 독립)
- ✓ Connection Migration (IP 바뀌어도 연결 유지)
- ✓ UDP 포트 하나로 모든 통신 (WebRTC처럼 복잡한 인프라 불필요)
- ✓ TLS 1.3 내장 (별도 암호화 레이어 불필요)
단점
- ✗ UDP 기반이라 일부 방화벽/네트워크에서 차단 가능
- ✗ 기존 TCP 미들박스(방화벽, IDS)와 호환성 문제
- ✗ 구현 복잡도 높음 (자체 재전송, 혼잡 제어 구현 필요)
- ✗ WebRTC처럼 미디어 코덱/에코 제거 등은 미내장 (직접 구현)
- ✗ UDP 최적화된 NIC/커널이 아니면 성능 저하 가능