⚠️

해당 글의 작성일은 2021년 2월이며 현재의 상황과는 많이 다른 부분이 존재합니다. 현재 HTTP/3 RFC 표준이 확정되었으며 많은 웹 서버와 브라우저에서 HTTP/3를 사용할 수 있는 상태입니다.

나는 웹 신기술을 좋아하는 (자칭)얼리 어탑터이다. HTTP/2가 나올 때는, 개인 홈페이지에 HTTP/2를 적용하고 싶어서 웹 호스팅에서 VPS로 넘어갔다. 그 때부터 Nginx를 쓰기 시작했었다.

근데 이제는 HTTP/3라는게 나온다더라. 그게 무엇인지 알아봤다.

HTTP/3란?

HTTP/3는 HTTP의 3번째 메이저 버전이자, HTTP/2의 차기 버전이다. 그리고 이 글을 쓰는 현재는 draft. 즉 아직 표준안이 확정되지 않았다.

QUIC!

QUIC은 구글에서 개발하기 시작되어 2012년에 공개 된 프로토콜이다. QUIC의 약자는 Quick UDP Internet Connections이지만, 그냥 QUIC라는 이름으로 쓴다. QUIC은 영어 단어 quick으로 발음한다고.

약자에서 알 수 있듯이 기존에 HTTP와는 다르게 UDP를 사용한다는 점이 특징인데, 이 것은 기존 TCP 단점을 개선할 수 있는 중요한 변경이다.

UDP

위에서 QUIC는 UDP를 사용한다고 언급했듯이, UDP를 사용하며 TCP의 단점들을 극복할 수 있다.

이 내용에 대한 내용을 조금 더 상세하게 알고 싶다면, HTTP/3는 왜 UDP를 선택한 것일까? 라는 글을 읽어보는 것을 추천한다.

~~사실은 내가 네트워크를 잘 몰라서 유연하게 설명할 자신이 없다~~

안전하다 ✅

HTTP/2에서는 표준안에는 TLS 요구 사항이 없었지만, 대부분의 클라이언트 (Chromium, Firefox 등)에서 보안 연결을 요구하여 사실상 암호화가 필요했었다.

하지만 HTTP/3, 정확히는 QUIC은 TLS의 가장 메이저 버전인 TLS 1.3을 사용하여 암호화해야만 한다.

Alt-Svc 헤더 🚏

1alt-svc: h3-29=":443"; ma=86400

Alt-Svc 헤더는 클라이언트에게 다른 프로토콜로 이 호스트에 연결할 수 있다고 알리는 역할을 한다. 이는 HTTP Alternative Services라고 불리는 RFC 7838 표준이다.

웹 서버는 이 헤더를 이용하여 클라이언트에게 이 연결은 HTTP/3을 사용할 수 있다고 알린다. 이 Alt-Svc 헤더에는 만료 시간이 있어서 클라이언트가 해당 프로토콜을 사용할 수 있다고 기억하게 돕는다.

따라서 HTTP/3의 첫 연결은 엄연히 따지자면 HTTP/2 이하 버전을 통한다고 볼 수 있다.

HTTP/2와 비슷한 점, 다른 점

비슷한 점

스트림 제공. (구글 Developers의 HTTP/2 소개를 참고하자)

스트림을 통해 하나의 연결로 멀티플랙싱을 함
스트림에 우선순위를 정함

Server Push 지원.

헤더 압축을 제공.

다른 점

HTTP/3는 UDP 기반의 QUIC 프로토콜 적용

TCP + TLS 1.3을 사용하는 이전 버전보다 더 빠른 핸드쉐이크(handshake) 과정

HTTP/3는 표준에 일반 연결이 없음. (무조건 보안 연결을 사용)

소개할 때도 언급했지만, HTTP/2는 이론상으로는 HTTPS 없이 사용이 가능하다.

HTTP/2는 ALPN 확장을 통해 TLS handshake 협상을 완료하지만 HTTP/3는 QUIC을 사용하기 때문에 클라이언트에 먼저 Alt-Svc 헤더를 알려야 함.

draft라면서요. 벌써 프로덕션에 써도 될까요?

내 개인적인 의견이지만, 이 글을 쓰는 지금은 시기상조라고 생각한다.

우선 클라이언트 지원이 없는 것은 아니다.

크롬의 지원을 알아보자. 크로뮴 블로그를 보면 크롬은 2020년 10월에 이미 h3-29 버전의 HTTP/3를 25%의 Stable(안정 버전) 사용자에게 적용했다고 한다. 그리고 글을 읽어보면 TLS v1.3 + TLS(아마 HTTP/2)보다 구글 검색의 레이턴시가 2% 감소하고, 유튜브의 리버퍼(rebuffer)가 9% 감소되었다고 하는 통계도 있다.

실제로 내가 사용중인 크롬을 보면, 구글의 연결을 h3-29를 통해 하고 있는 것을 볼 수 있다.(나는 Stable 버전을 사용한다) 우선 구글도 지원하고 있는 어느 정도 안정된 표준이라는 것은 증명된 것이라고 볼 수 있겠다.

ℹ️

Chrome에만 해당하고 다른 크로뮴 기반 브라우저는 아직 적용되지 않은 것 같다.

하지만, 시기상조라고 생각하게 하는 요소가 너무 많다.

아직 OpenSSL은 QUIC을 지원하지 않는다. 우리가 서비스에 HTTP/3를 적용하기 위해선 구글의 OpenSSL 포크인 BoringSSL을 빌드하여 사용하여야 한다.

많은 리눅스 배포판에서는 BoringSSL 바이너리 패키지를 제공하지 않고 있는데, 빌드를 직접 해야하는 상황이다. 근데 빌드에는 Go가 필요한 것도 단점으로 꼽을 수 있겠다.

지원하는 웹 서버가 적다. 점유율이 제일 큰 Apache는 소식조차 없고, Nginx는 아직 개발 중이다. 상용 웹 서버인 Litespeed에서만 지원하고 있다. IIS는 Microsoft 365에서 테스트 중이라는 정보도 있다.

지원하는 서비스도 적다. 최근에는 정적 파일이 점점 늘어남에 따라 CDN을 사용하는 사이트들이 많은데, 아직 대부분의 CDN 제공자들은 HTTP/3을 지원할 계획이 없어보인다. (Cloudflare는 이미 지원하기 시작했고, Fastly도 베타 테스터를 받고 있다는 글이 있다. 또한 알리바바 클라우드는 Q46 버전을 지원한다는 문서도 있다.)

Nginx의 상황

~~nginx는~~ ~~1.19에서 HTTP/3 (QUIC)을 지원하는 것을 마일스톤으로 열심히 개발 중이다. 실제로 마일스톤이 얼마 남지 않아 보이기도 하고, 조만간 정식적으로 지원될 것으로 보인다.~~

2021년 8월 21일 추가) 마일스톤이 연기되었다. 1.21 버전에서도 아직 in progress인 상태이지만... 언젠간 나오지 않을까.

2023년 9월 2일 추가) quic 개발 브랜치가 머지되어, 1.25.0 버전부터 정식 버전에서도 사용이 가능하다.

nginx-quic

quic.nginx.org

상술한대로 nginx에서 공식적으로 개발 중인 HTTP/3 (QUIC) 대응이다. 개발 중이긴 하지만 h3-29도 지원하고 있는 것을 확인할 수 있다.

Quiche

github.com/cloudflare/quiche

quiche는 Cloudflare사에서 Rust로 구현 중인 QUIC + HTTP/3 구현체이다. nginx 패치는 비공식이긴 하나 docker-nginx-http3에서도 quiche를 사용 중이다.

더 읽어보기

내가 HTTP/3을 좋아하게 만들어 준 글 2개를 가져와봤는데, 글을 작성하는 데에도 참고되었다.

HTTP/3 Explained

HTTP/3는 왜 UDP를 선택한 것일까?