HTTP/3 시대의 웹 개발: QUIC이 실제로 뭘 바꿨나

인터넷 브라우저 주소창에 `https://`를 입력할 때, 그 연결이 TCP 위에서 돌고 있는지 UDP 위에서 돌고 있는지 알아차리는 사람이 얼마나 될까. HTTP/3는 조용히, 하지만 꽤 근본적인 방식으로 레이어를 바꿨다.

## TLS 위에 앉은 TCP vs. QUIC이라는 새 연결 방식

기존 HTTP/2는 이렇게 생겼다:

```
HTTP/2
  └── TLS 1.3
       └── TCP
            └── IP
```

HTTP/3는 이렇다:

```
HTTP/3
  └── QUIC
       └── TLS 1.3 (내장됨)
            └── UDP
                 └── IP
```

언뜻 비슷해 보이지만 의미가 다르다. QUIC은 TCP를 대체하면서 TLS를 스택 내부로 끌어들였다. 별도 TLS 핸드셰이크가 없고, 연결 설정과 암호화 협상이 동시에 일어난다.

## 핸드셰이크: 1-RTT와 0-RTT

일반적인 HTTP/2 + TLS 1.3 연결은 최소 1번의 왕복(RTT)이 필요하다. 처음 방문하는 서버라면 여기에 DNS 조회, TCP SYN-ACK, TLS 핸드셰이크가 차례로 붙는다.

QUIC은 초기 연결도 1-RTT이지만, 이전에 연결한 적 있는 서버라면 0-RTT 재개가 된다. 캐시된 세션 티켓을 이용해 첫 번째 패킷에 요청을 바로 실어 보낼 수 있다. 단, 0-RTT는 리플레이 공격에 노출될 수 있어서 멱등하지 않은 요청(POST, PUT 등)에는 적합하지 않다는 점은 주의해야 한다.

## Head-of-Line Blocking: 어디서 막히느냐

HTTP/2가 해결하려 했던 문제 중 하나가 HOL(Head-of-Line) 블로킹이었다. HTTP/1.1은 요청을 직렬로 처리했지만, HTTP/2는 멀티플렉싱으로 하나의 TCP 연결 위에서 여러 스트림을 동시에 처리한다.

근데 TCP 레이어에서 패킷 하나가 유실되면? TCP는 그 패킷이 도착할 때까지 이후 데이터를 전달하지 않는다. HTTP/2의 모든 스트림이 하나의 TCP 연결을 공유하기 때문에, 스트림 A에서 발생한 패킷 유실이 스트림 B, C, D까지 막아버린다.

QUIC에서는 각 스트림이 독립적이다. 스트림 A에서 패킷이 유실돼도 스트림 B는 계속 흐른다. 이 차이가 특히 모바일 환경이나 불안정한 네트워크에서 체감된다.

## Connection Migration

QUIC 연결은 IP 주소와 포트가 아니라 **Connection ID**로 식별된다.

지하철을 타면서 Wi-Fi에서 LTE로 전환될 때, TCP라면 그 연결은 끊어진다. 새 TCP 연결을 수립하고 TLS 핸드셰이크를 다시 해야 한다. 이미 진행 중인 파일 다운로드나 스트리밍이 있다면 중단된다.

QUIC은 Connection ID가 유지되는 한 IP 주소가 바뀌어도 연결이 살아있다. 전환 시간 동안 약간의 패킷 유실이 있을 수 있지만, 연결 자체가 끊기지 않는다.

## 실제 지원 현황

2025~2026년 기준 브라우저 지원은 사실상 전부다:
- Chrome/Edge: 91+ (기본 활성화)
- Firefox: 88+
- Safari: 16.4+

서버 쪽은 조금 더 파편화되어 있다. Nginx는 1.25+에서 QUIC을 공식 지원한다. Cloudflare, Akamai, AWS CloudFront는 이미 HTTP/3를 기본으로 제공한다. Apache는 아직 실험적 단계다.

실제로 내 서버가 HTTP/3를 제공하고 있는지 확인하는 가장 쉬운 방법은 Chrome 개발자 도구 → Network 탭 → Protocol 열을 활성화하는 것이다. `h3`가 보인다면 HTTP/3다. `h2`면 HTTP/2.

## 개발자 입장에서 뭐가 달라지나

사실 코드를 직접 수정할 일이 거의 없다. HTTP/3는 전송 레이어 최적화이지 애플리케이션 레이어 변경이 아니다. fetch() API를 쓰든 axios를 쓰든 차이가 없다.

다만 몇 가지는 의식해야 한다:
- 방화벽 설정에서 UDP 443이 막혀 있으면 HTTP/3가 안 된다. 클라이언트는 이 경우 HTTP/2로 폴백한다.
- CDN을 쓴다면 이미 HTTP/3를 쓰고 있을 가능성이 높다.
- Node.js에서 HTTP/3 서버를 직접 구현하려면 `node-quic` 같은 서드파티가 필요하다. 내장 `http` 모듈은 아직 HTTP/3를 지원하지 않는다.

## 체감 성능 차이

HTTP/3가 체감적으로 빠른 경우: 초기 연결이 많고, 네트워크가 불안정하거나, 모바일 사용자 비율이 높은 서비스. SPA(Single Page App)처럼 에셋을 한꺼번에 많이 받아야 할 때도 유리하다.

HTTP/3가 별 차이 없는 경우: 이미 Keep-Alive로 커넥션을 재사용하는 서비스, 안정적인 유선 네트워크 환경, 데이터가 몇 개의 큰 청크인 경우.

기술은 맥락 없이 "무조건 좋다"는 게 없다. HTTP/3도 마찬가지다.

HTTP/3 시대의 웹 개발: QUIC이 실제로 뭘 바꿨나

// COMMENTS

ON THIS PAGE