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

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

HTTP/3란?

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

QUIC!

영문 위키백과의 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 헤더 🚏

alt-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 버전을 사용한다) 우선 구글도 지원하고 있는 어느 정도 안정된 표준이라는 것은 증명된 것이라고 볼 수 있겠다.

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

• 아직 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를 선택한 것일까?