HTTP/3 & QUIC: TCP를 버리고 UDP로 간 이유

브라우저가 index.html, style.css, app.js, logo.png 를 요청

HTTP/1.1 (파이프라이닝 이론):
  요청1 ──→ ──→ 응답1 ──→
  요청2 ──→ ──→ (응답1 끝나야 응답2 시작) ──→ 응답2
  요청3 ──→ ──→ (응답2 끝나야 응답3 시작) ──→ 응답3

→ 앞의 응답이 느리면 뒤가 모두 대기 (Application-level HOL Blocking)
→ 실무에서는 파이프라이닝 비활성화, 연결 6개를 동시에 열어서 회피 (비효율)

HTTP/2:
  ┌── TCP 연결 1개 ──────────────────────┐
  │  Stream 1: [Header] [Data] [Data]    │
  │  Stream 2: [Header] [Data]           │
  │  Stream 3: [Header] [Data] [Data]    │
  └──────────────────────────────────────┘
  → 요청/응답이 순서 상관없이 섞여서 전달됨 (빠름!)

TCP 패킷 순서: [1] [2-LOST] [3] [4] [5]

TCP의 규칙: "2번이 올 때까지 3, 4, 5번을 앱에 전달하지 않음"
→ Stream 1의 패킷(3번)도, Stream 3의 패킷(5번)도 모두 대기
→ 서로 관계없는 스트림끼리 간섭 = TCP-level HOL Blocking

HTTP/2 스택                HTTP/3 스택
┌─────────────┐           ┌─────────────┐
│  HTTP/2     │           │  HTTP/3     │
├─────────────┤           ├─────────────┤
│  TLS 1.2/3  │           │             │
├─────────────┤           │  QUIC       │ ← 신뢰성 + TLS 1.3 통합
│  TCP        │           │  (User-space)│
├─────────────┤           ├─────────────┤
│  IP         │           │  UDP        │
└─────────────┘           ├─────────────┤
                          │  IP         │
                          └─────────────┘

QUIC의 스트림 독립성:

  ┌── QUIC 연결 1개 ───────────────────────┐
  │                                         │
  │  Stream 1: [Pkt A] [Pkt B-LOST] [Pkt C]│ ← B 재전송 대기
  │  Stream 2: [Pkt D] [Pkt E]             │ ← 영향 없음! 즉시 전달
  │  Stream 3: [Pkt F] [Pkt G] [Pkt H]     │ ← 영향 없음! 즉시 전달
  │                                         │
  └─────────────────────────────────────────┘

TCP + TLS 1.3 (최소 2-RTT):
  Client                    Server
    │── SYN ──────────────→│   }
    │←─ SYN-ACK ───────────│   } TCP 핸드셰이크: 1 RTT
    │── ACK ──────────────→│   }
    │── ClientHello ──────→│   }
    │←─ ServerHello ───────│   } TLS 핸드셰이크: 1 RTT
    │── Finished ─────────→│   }
    │── HTTP Request ─────→│   ← 드디어 데이터!
    │←─ HTTP Response ─────│
    총: 2 RTT 후 데이터 전송 시작

QUIC 첫 연결 (1-RTT):
  Client                    Server
    │── Initial ──────────→│   } QUIC + TLS 핸드셰이크 통합
    │←─ Initial + Handshake│   } 1 RTT
    │── Handshake + Data ─→│   ← 1 RTT 만에 데이터!
    총: 1 RTT 후 데이터 전송 시작

QUIC 재연결 (0-RTT):
  Client                    Server
    │── Initial + Data ───→│   ← 첫 패킷부터 데이터! (캐시된 키 사용)
    │←─ Handshake + Data ──│
    총: 0 RTT로 데이터 전송 시작

TCP 연결 식별자: (클라이언트 IP, 클라이언트 Port, 서버 IP, 서버 Port)

WiFi:  (192.168.0.10 : 54321, 1.2.3.4 : 443) ← 연결 A
  ↓ WiFi → LTE 전환
LTE:   (10.0.0.5 : 38912, 1.2.3.4 : 443)     ← 새 연결 (IP+Port 모두 변경)
→ 연결 A는 사라짐 → 재접속 필요 → 버퍼링/끊김

QUIC 연결 식별자: Connection ID (64비트 랜덤 값)

WiFi:  IP=192.168.0.10, Connection ID = 0xA1B2C3D4
  ↓ WiFi → LTE 전환
LTE:   IP=10.0.0.5, Connection ID = 0xA1B2C3D4
→ IP가 바뀌어도 Connection ID가 같으므로 동일 세션 유지
→ 추가 핸드셰이크 없이 바로 데이터 이어보냄

TCP 연결이 먼저 수립됨 (평문) → 그 위에 TLS 핸드셰이크 → 암호화 시작
→ 초기 패킷(TCP 핸드셰이크)은 암호화되지 않음
→ 관찰자가 연결 수립 과정을 볼 수 있음

첫 패킷(Initial)부터 TLS 1.3 핸드셰이크가 포함됨
→ 핸드셰이크 이후 모든 페이로드 + 대부분의 헤더가 암호화됨
→ 미들박스(방화벽, ISP)가 내부를 들여다볼 수 없음
→ 프로토콜 경직화(Ossification) 방지

공격자가 0-RTT 패킷을 복사하여 서버에 재전송

정상 클라이언트:
  [0-RTT: POST /transfer?amount=1000&to=attacker]  ──→ 서버 (처리)

공격자 (패킷 가로채기):
  [0-RTT: POST /transfer?amount=1000&to=attacker]  ──→ 서버 (또 처리?!)

✅ 0-RTT에 허용해도 안전한 요청:
  - GET /api/products (조회, 멱등)
  - GET /api/user/profile (읽기 전용)
  - HEAD, OPTIONS

❌ 0-RTT에 허용하면 안 되는 요청:
  - POST /api/transfer (송금)
  - PUT /api/orders/{id}/confirm (상태 변경)
  - DELETE /api/users/{id} (삭제)

# Nginx에서 0-RTT 활성화 시
ssl_early_data on;

# 프록시에 0-RTT 여부를 전달
proxy_set_header Early-Data $ssl_early_data;

// 애플리케이션에서 0-RTT 요청 검증
@PostMapping("/api/transfer")
public ResponseEntity<?> transfer(
        @RequestHeader(value = "Early-Data", required = false) String earlyData,
        @RequestBody TransferRequest request) {

    if ("1".equals(earlyData)) {
        // 0-RTT 요청은 비멱등 작업에서 거부
        return ResponseEntity.status(HttpStatus.TOO_EARLY) // 425
            .body("0-RTT 요청으로는 송금을 처리할 수 없습니다.");
    }
    return ResponseEntity.ok(transferService.execute(request));
}

server {
    # HTTP/3 (QUIC)
    listen 443 quic reuseport;

    # HTTP/2 (기존 호환)
    listen 443 ssl;

    http2 on;
    http3 on;

    ssl_certificate /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    # 0-RTT 활성화 (주의: 비멱등 요청 방어 필요)
    ssl_early_data on;

    # Alt-Svc 헤더로 HTTP/3 지원을 브라우저에 알림
    add_header Alt-Svc 'h3=":443"; ma=86400';

    # QUIC 전용 설정
    quic_retry on;  # Address Validation (DDoS 방어)

    location / {
        proxy_pass http://backend;
        proxy_set_header Early-Data $ssl_early_data;
    }
}

[첫 번째 요청] HTTP/2 over TCP
  Client ──→ Server
  Server ──→ Client: Alt-Svc: h3=":443"; ma=86400

[두 번째 요청~] HTTP/3 over QUIC
  Client ──→ Server (QUIC)

Phase 1: CDN에서 HTTP/3 활성화
  └─ 가장 안전. Cloudflare/CloudFront 설정만 바꾸면 됨.
  └─ 정적 콘텐츠(이미지, JS, CSS)에서 효과 확인

Phase 2: 리버스 프록시(Nginx/Caddy)에서 HTTP/3 활성화
  └─ Alt-Svc 헤더 추가
  └─ 백엔드 서버는 여전히 HTTP/2 또는 HTTP/1.1 (변경 없음)
  └─ QUIC은 프록시 ↔ 클라이언트 구간에만 적용

Phase 3: 모니터링 및 튜닝
  └─ QUIC 연결 비율 모니터링
  └─ UDP 방화벽 규칙 확인
  └─ 0-RTT 비율 및 실패율 관찰

Phase 4: API 서버에 직접 적용 (필요 시)
  └─ gRPC over QUIC 등 고려
  └─ 0-RTT 비멱등 요청 방어 구현

문제: 기업 네트워크에서 UDP 443 차단
  → QUIC 연결 실패
  → 브라우저가 자동으로 TCP(HTTP/2)로 폴백
  → 사용자는 모름, 하지만 HTTP/3 혜택을 받지 못함

# UDP 443이 열려있는지 확인
nc -zuv example.com 443

# curl로 HTTP/3 테스트
curl --http3-only -v https://example.com

# 브라우저에서 확인
# Chrome: chrome://net-internals/#quic
# Firefox: about:networking#quic

1. CPU 사용량: QUIC은 커널이 아닌 유저스페이스에서 동작
   → TCP 대비 CPU 사용량이 높을 수 있음 (특히 고트래픽)
   → GSO/GRO 최적화, io_uring 등으로 개선 중

2. 미들박스 호환성: 일부 네트워크 장비가 UDP를 제한
   → 자동 TCP 폴백으로 대응, 하지만 폴백 지연 발생

3. 디버깅 난이도: 패킷이 암호화되어 tcpdump로 내용을 볼 수 없음
   → qlog (QUIC 전용 로그 포맷) 활용
   → Wireshark QUIC 디코더 사용 (키 로그 필요)

4. 서버 부하: 연결당 상태 관리가 TCP보다 복잡
   → 대규모 서비스에서는 로드밸런서 설정 주의