이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- UDP가 TCP와 달리 연결, 순서, 재전송을 기본 제공하지 않는다는 점이 운영에서 어떤 의미를 가지는가?
- DNS, HTTP/3, QUIC, metrics, streaming에서 UDP가 어떻게 쓰이고 어디서 막히는가?
- HTTP/3/QUIC 장애를 앱 라우팅 장애와 구분하려면 어떤 증거를 봐야 하는가?
개요
UDP는 연결 상태를 만들지 않고 datagram을 보낸다. 순서 보장, 재전송, 흐름 제어가 기본으로 없기 때문에 빠르고 단순하지만 신뢰성은 애플리케이션이나 상위 프로토콜이 맡아야 한다. 웹 백엔드에서는 DNS와 HTTP/3/QUIC 때문에 반드시 만난다.
- UDP는 연결 상태를 만들지 않으므로 빠르고 단순하지만 신뢰성은 기본 제공하지 않는다.
- DNS는 대표적인 UDP 사용 사례이고, HTTP/3는 QUIC 위에서 동작한다.
- QUIC은 TLS와 전송 제어를 사용자 공간에서 결합해 연결 설정 지연을 줄인다.
왜 백엔드 개발자가 알아야 하는가
백엔드 개발자가 직접 UDP 서버를 만들지 않더라도 UDP 경로는 운영 품질에 영향을 준다. DNS 질의가 UDP에서 막히거나, HTTP/3가 UDP 443에서 실패하거나, CDN이 h3에서 h2로 fallback하면 사용자 체감과 장애 증상이 달라진다.
- DNS는 보통 UDP 53을 먼저 쓰고, 응답이 크거나 정책상 필요하면 TCP 53도 쓴다.
- HTTP/3는 QUIC 위에서 동작하므로 TCP 443만 열어서는 충분하지 않다.
- 일부 회사망, 이동통신망, 방화벽은 UDP 443을 제한해 HTTP/3만 실패시킬 수 있다.
- QUIC은 connection ID를 사용해 네트워크 전환에 강하지만, 중간 장비 관측 방식은 TCP와 다르다.
- 0-RTT는 지연을 줄일 수 있지만 replay 가능성을 고려해야 한다.
요청 흐름에서의 위치
UDP는 DNS와 HTTP/3에서 요청 경로 앞부분과 전송 계층에 나타난다.
DNS over UDP 53
→ TCP/TLS/HTTP/2 또는 UDP/QUIC/HTTP/3
→ CDN/LB/Gateway
→ backend HTTP/1.1 or HTTP/2 upstream대부분의 백엔드 origin은 여전히 CDN이나 LB 뒤에서 HTTP/1.1 또는 HTTP/2 upstream을 받는다. 사용자는 HTTP/3로 CDN에 접속하지만 CDN에서 origin까지는 다른 protocol일 수 있다.
원리
UDP와 TCP의 차이는 장애 증상에도 반영된다.
| 구분 | TCP | UDP |
|---|---|---|
| 연결 상태 | handshake와 connection state 있음 | 기본 연결 없음 |
| 순서 보장 | 제공 | 제공하지 않음 |
| 재전송 | 제공 | 제공하지 않음 |
| 혼잡 제어 | 제공 | 기본 없음 |
| 대표 웹 사례 | HTTP/1.1, HTTP/2, TLS | DNS, QUIC/HTTP/3 |
QUIC은 UDP 위에서 동작하지만 TCP처럼 신뢰성, 혼잡 제어, stream을 자체 구현한다. TLS 1.3을 통합해 handshake 왕복을 줄이고, 여러 stream을 하나의 connection 안에 두어 TCP 기반 HTTP/2의 head-of-line blocking 문제를 완화한다.
핵심 판단 기준
- HTTP/3를 켰다면 UDP 443이 client, CDN, firewall, security group에서 허용되는지 확인한다.
- h3 장애를 앱 장애로 단정하지 않는다. h3만 실패하고 h2가 정상인 경우 CDN/edge/UDP 경로를 먼저 본다.
- DNS 장애에서는 UDP 53과 TCP 53을 모두 확인한다. TCP fallback이 막히면 큰 DNS 응답이나 DNSSEC 환경에서 실패할 수 있다.
- QUIC은 TCP socket state로 관찰되지 않는다. CDN metric, browser protocol, UDP packet, edge log를 봐야 한다.
- 0-RTT를 허용하는 endpoint는 idempotency와 replay 위험을 고려한다.
실무에서 자주 만나는 문제
- UDP 차단을 DNS 장애로 착각한다.
- HTTP/3 실패를 애플리케이션 라우팅 문제로 본다.
- 방화벽에서 TCP 443만 열고 UDP 443을 잊는다.
- CDN에서 h3를 켰지만 corporate network 사용자는 h2 fallback으로만 접속한다.
- DNS 응답이 커져 TCP fallback이 필요한데 TCP 53이 막혀 일부 조회가 실패한다.
- UDP idle timeout이 짧아 NAT 뒤 모바일 클라이언트에서 연결이 자주 끊긴다.
- QUIC packet이 MTU/path 문제로 손실되어 특정 네트워크에서만 느리다.
- origin 서버 로그만 보고 HTTP/3 사용 여부를 판단하려 한다.
UDP/QUIC 문제는 특정 네트워크에서만 보이는 경우가 많다. 회사 보안망, 이동통신망, 해외 ISP, VPN, 공항/호텔 Wi-Fi처럼 중간 장비 정책이 강한 곳에서 재현되는지 확인해야 한다.
디버깅 방법
dig로 DNS UDP 동작을 확인한다.- 브라우저 DevTools에서 protocol이 h2인지 h3인지 본다.
- UDP 443 허용 여부를 firewall에서 확인한다.
dig +tcp로 DNS TCP fallback을 별도 확인한다.curl --http3가 가능한 환경이면 h3와 h2를 나눠 비교한다.- response header의
alt-svc로 HTTP/3 광고 여부를 본다. - edge/CDN dashboard에서 HTTP version별 error rate와 fallback rate를 본다.
dig example.com A
dig +tcp example.com A
curl -I https://example.com
curl --http2 -I https://example.com
curl --http3 -I https://example.comcurl --http3는 설치된 curl이 HTTP/3를 지원해야 한다. 지원하지 않는다면 브라우저 DevTools의 Protocol column, CDN log, edge analytics를 사용한다.
코드로 확인하기
HTTP/3를 열었다면 응답이 어떤 protocol로 내려오는지 운영 smoke test에 포함할 수 있다.
#!/usr/bin/env bash
set -euo pipefail
URL="${1:-https://example.com}"
echo "== advertised protocols =="
curl -fsSI "$URL" | egrep -i 'alt-svc|server|via|cf-cache-status|x-cache' || true
echo "== h2 path =="
curl --http2 -fsSI "$URL" >/dev/null
echo "== h3 path =="
curl --http3 -fsSI "$URL" >/dev/null이 스크립트는 h3 지원 curl이 있는 환경에서만 동작한다. h3만 실패하면 앱 origin보다 CDN, UDP 443, edge 설정, 방화벽 정책을 먼저 의심한다.
주니어가 자주 하는 오해
- UDP는 신뢰성이 없으니 웹에서는 쓰지 않는다고 생각한다.
- DNS와 HTTP/3가 UDP 경로를 사용한다.
- HTTPS는 항상 TCP 443이라고 생각한다.
- HTTP/3는 UDP 443 위의 QUIC을 쓴다.
- h3가 실패하면 사이트가 실패한 것이라고 생각한다.
- 대부분의 환경에서는 h2/h1 fallback이 있어 h3만 실패할 수 있다.
- QUIC이면 TCP 문제를 모두 해결한다고 생각한다.
- UDP 차단, MTU, NAT idle timeout, CDN 설정 같은 별도 문제가 있다.
시니어의 설계 판단 기준
- HTTP/3는 enable 자체보다 fallback, observability, CDN support, firewall 허용 범위를 함께 설계한다.
- critical API는 h3/h2/h1별 error rate와 latency를 분리해 본다.
- DNS는 UDP 53과 TCP 53을 모두 허용하고, 응답 크기와 DNSSEC 영향을 이해한다.
- 모바일이나 글로벌 서비스는 NAT rebinding과 network switch 시나리오를 테스트한다.
- 0-RTT는 GET처럼 안전한 요청 위주로 제한하고 결제/주문 같은 비멱등 작업에는 신중하게 접근한다.
인프라 협업 포인트
- HTTP/3를 켤 때는 CDN 설정, UDP 443 방화벽, WAF 지원, observability 필드를 함께 확인한다.
- h3 장애 보고에는 사용자 네트워크, browser protocol,
alt-svc, CDN edge region, h2 fallback 성공 여부를 포함한다. - DNS UDP/TCP 문제가 의심되면 resolver, query type, UDP/TCP 각각의 결과를 제공한다.
- 인프라 팀은 UDP 허용이 TCP보다 추적이 어렵고 보안 장비 정책 영향을 더 많이 받는다는 고충이 있다.
실전 팁
- 개인 프로젝트에서 CDN을 쓴다면 HTTP/3를 켜기 전에 h2 fallback이 정상인지 먼저 본다.
- UDP는 packet loss가 있어도 TCP처럼 같은 방식으로 보이지 않는다. 사용자 지역별 p95/p99를 분리한다.
- h3 rollout은 전체 적용보다 일부 도메인이나 CDN rule로 시작해 metric을 본다.
- QUIC 문제를 origin app log에서만 찾으면 놓친다. edge log와 browser protocol이 더 직접적일 때가 많다.
위험 신호!
- HTTP/3를 켰지만 h3/h2/h1별 error rate를 모른다.
- firewall 변경에서 TCP 443만 열고 UDP 443을 확인하지 않았다.
- DNS TCP fallback이 막혀 있는지 아무도 모른다.
- 특정 네트워크에서만 느린데 edge region/protocol별 분석이 없다.
- 0-RTT 허용 여부를 보안/백엔드 팀이 모른다.
확인 질문
확인 질문
- HTTP/3가 TCP 443만으로 동작하지 않는 이유는 무엇인가?
- HTTP/3는 QUIC 위에서 동작하고 QUIC은 UDP를 사용하므로 UDP 443 경로가 필요하기 때문이다.
- h3만 실패하고 h2는 정상이라면 무엇을 먼저 의심해야 하는가?
- 앱 라우팅보다 CDN/edge 설정, UDP 443 firewall, 사용자 네트워크의 UDP 제한, h3 fallback 상태를 먼저 본다.
- DNS에서 UDP와 TCP를 모두 확인해야 하는 이유는 무엇인가?
- DNS는 보통 UDP를 먼저 쓰지만 큰 응답, DNSSEC, 정책 상황에서는 TCP fallback이 필요할 수 있기 때문이다.