NGINX QUIC+HTTP/3 구현을 위한 바이너리 패키지에 대한 활용 가능

• Red Hat Enterprise Linux 9 및 바이너리 호환 변형
• 우분투 22.04

바이너리는 프리뷰 구현을 호스팅하는 별도의 nginx-quic repo의 quic 브랜치에서 제공하는 최신 제공물입니다. NGINX에서 QUIC+HTTP/3 작업을 시작한 이래로 , QUIC+HTTP/3 및 QUIC를 지원하는 SSL/TLS 라이브러리를 선택하여 NGINX 오픈 소스를 다운로드하고 빌드 할 수 있습니다. 코드는 실험적이라고 표시되어 있지만, 여러 커뮤니티 구성원이 프로덕션에서 nginx-quic을 성공적으로 사용하고 있다고 보고했습니다 .

사전 빌드된 바이너리를 출시하는 주된 동기는 QUIC+HTTP/3로 NGINX를 테스트하는 것을 더 빠르고 쉽게 만드는 것입니다. 바이너리는 소스에서 컴파일할 필요성을 없애고 표준 패키지 관리 도구를 사용하여 설치할 수 있습니다.

이 글을 쓰는 시점에서 오픈소스 SSL/TLS의 사실상 표준인 OpenSSL은 QUIC를 지원하지 않습니다. 따라서 종속성으로 자동 설치되는 quictls 라이브러리 패키지로 바이너리 배포판을 빌드합니다. quictls를 선택한 이유는 현재 안정성, 호환성, 기능의 최상의 조합을 나타내기 때문입니다.

바이너리 배포판에 대한 설치 지침은 NGINX QUIC 웹사이트 에서 확인할 수 있습니다 .

QUIC+HTTP/3를 위한 NGINX 구성

QUIC+HTTP/3에 맞게 NGINX를 구성하기 위한 새로운 지침이 여러 개 있지만, 기존 가상 서버( server{}) 구성 블록에서 HTTP/1.1 및 HTTP/2에 대한 지침과 쉽게 결합할 수 있습니다.

server{}가장 기본적인 기능 구성의 경우 (and child ) 블록 에 세 개의 지시문을 포함하기만 하면 됩니다 location{}.

샘플 server{}블록은 다음과 같습니다.

server {    # for better compatibility we recommend
    # using the same port number for QUIC and TCP
    listen 443 quic reuseport; # QUIC
    listen 443 ssl;             # TCP

    ssl_certificate     certs/example.com.crt;
    ssl_certificate_key certs/example.com.key;
    ssl_protocols       TLSv1.3;

    location / {
        # advertise that QUIC is available on the configured port
        add_header Alt-Svc 'h3=":$server_port"; ma=86400';
                
        #proxy_pass <upstream_group>; 
        #root       /<root_directory>; 
    }
}

다음을 포함하여 여러 가지 새로운 선택적 HTTP/3 관련 지시문 및 변수가 있습니다(스니펫에 표시되지 않음):

• $http3 – (변수) HTTP/3 세션 중에 요청이 전송될 때 설정됩니다 h3(그렇지 않으면 빈 문자열).
• quic_retry – (지시) 로 설정하면 onNGINX가 요청자에게 QUIC 재시도 메시지를 다시 보내 요청자의 IP 주소를 검증하기 위해 사용할 새 연결 ID를 지정하도록 지시합니다. QUIC 재시도 패킷은 QUIC가 UDP를 통해 실행되기 때문에 TCP 3방향 연결 핸드셰이크를 사용하여 연결을 검증할 수 없다는 사실을 부분적으로 보완합니다.

• ssl_early_data – (지시) 로 설정하면 on클라이언트가 새 TLS 1.3 연결을 통해 보낸 첫 번째 요청에서 해당 클라이언트에서 이전에 연결이 있었을 경우 애플리케이션 데이터를 수락하도록 NGINX에 지시합니다. 이를 0 왕복 시간(0‑RTT) 연결 재개 라고 합니다 . "조기 데이터" 전송 지원은 TLS 1.3 의 기능이며 TLS 핸드셰이크에 필요한 추가 왕복 메시지 교환을 제거하여 QUIC+HTTP/3의 성능을 개선하는 데 기여합니다.

  참고: 0‑RTT 연결 재개는 초기 데이터가 . 이외의 HTTP 요청 방법을 포함하는 경우 재생 공격을 받을 수 있으므로 보안 위험을 초래할 수 있습니다. 자세한 내용은 블로그의 Announcing NGINX Plus R17 에서 TLS 1.3에 대한 섹션을GET 참조하세요 .

이 다이어그램은 QUIC+HTTP/3를 사용한 0‑RTT 연결 재개가 클라이언트가 NGINX에 대한 QUIC 연결을 재개할 때 첫 번째 메시지에서 HTTP 요청을 보낼 수 있기 때문에 성능이 어떻게 향상되는지 강조합니다. 반면 TLS가 있는 TCP의 경우 클라이언트는 NGINX와 새로운 TLS 핸드셰이크를 수행하여 보안 연결을 설정해야 하며, 몇 번의 추가 왕복이 필요합니다.

모든 새로운 지침 및 변수에 대한 자세한 내용은 nginx-quic README 의 3. 구성 섹션을 참조하세요 .

QUIC+HTTP/3로 NGINX 테스트

이전에 언급했듯이, 사전 빌드된 바이너리를 릴리스하는 동기 중 하나는 NGINX가 HTTP/3 트래픽을 올바르게 처리하는지 테스트하기 쉽게 만드는 것입니다. 간단한 명령줄 테스트의 경우 HTTP/3 지원으로 빌드 하거나 사전 빌드된 컨테이너를 사용할 수curl 있습니다 . 또한 대부분의 브라우저의 최신 버전은 QUIC+HTTP/3를 지원합니다.

QUIC 지원 사이트가 브라우저의 HTTP/3 연결 요청을 충족하는지 확인하려면 브라우저의 개발자 도구를 사용하여 NGINX에서 반환된 HTTP 헤더를 검사할 수 있습니다. NGINX가 TCP를 통한 브라우저의 초기 HTTP 요청에 대한 응답에 위에서Alt-Svc 설명한 헤더를 포함하는 경우 QUIC+HTTP/3 구현이 올바르게 작동합니다.

그 시점에서 QUIC 지원 브라우저는 지시문에 지정된 포트에서 QUIC 연결을 만들고 Alt-Svc, 이후의 HTTP 요청과 응답은 QUIC를 통해 이루어집니다. QUIC+HTTP/3가 사용되고 있는지 확인하는 또 다른 방법은 add_header변수에서 캡처한 프로토콜로 사용자 지정 HTTP 헤더의 값을 설정하는 또 다른 지시문을 포함하는 것입니다. QUIC 연결이 설정되기 전부터 QUIC가 사용될 때 $server-protocol까지 헤더 값이 변경되는 것을 추적할 수 있습니다 .HTTP/1.xHTTP/3.0

location사용자 정의 HTTP 헤더가 있는 샘플 블록은 다음과 같습니다 X-protocol.

location / {     # advertise that QUIC is available on the configured port 
    add_header Alt-Svc 'h3=":$server_port"; ma=86400'; 
       
    # signal whether we are using QUIC+HTTP/3
    add_header X-protocol $server_protocol always;        
    
    #proxy_pass <upstream_group>; 
    #root /<root_directory>; 
}

또는 Chrome HTTP Indicator 확장 프로그램과 같은 도구가 사용 중인 프로토콜을 시각적으로 표시합니다. (이것은 어떤 브라우저 확장 프로그램을 지지하는 것이 아니며, 확장 프로그램의 가능한 보안 영향이 귀하의 상황을 감안할 때 허용 가능하다는 것을 스스로 확인해야 합니다).

위 내용과 같이 NGINX Plus 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요

전문가에게 상담받기