QUIC은 왜 UDP 위에서 돌아갈까요?¶

HTTPS면 그냥 TCP 위에서만 더 좋아지면 될 것 같죠? 사실은 웹이 더 빨라지려면, 아래 전달 방식부터 다시 만져야 하는 순간이 있었어요.

TCP vs UDP에서는 TCP는 꼼꼼하고, UDP는 가볍다는 큰 성격 차이를 먼저 봤어요. 그리고 HTTP와 HTTPS에서는 브라우저와 서버가 HTTP로 말하고, HTTPS는 그 대화를 보호된 통로로 감싼다는 흐름도 봤죠. 바로 앞 글인 SNI, ESNI, ECH는 뭐가 다를까요?에서는 TLS의 첫 장면이 어떻게 보이고, 그 안에서 이름이 왜 민감한 힌트가 되는지도 열어봤고요.

근데 여기까지 오면 또 이런 질문이 자연스럽게 남아요.

"좋아요, 근데 왜 요즘은 HTTP/3가 TCP 대신 UDP 위에 올라간다고 하죠? UDP면 원래 허술한 쪽 아니었나요?"

바로 그 빈칸을 채우는 글이에요. 오늘은 QUIC이 왜 UDP를 바닥으로 고른 건지, TLS는 QUIC 안에서 어떤 자리를 차지하는지, 그리고 HTTP/3 장면이 실제로 어떤 흔적으로 보이는지를 같이 읽어볼게요. 큰 뼈대는 RFC 9000, RFC 9001, RFC 9114, 그리고 운영상 caveat를 잘 정리한 RFC 9308 쪽 감각을 바탕으로 볼게요.

일단 비유로 시작해볼게요¶

이번에는 기존 고속도로 규칙을 그대로 쓰기엔 너무 답답해서, 그 위에 전용 급행 운영 규칙을 얹은 셔틀 서비스를 떠올려볼까요?

• 도로 자체는 이미 다 깔려 있어요.
• 근데 그 도로의 오래된 규칙 때문에, 한 차선에서 막히면 뒤쪽 흐름까지 같이 답답해지는 문제가 있어요.
• 그래서 아예 자기만의 연결 방식, 재전송 방식, 흐름 제어 방식을 더 빨리 바꿀 수 있는 셔틀 서비스를 얹는 거예요.

즉 QUIC은 UDP라는 단순한 바닥 위에, 필요한 신뢰성·보안·혼잡 제어·다중 스트림 규칙을 다시 얹은 전송 계층에 더 가까워요.

왜 굳이 UDP 위에서 다시 시작했을까요?¶

처음 들으면 좀 이상해 보여요.

"TCP가 이미 신뢰성도 해주고 순서도 맞춰주는데, 왜 또 새로 만들죠?"

핵심은 기존 TCP 위에서 바꾸기 어려운 것들이 있었기 때문이에요.

1. 운영체제 커널 바깥에서 더 빨리 발전시키고 싶었어요¶

QUIC은 UDP 위에 올라가니까, 구현이 사용자 공간(user space) 에 더 가깝게 올라올 수 있어요. 그러면 브라우저나 서버 소프트웨어가 TCP 스택 전체를 OS가 바꿔주길 기다리지 않고 더 빠르게 진화할 수 있죠.

2. 연결 시작과 보안을 더 가깝게 묶고 싶었어요¶

TCP 위에 TLS를 따로 얹는 구조에서는, 연결 열기와 보안 준비가 분리된 두 단계처럼 느껴져요. QUIC은 여기서 한 발 더 나가, 전송 계층과 TLS 1.3 협상을 더 촘촘히 묶어 시작 지연을 줄이려 했어요.

3. 스트림이 서로 덜 발목 잡게 하고 싶었어요¶

HTTP/2는 TCP 위에서 다중화는 했지만, 바닥 TCP에서 패킷 손실이 나면 한 스트림의 손실이 전체 전달 흐름에 영향을 주는 감각이 남았어요. QUIC은 이 부분을 더 잘게 나눠 스트림 단위 독립성을 더 확보하려고 했죠.

flowchart LR
    A[기존 TCP + TLS] --> B[연결 열기와 보안 준비가 분리됨]
    A --> C[운영체제 TCP 진화 속도 제약]
    A --> D[손실 시 여러 스트림이 같이 답답해짐]
    B --> E[UDP 위 QUIC]
    C --> E
    D --> E

RFC 9308을 초심자 말로 줄이면, QUIC은 그냥 UDP라서 빠르다가 아니라, UDP 위에서 자기가 필요한 전송 규칙을 다시 설계할 수 있어서 유연해졌다 쪽에 더 가까워요.

QUIC은 UDP 위에서 정확히 무엇을 다시 해주나요?¶

여기서 제일 흔한 오해가 나와요.

QUIC은 “UDP에 암호화만 덧씌운 것”이 아니에요.

RFC 9000 기준으로 보면 QUIC은 이런 것들을 스스로 가져가요.

• 연결 식별자
• 패킷 번호
• 신뢰성 있는 전달
• 혼잡 제어
• 흐름 제어
• 다중 스트림
• 연결 마이그레이션 지원

flowchart LR
    A[UDP<br/><small>단순한 datagram 바닥</small>] --> B[QUIC Transport]
    B --> C[패킷 번호]
    B --> D[재전송 / 손실 복구]
    B --> E[혼잡 제어]
    B --> F[스트림 다중화]
    B --> G[연결 식별자]
    B --> H[TLS 1.3 보호]

즉 QUIC은 TCP의 역할 일부를 버리는 게 아니라, 그중 필요한 것들을 자기 방식으로 다시 구현한 쪽에 더 가까워요. 그래서 UDP 위에 있지만, 실제 성격은 가벼운 전송 계층 + 보안 계층이 강하게 묶인 구조라고 보는 편이 맞아요.

TLS는 QUIC에서 어디에 들어갈까요?¶

이 부분이 정말 중요해요. TLS 1.3 핸드셰이크는 실제로 어떤 순서일까요?에서 본 ClientHello, ServerHello, Finished 감각은 여전히 중요해요. 근데 QUIC에서는 그 TLS가 TCP 위의 별도 레코드 계층처럼 들어가지 않아요.

flowchart LR
    A[TCP 위 TLS] --> B[TCP 연결 먼저]
    B --> C[TLS records]
    C --> D[그 안에서 HTTP]

    E[UDP 위 QUIC] --> F[QUIC packet]
    F --> G[안에서 TLS 1.3 handshake 사용]
    G --> H[파생된 키로 QUIC packet 보호]
    H --> I[그 위에 HTTP/3]

RFC 9001을 초심자 말로 줄이면 이래요.

• QUIC은 TLS 1.3을 그대로 버리지 않아요.
• 대신 TLS 1.3을 키 협상과 인증의 엔진처럼 써요.
• 그리고 그 결과로 나온 키를 써서 QUIC 패킷 자체를 보호해요.

즉 QUIC은 "TLS를 안 쓰는 새 프로토콜" 이 아니라, TLS 1.3을 더 깊게 끌어안은 전송 계층에 더 가까워요.

HTTP/3는 QUIC 위에서 어떻게 올라갈까요?¶

HTTP/3는 아예 새로운 웹 의미론을 만든 게 아니에요. 핵심은 HTTP 의미를 QUIC 위에 다시 매핑한 것에 가까워요.

flowchart LR
    A[HTTP 의미론<br/><small>요청 / 응답 / 헤더</small>] --> B[HTTP/3 framing]
    B --> C[QUIC streams]
    C --> D[QUIC packets]
    D --> E[UDP]

그래서 초심자 감각으로는 이렇게 이해하면 좋아요.

• HTTP/1.1: TCP 위에서 비교적 단순한 요청/응답 흐름
• HTTP/2: TCP 위에서 스트림 다중화 강화
• HTTP/3: QUIC 위로 올라가며, 아래 전송 성격 자체가 달라짐

RFC 9114가 말하는 핵심을 사람 말로 줄이면, HTTP/3는 HTTP가 QUIC의 스트림과 보안 모델을 타도록 옮겨 탄 버전이에요.

그럼 진짜 장면에서는 무엇이 다르게 보일까요?¶

이번 글은 structure+scene 이니까, 실제 장면 한 컷도 같이 볼게요. 예를 들어 브라우저 개발자 도구나 curl --http3 -I https://example.com 류의 장면을 보면, 대략 이런 감각의 출력이나 흔적을 만나게 돼요.

$ curl --http3 -I https://example.com
HTTP/3 200
alt-svc: h3=":443"; ma=86400
server: example

또 브라우저 네트워크 화면에서는 Protocol 칼럼이 h3 로 보이거나, 초기 연결에서 UDP 기반 QUIC 연결이 먼저 보이는 식으로 흔적이 남을 수 있어요. 실제 문자열과 세부 출력은 도구와 버전에 따라 다르지만, HTTP/3 / h3 / QUIC / UDP 쪽 힌트가 같이 붙는다는 감각이 중요해요.

이 장면에서 먼저 읽어야 할 신호 네 가지¶

• HTTP/3 또는 h3 표시가 있는지 — 지금 정말 HTTP/3로 올라갔는가?
• alt-svc 가 보이는지 — 서버가 HTTP/3 가능성을 어떻게 알렸는가?
• UDP 기반 연결 흔적이 있는지 — TCP 대신 QUIC 쪽으로 갔는가?
• fallback 흔적이 있는지 — UDP 차단이나 환경 제약으로 다시 HTTP/2/TCP로 내려갔는가?

이 네 가지만 잡아도, "정말 QUIC이 쓰였나?", "시도는 했지만 fallback된 건가?" 같은 질문을 훨씬 덜 헤매고 읽을 수 있어요.

근데 QUIC이 만능은 아니에요¶

여기서 과장을 빼는 게 중요해요.

1. UDP가 막히는 환경이 있어요¶

RFC 9308도 강조하듯, 어떤 네트워크는 UDP를 더 엄격하게 다뤄요. 그러면 QUIC 시도가 막히고, HTTP/2/TCP fallback 이 필요할 수 있어요.

2. 0-RTT는 아무 요청에나 막 쓰면 안 돼요¶

QUIC이 빠르다고 할 때 자주 같이 나오는 게 0-RTT인데, 이건 replay 성질이 있어서 모든 요청에 함부로 쓰는 감각은 위험해요.

3. 스트림 독립성에도 한계는 있어요¶

QUIC은 스트림 사이의 발목 잡힘을 많이 줄였지만, 각 스트림 내부 질서나 혼잡 제어 자체가 사라지는 건 아니에요.

4. QUIC이 UDP 위에 있다고 해서 “UDP처럼 대충 간다”는 뜻은 아니에요¶

오히려 QUIC은 UDP 바닥 위에서 필요한 신뢰성과 제어를 다시 세밀하게 만든 쪽에 더 가까워요.

잘못 읽기 쉬운 함정 다섯 가지¶

하나, QUIC은 그냥 UDP라서 빠르다고 생각하기.
더 정확한 말은, UDP 위에서 자기 전송 규칙을 다시 설계할 수 있어서 유연해졌다는 쪽이에요.

둘, QUIC은 TLS를 버린 새 보안 방식이라고 생각하기.
실제로는 TLS 1.3을 키 협상과 인증 엔진으로 깊게 품고 있어요.

셋, HTTP/3는 HTTP 내용을 완전히 새로 만든 거라고 생각하기.
핵심은 HTTP 의미론을 QUIC 위로 옮겨 탄 것에 더 가까워요.

넷, QUIC이면 무조건 항상 더 빠르다고 생각하기.
환경에 따라 UDP 차단, fallback, middlebox 제약 같은 현실 변수가 있어요.

다섯, 스트림이 분리되면 손실과 순서 문제 자체가 완전히 사라진다고 생각하기.
cross-stream HOL 감각은 줄지만, 모든 전달 제약이 사라지는 건 아니에요.

자, 정리해볼까요?¶

결국 QUIC을 읽는다는 건, "왜 웹이 TCP + TLS 조합만으로는 아쉬워졌는지" 와 "그 아쉬움을 줄이려고 어떤 것들을 UDP 위에 다시 만들었는지" 를 함께 보는 일이에요. 이 감각이 잡히면 HTTP/3 가 단순한 버전 숫자 업이 아니라, 아래 전송 장면 자체가 달라진 결과라는 것도 같이 보이기 시작해요.

이어서 보면 좋은 글¶

• TCP와 UDP의 성격 차이부터 다시 잡고 싶다면 — TCP vs UDP
• HTTP와 HTTPS의 큰 그림부터 다시 보고 싶다면 — HTTP와 HTTPS는 뭐가 다를까요?
• TLS 1.3 핸드셰이크 구조를 먼저 다시 붙이고 싶다면 — TLS 1.3 핸드셰이크는 실제로 어떤 순서일까요?
• ECH와 ClientHello 쪽 민감한 메타데이터 문제를 다시 보고 싶다면 — SNI, ESNI, ECH는 뭐가 다를까요?