NGINX HTTP/3 및 QUIC에 대한 기술 지원

NGINX HTTP/3 및 QUIC 기술 미리보기를 특별한 오픈소스 리포지토리에서 발표하게 되어 기쁩니다.
이것은 IETF QUIC 초안을 기반으로 한 사전 릴리스 소프트웨어로, Stable 및 Mainline 브랜치와는 격리된 개발 branches에서 유지되고 있습니다.
이 릴리스는 초기 개발을 몇 개월 동안 거쳐 이루어진 결과물로, 상호 운용성 테스트, 피드백 및 코드 기여를 위해 준비가 완료되었습니다.

목차

1. HTTP/3 이해
 1-1. HTTP/3를 사용하는 이유
2. NGINX HTTP/3 + QUIC 미리보기

1. HTTP/3 이해

빠르게 변화하는 세상에서, Hypertext Transfer Protocol (HTTP)는 20년 이상이라는 오랜 기간 동안 매우 안정된 상수로 남아 있었습니다. HTTP/1.1 표준은 1999년에 발표되어 웹 애플리케이션과 API의 보편적인 전송 프로토콜로 사용되어 왔습니다. 애플리케이션과 서비스의 엄청난 변화에도 불구하고 향후 21년 동안 계속 사용되어 왔습니다.

이 시점에서 해당 글을 읽는 독자는 “하지만 HTTP/2는 어떻게 됐습니까?” 라고 물을 수 있습니다. 이는 매우 좋은 질문입니다. HTTP/2 표준은 2015년에 발표되었으며, 45%의 인터넷 서비스 웹 사이트에서 HTTP/2를 지원하는 등 꾸준한 채택률을 보여주고 있습니다.
그러나 이 통계는 공개 인터넷과 실제 운영 인프라에서의 HTTP 사용이 상당히 다르다는 현실을 감추고 있습니다.

모던 인터넷 인프라의 현실은 HTTP/2가 End to End 배포되는 경우가 거의 없다는 것입니다.
대기 시간이 예측할 수 없을 정도로 높고 HTTP 요청 문제로 인해 후속 요청이 지연될 수 있는 공용 인터넷에서 가장 명확하게 나타나는 문제를 해결하도록 설계되었습니다. 애플리케이션 런타임 환경 내부 (예: Public Cloud 또는 Private Data Center)에서는 대기 시간이 짧고 네트워크 안정성이 우수하며 HTTP/1.1의 텍스트 기반 전송 스트림을 직접 검사하는 기능이 HTTP/2의 이진 전송 스트림의 효율성보다 더 중요합니다.

HTTP/2는 클라이언트와 런타임 인프라의 “가장자리” 사이의 환경에 적합하기 때문에 브라우저와 모바일 장치의 사용자 경험을 크게 향상시켰습니다. 이 시점에서 일반적으로 HTTP/1.1이 사용되는 런타임 환경으로 프록시됩니다.
Edge는 CDN 공급자이거나 런타임 환경에 들어오는 트래픽을 처리하는 Reverse Proxy 로드 밸런서일 가능성이 높습니다.

HTTP 버전의 일반적인 하이브리드 배포

1-1. HTTP/3를 사용하는 이유

웹사이트와 애플리케이션을 제공하기 위해 HTTP/2와 HTTP/1.1을 혼합하는 접근 방식은 잘 작동합니다.
그렇다면 왜 또 다른 새로운 프로토콜인 HTTP/3를 제안하는 이유는 무엇일까요?

HTTP/2의 주요 혁신은 TCP를 하위 수준 전송으로 사용하는 단일 연결을 통해 여러 HTTP 요청을 다중화 하는 것입니다.
그러나 TCP에는 성능과 사용자 경험을 제한하는 내재적인 한계가 있습니다.
TCP 표준은 원래 1981년에 발표되었으며, 범용 전송 프로토콜로서 놀라운 성공을 거두었습니다.
그러나 동일한 연결을 통해 여러 개의 독립적인 요청을 다중화하면 모든 요청은 해당 연결의 신뢰성에 영향을 받습니다.
하나의 요청에 대한 패킷이 손실되면 다중화된 모든 요청은 손실된 패킷이 먼저 감지된 후 재전송 될 때까지 지연됩니다.

HTTP/3 은 단일 TCP 연결에 의존하지 않고 다중 연결을 지원하도록 특별히 설계된 QUIC 전송 프로토콜을 기반으로 합니다. 대신 QUIC 은 클라이언트와 서버 간에 패킷을 이동하기 위한 저수준 전송 메커니즘으로 UDP를 사용 하고 HTTP 요청이 이루어지는 안정적인 연결을 구현합니다. 특히 QUIC은 TLS를 HTTP/1.1 및 HTTP/2와 같은 추가 계층이 아닌 필수 구성 요소로 통합합니다.

HTTP 전송 스택의 상위 수준 개요

QUIC의 목표는 HTTP/3을 위한 고성능, 높은 신뢰성, 높은 수준의 보안 전송 프로토콜을 제공하는 것입니다.
의미상 HTTP/3 자체는 HTTP/2와 매우 유사합니다. 그러나 HTTP에는 명시적인 버전 번호가 없습니다.
https://www.example.com은 HTTP/1.1, HTTP/2 및 HTTP/3 중 하나 이상을 지원할 수 있습니다.
클라이언트 (웹 브라우저)는 어떻게 HTTP의 버전을 알 수 있을까요?

버전 관련 문제는 HTTP/2의 도입으로 처음 발생했으며, 이를 해결하기 위해 TLS Handshake를 사용하여 클라이언트와 서버가 HTTP/2로 통신할 수 있는지 여부를 감지합니다. 이렇게 함으로써 클라이언트는 연결이 설정되기 전에 서버와 통신하는 방법을 알 수 있습니다. 그러나 기반 전송 프로토콜로 TCP 대신 UDP를 사용하는 QUIC의 사용은 새로운 문제를 제시합니다. 클라이언트가 초기에 요청하는 연결 유형이 TCP인지 UDP인지 어떻게 알 수 있을까요?
하결책은 클라이언트가 초기 HTTP 요청을 위해 TCP 연결을 설정하는 것입니다. HTTP/3를 지원하는 서버의 응답에는 Alt-Svc 헤더가 포함되어 있어 HTTP/3 트래픽을 수신하는 UDP 포트를 지정합니다.
또한, 브라우저는 QUIC를 지원하는 사이트를 기억하여 Alt-Svc를 기반으로 하는 검색 방법의 overhead를 제거합니다.

2. NGINX HTTP/3 + QUIC 미리보기

NGINX를 위한 공식 NGINX HTTP/3 + QUIC 구현인 http_v3_module의 초기 릴리스를 발표합니다. 이는 기술 미리보기로 실험적인 것으로 간주되며, Production용으로 사용해서는 안 됩니다. 작성 시점에서 QUIC 표준은 아직 최종화되지 않았으며, 이 초기 릴리스는 현재 초안의 일부를 구현한 것입니다.

몇 개월 간의 설계 및 개발 끝에 http_v3_module은 상호 운용성 테스트를 위한 준비가 되었습니다. 일반적인 피드백과 코드 기여도 환영합니다. http_v3_module은 여전히 실험적인 상태이므로 NGINX 오픈소스 Mainline 개발 branches(및 NGINX Plus의 어떠한 릴리스)에서 사용할 수 없습니다.

또한 이 NGINX HTTP/3 + QUIC 구현은 Cloudflare의 quiche 프로젝트의 일환으로 제공되는 패치와 관련이 없으며, 전적으로 새롭게 개발된 것임을 참고하세요.

NGINX 구성에 익숙한 사용자에게는 NGINX HTTP/3 + QUIC를 활성화하는 것이 매우 간단합니다.

server {
    listen 443 ssl;              # TCP listener for HTTP/1.1
    listen 443 quic reuseport;  # UDP listener for QUIC+HTTP/3

    ssl_protocols       TLSv1.3; # QUIC requires TLS 1.3
    ssl_certificate     ssl/www.example.com.crt;
    ssl_certificate_key ssl/www.example.com.key;

    add_header Alt-Svc 'h3=":443"';   # Advertise that HTTP/3 is available
    add_header QUIC-Status $quic;     # Sent when QUIC was used
}

nginx-quic 저장소에서 NGINX를 빌드하는 방법과 권장 구성에 대한 자세한 정보는 README를 참조하십시오. 또한, http_v3_module을 활성화한 데모 사이트인 https://quic.nginx.org/에서 브라우저가 이미 QUIC를 지원하는지 확인하고, nginx-quic을 사용하여 NGINX HTTP/3 상호 운용성을 비교할 수 있습니다. QUIC의 초안 상태로 인해 QUIC 연결을 활성화하려면 개발 버전 또는 최신 브라우저 빌드를 사용해야 할 수 있습니다.

추가 의견은 NGINX STORE에 문의하여 답변을 받아보세요.