HTTP/3와 QUIC

앞 글에서 HTTP/2가 HTTP 수준의 HOL 블로킹을 없앴지만 TCP 위에 있는 한 TCP의 HOL 블로킹은 남는다고 했습니다. HTTP/3(RFC 9114)는 HTTP의 의미를 TCP 대신 QUIC 위에 옮겨 이 문제를 줄였습니다. QUIC이 스트림을 어떻게 다루고 연결을 어떻게 맺는지는 7장 3편에서 보았으므로, 이 글에서는 HTTP/3가 QUIC의 스트림을 어떻게 쓰는지와, 실제로 도입하고 운영할 때 알아야 할 것에 집중합니다.

HTTP/3는 QUIC 스트림 위의 HTTP

HTTP/2는 스트림을 자기가 직접 만들어 TCP의 바이트 스트림 하나에 섞었습니다. HTTP/3는 스트림을 만드는 일을 QUIC에 맡깁니다. QUIC은 연결 안에 서로 독립적인 스트림을 여러 개 열 수 있고, 스트림마다 따로 순서를 맞추고 손실을 복구하므로, HTTP/3는 요청 하나에 QUIC 스트림 하나를 쓰면 됩니다. 그래서 HTTP/3의 프레임에는 HTTP/2처럼 스트림 번호가 없고, 프레임의 종류와 길이만 적힙니다.

QUIC의 스트림 번호는 아래쪽 두 비트로 누가 열었는지와 방향을 나타냅니다(RFC 9000 §2.1).

요청과 응답은 0, 4, 8번처럼 클라이언트가 연 양방향 스트림에 HEADERS와 DATA 프레임으로 실리고, 연결 전체의 설정은 양쪽이 하나씩 여는 단방향 제어 스트림의 SETTINGS 프레임으로 주고받습니다. HTTP/2의 0번 스트림이 하던 일을 별도의 스트림이 맡은 것입니다.

QUIC과 HTTP/3는 스트림 번호나 프레임의 길이 같은 정수를 가변 길이 정수(variable-length integer)로 적습니다. 첫 바이트의 위쪽 두 비트가 전체 길이를 1, 2, 4, 8바이트 가운데 하나로 알려 주고, 나머지 비트가 값입니다(RFC 9000 §16). 다음 코드는 RFC에 실린 예제 값들을 풀어 봅니다.

def decode_varint(data):
    first = data[0]
    length = 1 << (first >> 6)                       # 앞 두 비트가 길이: 1, 2, 4, 8바이트
    value = first & 0x3F                             # 첫 바이트의 나머지 여섯 비트부터 값이다
    for b in data[1:length]:
        value = (value << 8) | b
    return value, length

for hexstr in ["25", "4025", "7bbd", "9d7f3e7d", "c2197c5eff14e88c"]:
    value, length = decode_varint(bytes.fromhex(hexstr))
    print(f"{hexstr:<16} -> {value} ({length}바이트)")

25               -> 37 (1바이트)
4025             -> 37 (2바이트)
7bbd             -> 15293 (2바이트)
9d7f3e7d         -> 494878333 (4바이트)
c2197c5eff14e88c -> 151288809941952652 (8바이트)

작은 값은 1바이트로, 큰 값은 8바이트까지 늘려 적으므로, 대부분이 작은 수인 스트림 번호나 길이를 짧게 담을 수 있습니다. 25와 4025가 모두 37인 것처럼 같은 값을 더 길게 적을 수도 있지만, 보통은 가장 짧은 표현을 씁니다.

HPACK 대신 QPACK

HTTP/2의 HPACK은 연결 하나의 동적 표를 헤더 블록이 도착한 순서대로 고쳐 나갑니다. 이 방식을 QUIC에 그대로 가져오면 문제가 생깁니다. 스트림 4의 헤더 블록이 동적 표에 항목을 더했는데 그 패킷이 사라졌다면, 그 항목을 가리키는 스트림 8의 헤더 블록은 스트림 4의 재전송을 기다려야 합니다. 스트림끼리 막지 않게 하려고 QUIC을 썼는데, 헤더 압축 때문에 다시 서로를 막게 되는 것입니다.

QPACK(RFC 9204)은 동적 표를 고치는 명령을 요청 스트림이 아니라 별도의 단방향 인코더 스트림으로 보냅니다. 각 헤더 블록에는 자기를 풀려면 표에 몇 번째 항목까지 들어와 있어야 하는지가 적혀 있어서, 받는 쪽은 필요한 항목이 아직 오지 않은 블록만 잠시 기다리게 하고 나머지는 바로 풉니다. 보내는 쪽이 받는 쪽이 이미 확인한 항목만 가리키도록 조심하면 기다림을 아예 없앨 수도 있고, 얼마나 많은 스트림이 기다려도 되는지는 SETTINGS로 정합니다. 압축률을 조금 덜 얻는 대신 스트림의 독립성을 지키는 설계입니다.

더 깊이: 기본값으로는 동적 표를 쓰지 않는 QPACK

QPACK의 동작은 받는 쪽이 HTTP/3의 SETTINGS 프레임으로 알리는 두 값이 정합니다. 동적 표의 최대 크기인 SETTINGS_QPACK_MAX_TABLE_CAPACITY와 기다려도 되는 스트림의 수인 SETTINGS_QPACK_BLOCKED_STREAMS입니다. RFC 9204는 두 값의 기본값을 모두 0으로 정하므로, 받는 쪽이 따로 값을 알리지 않은 연결에서는 동적 표 없이 정적 표와 값을 직접 적는 방식만 씁니다. HTTP/2에서 같은 역할을 하는 SETTINGS_HEADER_TABLE_SIZE의 처음 값이 4,096바이트인 것과 다른 점입니다.

막힌 스트림의 한도는 보내는 쪽이 언제나 지켜야 하는 약속이어서, 받는 쪽은 약속한 수보다 많은 스트림이 막히면 이를 QPACK_DECOMPRESSION_FAILED 연결 오류로 처리합니다. 그래서 QPACK의 압축률은 구현의 선택만이 아니라 양쪽이 알린 설정에 따라 달라지며, HTTP/3로 바꾼 뒤 헤더의 크기가 HTTP/2 때보다 크다면 이 설정부터 확인해 볼 수 있습니다. 정적 표의 번호도 HPACK은 1부터, QPACK은 0부터 매긴다는 차이가 있습니다.

서버가 HTTP/3를 알리는 방법

HTTP/3는 UDP를 쓰므로, 브라우저는 처음부터 HTTP/3로 접속해도 되는지 알 수 없습니다. 그래서 서버가 먼저 알려 줍니다. 가장 흔한 방법은 HTTP/1.1이나 HTTP/2 응답에 Alt-Svc: h3=":443"; ma=86400 같은 헤더를 붙여 "UDP 443번에서 HTTP/3도 된다"고 광고하는 것이고, 브라우저는 다음 연결부터 HTTP/3를 시도합니다. DNS의 HTTPS 레코드(RFC 9460)에 alpn="h3"를 적어 두면 첫 연결부터 HTTP/3를 시도할 수 있습니다.

연결을 맺을 때는 QUIC 핸드셰이크 안의 TLS ALPN으로 h3를 협상합니다. UDP가 막힌 망에서는 QUIC이 실패하므로, 브라우저는 7장 3편의 연습 문제에서 본 것처럼 TCP와 QUIC을 함께 시도하거나 실패한 망을 기억해 두는 방식으로 손해를 줄입니다.

0-RTT를 쓸 때

QUIC은 전송과 TLS 1.3의 핸드셰이크를 합쳐, 새 연결에서는 한 번의 왕복 뒤에 요청을 보내고, 예전에 접속한 서버에 다시 연결할 때는 0-RTT로 첫 패킷부터 요청을 실을 수 있습니다. RTT가 80ms라면 새 연결의 첫 요청은 약 80ms 뒤에 나가고, 0-RTT라면 바로 나갑니다. 다만 0-RTT로 보낸 요청도 서버까지 가고 응답이 돌아오는 시간은 그대로 걸리며, 서버가 0-RTT 데이터를 거절하면 핸드셰이크 뒤에 다시 보내야 합니다.

0-RTT의 데이터는 재전송 공격을 막지 못하므로, 같은 요청이 두 번 처리되어도 괜찮은 요청에만 씁니다. 메서드가 GET이라는 것만으로는 판단할 수 없고, 그 요청이 서버에 어떤 효과를 남기는지를 봐야 합니다. 서버는 받아들일 0-RTT 요청을 정해 두고 나머지는 핸드셰이크가 끝날 때까지 미루거나 425 Too Early로 거절합니다.

연결 이동은 경로를 확인한 뒤에 이어진다

QUIC은 연결을 Connection ID로 구별하므로, 스마트폰이 와이파이에서 LTE로 옮겨 주소가 바뀌어도 같은 연결을 이어 갈 수 있습니다. 하지만 새 주소에서 온 패킷을 그대로 믿고 그쪽으로 데이터를 쏟아 보내면, 공격자가 남의 주소를 출발지로 적어 보내는 것만으로 트래픽을 그 주소로 몰아줄 수 있습니다. 그래서 서버는 새 경로로 보내기 전에 그 주소가 정말 응답하는지 확인합니다.

서버는 새 주소로 예측할 수 없는 8바이트 값을 담은 PATH_CHALLENGE 프레임을 보내고, 클라이언트는 받은 값을 그대로 PATH_RESPONSE에 담아 돌려보냅니다(RFC 9000 §8.2). 같은 값이 돌아오면 서버는 그 주소에 정말 클라이언트가 있다는 것을 압니다. 주소를 위조한 공격자는 진짜 주소로 간 PATH_CHALLENGE를 볼 수 없으므로 같은 값을 돌려줄 수 없습니다. 확인이 끝나기 전에도 데이터를 조금은 보낼 수 있지만, 받은 양의 세 배를 넘지 않도록 제한해 반사 공격의 도구가 되지 않게 합니다.

새 경로의 확인이 실패했다고 연결이 끝나는 것은 아닙니다. 예전의 와이파이 경로가 아직 살아 있다면 그 경로를 계속 쓸 수 있습니다. 연결 이동이 실제로 되려면 서버가 이를 허용하고, 서버 앞의 로드 밸런서가 주소가 아닌 Connection ID를 보고 같은 서버로 패킷을 보내야 하며, 새 경로의 NAT와 방화벽이 UDP를 통과시켜야 합니다.

QUIC이 숨기지 못하는 것

QUIC은 TLS 1.3을 전송 프로토콜 안에 넣어, TCP와 TLS를 쓸 때보다 훨씬 많은 부분을 암호화합니다. TCP에서는 순서 번호와 ACK가 그대로 보였지만, QUIC에서는 패킷 번호까지 헤더 보호로 가려지고 ACK 같은 제어 정보도 암호화된 페이로드 안에 들어갑니다. 그래도 모든 것이 숨겨지지는 않습니다. 연결의 첫 Initial 패킷을 보호하는 키는 패킷에 적힌 Connection ID와 공개된 값으로 누구나 만들 수 있으므로(RFC 9001 §5), 그 안의 ClientHello와 SNI는 경로 위에서 읽을 수 있습니다. 바깥에 드러나는 Connection ID와 패킷의 크기, 시각도 남습니다.

도입할 때 따져 볼 것

HTTP/3는 주요 브라우저와 CDN이 이미 지원하지만, 실제로 쓰이는 비율은 측정하는 곳에 따라 다릅니다. 예를 들어 Cloudflare의 2025년 정리에 따르면 Cloudflare 네트워크가 받은 요청 가운데 HTTP/2가 50%, HTTP/1.x가 29%, HTTP/3가 21%였습니다. 웹 전체의 비율이 아니라 한 사업자의 망에서 본 값이라는 점을 기억해야 합니다.

실제로 HTTP/3가 쓰였는지는 다음처럼 확인합니다. --http3는 HTTP/3가 안 되면 이전 버전으로 넘어가므로, 넘어가지 않는 --http3-only나 실제로 쓴 버전을 찍는 %{http_version}으로 확인해야 합니다.

curl -sI https://www.example.com | grep -i '^alt-svc'                            # HTTP/3를 광고하는지
curl -s -o /dev/null -w '%{http_version}\n' --http3-only https://www.example.com    # HTTP/3로만 시도

Alt-Svc는 광고일 뿐이어서, 이 헤더가 있다고 이번 요청이 QUIC으로 오간 것은 아닙니다. 문제가 생기면 협상된 HTTP 버전, UDP가 막혔는지, QUIC 연결과 스트림의 오류를 나누어 기록합니다. QUIC은 패킷의 대부분이 암호화되어 캡처만으로는 손실과 재전송을 보기 어려우므로, 구현이 남기는 qlog와 서버의 기록을 함께 봅니다.

정리

• HTTP/3는 요청 하나에 QUIC의 양방향 스트림 하나를 쓰고, 연결의 설정은 단방향 제어 스트림으로 주고받으므로 프레임에 스트림 번호가 없습니다.
• QUIC과 HTTP/3는 첫 바이트의 위쪽 두 비트로 1, 2, 4, 8바이트의 길이를 정하는 가변 길이 정수를 씁니다.
• QPACK은 동적 표의 갱신을 별도의 인코더 스트림으로 보내, 헤더 압축 때문에 스트림끼리 다시 막히는 일을 줄입니다.
• 서버는 Alt-Svc 헤더나 DNS의 HTTPS 레코드로 HTTP/3를 알리고, 브라우저는 UDP가 막힌 경우에 대비해 TCP로 넘어가는 길을 둡니다.
• 연결 이동은 PATH_CHALLENGE와 PATH_RESPONSE로 새 주소를 확인한 뒤에 이루어지며, 확인이 실패해도 예전 경로가 살아 있으면 연결은 계속됩니다.
• QUIC도 Initial 패킷의 내용과 Connection ID, 크기와 시각은 숨기지 못하며, HTTP/3의 실제 사용은 %{http_version}이나 --http3-only로 확인합니다.

연습 문제

1. 0-RTT로 보내도 되는 요청

중복 적립을 막는 장치가 없는 포인트 적립 요청을 0-RTT로 보내려 합니다. 네트워크가 빠르고 다시 연결할 정보도 있다면 괜찮은 선택인가요?

2. 새 경로의 확인이 실패하면

PATH_CHALLENGE에 대한 응답이 끝내 오지 않았지만, 예전의 와이파이 경로는 이미 확인되어 있고 아직 쓸 수 있습니다. 연결을 끝내고 새로 맺어야 하나요?

3. 가변 길이 정수로 적기

63, 64, 300을 QUIC의 가변 길이 정수로 가장 짧게 적으면 각각 몇 바이트, 어떤 값이 되나요?

다음 글 WebSocket과 실시간 통신에서는 HTTP의 요청과 응답을 벗어나 서버와 클라이언트가 아무 때나 메시지를 주고받는 WebSocket과, HTTP로 실시간을 흉내 내는 방법들을 비교합니다.