안동민 개발노트

이전 절에서 HTTP/2가 HTTP 계층의 HOL Blocking을 해결했지만, TCP 계층의 HOL Blocking은 여전히 남아있다는 것을 확인했습니다. HTTP/3는 이 문제를 해결하기 위해 TCP 자체를 버리는 과감한 선택을 합니다.

TCP의 구조적 한계

TCP는 순서 보장을 핵심 특성으로 설계되었습니다. 패킷 3이 유실되면, 패킷 4와 5가 이미 도착해 있어도 애플리케이션에 전달하지 않습니다.

HTTP/2 + TCP의 HOL Blocking

TCP 바이트 스트림 (스트림을 구분하지 못함)

  [...Stream A...][...Stream B...][...Stream C...]
         ↑ 패킷 유실!

  TCP의 관점: "3번 패킷 없으니 4, 5, 6번도 대기"
  Stream A: ■■ 재전송 대기 ■■
  Stream B: ■■ 대기 ■■ ← 자기 데이터는 다 왔는데!
  Stream C: ■■ 대기 ■■ ← 자기 데이터는 다 왔는데!

HTTP/1.1 (TCP 6개 연결)
  연결1: Stream A 패킷 유실 → A만 대기
  연결2: Stream B 정상 → 즉시 처리 ✓
  연결3: Stream C 정상 → 즉시 처리 ✓

패킷 유실률 높은 환경(무선)
  HTTP/2 < HTTP/1.1 (역설!)

QUIC의 해결 방식

QUIC(Quick UDP Internet Connections)은 Google이 설계한 전송 계층 프로토콜로, UDP 위에서 동작합니다.

프로토콜 스택 비교

HTTP/2
┌──────────────┐
│   HTTP/2     │
├──────────────┤
│   TLS 1.3    │
├──────────────┤
│    TCP       │
├──────────────┤
│    IP        │
└──────────────┘

HTTP/3
┌──────────────┐
│   HTTP/3     │
├──────────────┤
│    QUIC      │
│  (TLS 1.3    │
│   내장)      │
├──────────────┤
│    UDP       │
├──────────────┤
│    IP        │
└──────────────┘

QUIC의 독립 스트림
  Stream A 패킷 유실 → A만 재전송 대기
  Stream B 데이터 도착 → 즉시 전달 ✓
  Stream C 데이터 도착 → 즉시 전달 ✓
  → TCP의 HOL Blocking 완전 해결!

UDP를 사용한다고 해서 QUIC이 신뢰성을 포기하는 것은 아닙니다. QUIC은 UDP 위에 자체적인 신뢰성 계층을 구축합니다. 패킷 유실 탐지, 재전송, 혼잡 제어를 모두 QUIC 자체에서 수행합니다. 다만 이 신뢰성이 TCP처럼 전체 연결이 아니라 스트림 단위로 적용됩니다.

연결 수립 속도

연결 수립 비교

TCP + TLS 1.3 (2 RTT)
  Client            Server
    │──── SYN ──────→│
    │←── SYN-ACK ────│     1 RTT (TCP)
    │───── ACK ─────→│
    │── ClientHello →│
    │←─ ServerHello ─│     2 RTT (TLS)
    │── Finished ───→│
    │←─── Data ──────│     총 2 RTT

QUIC (1 RTT):
  Client            Server
    │──── Initial ───→│    TCP + TLS 통합
    │  (ClientHello)  │
    │←── Initial ─────│    1 RTT
    │  (ServerHello)  │
    │─── Data ───────→│    총 1 RTT

QUIC 0-RTT (재연결):
  Client            Server
    │── 0-RTT Data ──→│    0 RTT!
    │  (이전 키 사용) │    첫 패킷부터 데이터 포함
    │←── Data ────────│

연결 마이그레이션

모바일 환경에서 Wi-Fi와 LTE를 전환하면 IP 주소가 바뀝니다.

연결 마이그레이션

TCP (IP 기반 연결 식별)
  Wi-Fi: (192.168.1.5:54321 ↔ 서버:443) ← 연결 ID
  LTE로 전환: IP가 10.0.0.8로 변경
  → 연결 끊김! → TCP 재연결 + TLS 재핸드셰이크
  → 영상 통화 중 끊김!

QUIC (Connection ID 기반)
  Wi-Fi: Connection ID = 0xABCD1234
  LTE로 전환: IP 변경, 하지만 ID는 그대로
  → 연결 유지! → 끊김 없이 계속
  → 영상 통화 끊김 없음!

QUIC은 항상 암호화

TCP는 암호화가 선택사항이지만, QUIC은 암호화가 필수입니다.

프로토콜 경직화(Ossification) 문제

TCP 패킷:
  ┌─── 평문 헤더 ───┐┌─ 페이로드 ──┐
  │ SRC/DST Port    ││             │
  │ Seq/Ack Number  ││   데이터    │
  │ Flags, Window   ││             │
  └─────────────────┘└─────────────┘
        ↑ 중간 장비(방화벽, NAT)가 읽고 조작
        → 새 기능 추가 시 중간 장비가 차단 (ossification)

QUIC 패킷:
  ┌─── 최소 헤더 ───┐┌── 암호화 ──────────┐
  │ Connection ID   ││ 헤더 + 페이로드    │
  │ (일부 평문)     ││ 전체 암호화됨      │
  └─────────────────┘└────────────────────┘
        → 중간 장비가 내용을 볼 수 없음
        → 프로토콜 자유롭게 진화 가능

HTTP/3 도입 현황과 판단 기준

2024년 기준으로 Google, Facebook, Cloudflare 등의 주요 서비스가 HTTP/3를 지원하고, 전체 웹 트래픽의 30% 이상이 HTTP/3로 전송됩니다.

시나리오	추천	이유
모바일 사용자 많음	HTTP/3	연결 마이그레이션, 빠른 연결
고지연/고손실 네트워크	HTTP/3	스트림별 독립 처리
CDN 사용	HTTP/3	Cloudflare/CloudFront 설정만으로 도입
UDP 차단 환경	HTTP/2	기업 방화벽 UDP 차단 시 자동 폴백
레거시 호환 필요	HTTP/2	더 넓은 서버/클라이언트 지원
내부 서비스	HTTP/2	안정적 네트워크에서는 차이 적음

http3_check.sh

# HTTP/3 지원 확인 (curl 7.66+)
curl -I --http3 https://www.google.com 2>&1 | head -3
# HTTP/3 200

# Alt-Svc 헤더로 HTTP/3 지원 확인
curl -sI https://www.cloudflare.com | grep -i alt-svc
# alt-svc: h3=":443"; ma=86400

다음 절에서는 HTTP의 요청-응답 모델을 벗어나 양방향 실시간 통신을 가능하게 하는 WebSocket을 다루겠습니다.

HTTP/3와 QUIC

TCP의 구조적 한계

QUIC의 해결 방식

연결 수립 속도

연결 마이그레이션

QUIC은 항상 암호화

HTTP/3 도입 현황과 판단 기준

목차