NGINX의 QUIC 네트워킹 및 암호화 입문

Robert Haynes기술 마케팅 매니저

NGINX 블로그에서 QUIC과 HTTP/3가 처음 언급된 것은 4년 전이었습니다(!). 여러분과 마찬가지로 저희도 이제 QUIC 구현이 곧 NGINX Open Source 메인라인 브랜치에 병합되기를 손꼽아 기다리고 있습니다. 오랜 개발 기간을 고려하면 그동안 QUIC에 대해 별로 생각해 보지 않으셨더라도 충분히 이해할 만합니다.

하지만 이제 개발자나 사이트 관리자는 QUIC가 일부 네트워킹 세부 사항에 대한 책임을 운영 체제에서 NGINX(및 모든 HTTP 앱)로 어떻게 이전하는지 알아야 합니다. 네트워킹이 전문 분야가 아니더라도 QUIC를 도입한다는 것은 이제 네트워크에 대한 고민도 (적어도 어느 정도는) 여러분의 업무에 포함된다는 뜻입니다.

이 글에서는 명확한 설명을 위해 일부 세부 사항을 단순화하고 중요하지 않은 정보는 생략하면서, QUIC에 사용되는 주요 네트워킹 및 암호화 개념을 자세히 살펴봅니다. 이 과정에서 일부 미묘한 차이가 누락될 수 있지만, 여러분의 환경에 QUIC을 효과적으로 도입하는 데 충분한 정보를 제공하거나 최소한 관련 지식을 쌓을 수 있는 토대를 마련하는 것이 목적입니다.

QUIC을 처음 접하신다면 먼저 이전에 게시한 게시물 중 하나를 읽고 개요 동영상을 시청하시기를 권장합니다.

 

QUIC에 대한 더 자세하고 포괄적인 설명은 IETC QUIC 워킹 그룹의 훌륭한 문서인 QUIC 전송 프로토콜의 관리 용이성과 이 문서 전반에 링크된 추가 자료를 참조하시기 바랍니다.

QUIC의 네트워킹과 암호화에 관심을 가져야 하는 이유는 무엇일까요?

지금까지는 클라이언트와 NGINX 간 네트워크 연결의 복잡한 세부 사항이 대부분의 사용자에게 그다지 중요하지 않았습니다. 결국 HTTP/1.x와 HTTP/2에서는 운영 체제가 클라이언트와 NGINX 간의 전송 제어 프로토콜(TCP) 연결 설정을 담당합니다. NGINX는 연결이 설정되면 이를 사용하기만 하면 됩니다.

하지만 QUIC에서는 연결 생성, 검증 및 관리에 대한 책임이 기반 운영 체제에서 NGINX로 넘어갑니다. 이제 NGINX는 이미 설정된 TCP 연결을 전달받는 대신 사용자 데이터그램 프로토콜(UDP) 데이터그램 스트림을 수신하며, 이를 클라이언트 연결과 스트림으로 파싱해야 합니다. 또한 패킷 손실, 연결 재시작 및 혼잡 제어 처리도 NGINX가 담당합니다.

또한 QUIC는 연결 시작, 버전 협상, 암호화 키 교환을 하나의 연결 설정 작업으로 통합합니다. TLS 암호화는 QUIC+HTTP/3와 TCP+HTTP/1+2에서 대체로 비슷한 방식으로 처리되지만, 계층 4 로드 밸런서, 방화벽, 보안 어플라이언스와 같은 다운스트림 장치에 중요한 영향을 미칠 수 있는 차이점이 있습니다.

궁극적으로 이러한 변화는 NGINX 구성이나 운영을 거의 변경하지 않고도 사용자에게 더 안전하고 빠르며 안정적인 경험을 제공합니다. 하지만 NGINX 관리자는 문제가 발생했을 때 무고함을 입증하는 데 걸리는 평균 시간을 최대한 단축하기 위해서라도 QUIC과 NGINX에서 어떤 일이 일어나고 있는지 최소한 어느 정도는 이해해야 합니다.

(이 글에서는 HTTP/3에 QUIC가 필요하기 때문에 HTTP 동작을 중점적으로 다루지만, QUIC는 다른 프로토콜에도 사용할 수 있다는 점에 주목할 필요가 있습니다. 대표적인 예로 RFC 9250에 정의된 전용 QUIC 연결을 통한 DNS가 있습니다.)

이제 소개는 이쯤에서 마치고, QUIC 네트워킹의 구체적인 내용을 살펴보겠습니다.

TCP와 UDP 비교

QUIC은 클라이언트와 서버 간에 HTTP 애플리케이션 데이터를 전송하는 데 사용되는 기반 네트워크 프로토콜에 중대한 변화를 가져옵니다.

앞서 언급했듯이 TCP는 항상 HTTP 웹 애플리케이션 데이터를 전송하는 데 사용되는 프로토콜이었습니다. TCP는 IP 네트워크를 통해 데이터를 안정적으로 전달하도록 설계되었습니다. 연결을 설정하고 데이터 수신을 확인하기 위한 명확하고 널리 알려진 메커니즘뿐만 아니라, 불안정하고 혼잡한 네트워크에서 흔히 발생하는 패킷 손실과 지연을 관리하기 위한 다양한 알고리즘과 기법도 갖추고 있습니다.

TCP는 안정적인 전송을 제공하지만 성능과 지연 시간 측면에서 상충 관계가 있습니다. 또한 데이터 암호화는 TCP에 기본으로 포함되어 있지 않으므로 별도로 구현해야 합니다. 변화하는 HTTP 트래픽 패턴에 맞춰 TCP를 개선하거나 확장하는 것 역시 쉽지 않았습니다. TCP 처리가 Linux 커널에서 수행되기 때문에, 시스템의 전반적인 성능과 안정성에 예기치 않은 영향을 미치지 않도록 모든 변경 사항을 신중하게 설계하고 테스트해야 합니다.

또 다른 문제는 많은 경우 클라이언트와 서버 간의 HTTP 트래픽이 방화벽이나 로드 밸런서와 같은 여러 TCP 처리 장치(통칭하여 ‘미들박스’)를 거치며, 이러한 장치에는 TCP 표준의 변경 사항이 늦게 적용될 수 있다는 점입니다.

반면 QUIC은 전송 프로토콜로 UDP를 사용합니다. UDP는 TCP와 마찬가지로 IP 네트워크를 통해 데이터를 전송하도록 설계되었지만, 의도적으로 연결 설정과 신뢰성 있는 전송 기능을 제공하지 않습니다. 이러한 오버헤드가 없기 때문에 UDP는 신뢰성보다 효율성과 속도가 더 중요한 다양한 애플리케이션에 적합합니다.

하지만 대부분의 웹 애플리케이션에서는 안정적인 데이터 전송이 필수적입니다. 기반이 되는 UDP 전송 계층은 안정적인 데이터 전송을 제공하지 않으므로, 이러한 기능은 QUIC(또는 애플리케이션 자체)에서 제공해야 합니다. 다행히 이 점에서 QUIC은 TCP보다 몇 가지 장점이 있습니다:

• QUIC 처리는 Linux 사용자 공간에서 수행되므로 특정 작업에서 문제가 발생하더라도 전체 시스템에 미치는 위험이 적습니다. 따라서 새로운 기능을 빠르게 개발하기가 더 용이합니다.
• 위에서 언급한 ‘미들박스’는 일반적으로 UDP 트래픽을 최소한으로만 처리하므로 QUIC 프로토콜의 개선을 제약하지 않습니다.

간소화된 QUIC 네트워크 구조

QUIC 스트림은 HTTP/3 요청이나 응답(또는 기타 애플리케이션 데이터)을 포함하는 논리적 객체입니다. 네트워크 엔드포인트 간에 전송될 때는 다이어그램에 표시된 것처럼 여러 논리 계층으로 캡슐화됩니다.

바깥쪽부터 안쪽으로 살펴보면, 논리적 계층과 객체는 다음과 같습니다:

• UDP 데이터그램 – 소스 및 대상 포트(길이 및 체크섬 데이터 포함)를 지정하는 헤더와 그 뒤에 이어지는 하나 이상의 QUIC 패킷으로 구성됩니다. 데이터그램은 네트워크를 통해 클라이언트에서 서버로 전송되는 정보의 단위입니다.
• QUIC 패킷 – 하나의 QUIC 헤더와 하나 이상의 QUIC 프레임을 포함합니다.
• QUIC 헤더 – 패킷에 대한 메타데이터를 포함합니다. 헤더에는 두 가지 유형이 있습니다:
  • 연결 설정 중에 사용되는 긴 헤더입니다.
  • 연결이 설정된 후 사용되는 짧은 헤더입니다. 여기에는 연결 ID, 패킷 번호, 키 단계(키 순환을 지원하기 위해 패킷 암호화에 사용된 키를 추적하는 데 사용됨) 등의 데이터가 포함됩니다. 패킷 번호는 특정 연결 및 키 단계 내에서 고유하며 항상 증가합니다.
• 프레임 – 유형, 스트림 ID, 오프셋 및 스트림 데이터를 포함합니다. 스트림 데이터는 여러 프레임에 분산되지만, 연결 ID, 스트림 ID 및 오프셋을 사용하여 조합할 수 있습니다. 오프셋은 데이터 조각을 올바른 순서로 배치하는 데 사용됩니다.
• 스트림 – 단일 QUIC 연결 내에서 이루어지는 단방향 또는 양방향 데이터 흐름입니다. 각 QUIC 연결은 여러 개의 독립적인 스트림을 지원할 수 있으며, 각 스트림에는 고유한 스트림 ID가 있습니다. 일부 스트림이 포함된 QUIC 패킷이 손실되더라도 누락된 패킷에 포함되지 않은 다른 스트림의 진행에는 영향을 주지 않습니다(이는 HTTP/2에서 발생하는 HOL 블로킹을 방지하는 데 매우 중요합니다). 스트림은 양방향일 수 있으며 어느 엔드포인트에서든 생성할 수 있습니다.

연결 설정

잘 알려진 SYN / SYN-ACK / ACK 3단계 핸드셰이크를 통해 TCP 연결이 설정됩니다:

그림 2. TCP 연결을 설정하는 3방향 핸드셰이크

QUIC 연결을 설정하는 과정도 이와 비슷하지만 더 효율적입니다. 또한 암호화 핸드셰이크의 일부로 연결 설정 과정에 주소 검증이 포함됩니다. 주소 검증은 악의적인 공격자가 공격 대상 피해자의 출발지 주소 정보를 위조한 패킷을 서버에 보내는 트래픽 증폭 공격을 방어합니다. 공격자는 서버가 자신이 직접 생성할 수 있는 것보다 더 많거나 더 큰 패킷을 피해자에게 보내도록 유도하여 트래픽을 폭증시키려 합니다. (자세한 내용은 섹션 8RFC 9000의 QUIC: UDP 기반 다중화 및 보안 전송을 참조하세요.)

연결 설정 과정에서 클라이언트와 서버는 각각 독립적인 연결 ID를 제공하며, 이 ID는 QUIC 헤더에 인코딩됩니다. 따라서 클라이언트의 원본 IP 주소와 관계없이 연결을 간단히 식별할 수 있습니다.

하지만 QUIC 연결을 처음 설정할 때는 TLS 암호화 키 교환 작업도 포함되므로, 서버 입장에서는 TCP 연결 설정 중에 생성하는 단순한 SYN-ACK 응답보다 더 많은 연산 비용이 듭니다. 또한 키 교환 작업이 수행되기 전에 클라이언트 IP 주소를 검증하지 않기 때문에 분산 서비스 거부(DDoS) 공격에 악용될 가능성도 있습니다.

하지만 복잡한 암호화 작업을 시작하기 전에 클라이언트 IP 주소를 검증하도록 NGINX를 구성할 수 있습니다. 이를 위해 quic_retry 지시어를 on으로 설정합니다. 그러면 NGINX는 클라이언트에 토큰이 포함된 재시도 패킷을 전송하며, 클라이언트는 연결 설정 패킷에 이 토큰을 포함해야 합니다.

그림 3. 재시도 패킷이 없는 경우와 있는 경우의 QUIC 연결 설정

이 메커니즘은 TCP의 3방향 핸드셰이크와 다소 유사하며, 무엇보다도 클라이언트가 자신이 제시한 소스 IP 주소의 실제 소유자임을 확인합니다. 이러한 확인 절차가 없으면 NGINX와 같은 QUIC 서버는 위조된 소스 IP 주소를 이용한 간단한 DoS 공격에 취약할 수 있습니다. (이러한 공격을 완화하는 또 다른 QUIC 메커니즘은 모든 초기 연결 패킷을 최소 1200바이트가 되도록 패딩해야 한다는 요구 사항으로, 패킷 전송에 더 많은 비용이 들게 합니다.)

또한 재시도 패킷은 클라이언트에 전송하는 연결 ID에 연결 세부 정보를 인코딩하여 TCP SYN 플러드 공격과 유사한 공격(시작되었지만 완료되지 않은 수많은 핸드셰이크가 메모리에 저장되어 서버 리소스가 고갈되는 공격)을 완화합니다. 이 방식에는 서버 측에 정보를 보관할 필요가 없다는 추가적인 이점도 있습니다. 이후 클라이언트가 제시하는 연결 ID와 토큰을 사용해 연결 정보를 복원할 수 있기 때문입니다. 이 기법은 TCP SYN 쿠키와 유사합니다. 또한 NGINX와 같은 QUIC 서버는 연결 재개 속도를 높이기 위해 클라이언트의 향후 연결에 사용할 수 있는 만료 기한이 있는 토큰을 제공할 수 있습니다.

연결 ID를 사용하면 연결이 기본 전송 계층에 종속되지 않으므로 네트워크 환경이 변경되어도 연결이 끊어지지 않습니다. 이에 대해서는 클라이언트 IP 주소 변경을 원활하게 관리하기에서 설명합니다.

손실 감지

연결이 설정되고(아래에서 자세히 설명하는 것처럼 암호화도 활성화되면) 아래 클라이언트와 NGINX 간에 HTTP 요청과 응답을 주고받을 수 있습니다. UDP 데이터그램이 송수신됩니다. 하지만 여러 요인으로 인해 이러한 데이터그램 중 일부가 손실되거나 지연될 수 있습니다.

TCP에는 패킷 전달을 확인하고, 패킷 손실이나 지연을 감지하며, 손실된 패킷의 재전송을 관리하여 순서가 올바르고 완전한 데이터를 애플리케이션 계층에 전달하는 복잡한 메커니즘이 있습니다. UDP에는 이러한 기능이 없으므로 혼잡 제어와 손실 감지는 QUIC 계층에서 구현됩니다.

• 클라이언트와 서버는 수신한 각 QUIC 패킷에 대해 명시적인 확인 응답을 보냅니다(단, 우선순위가 낮은 프레임만 포함된 패킷에는 즉시 확인 응답을 보내지 않습니다).
• 신뢰할 수 있는 전송이 필요한 프레임이 포함된 패킷이 정해진 제한 시간 내에 확인 응답을 받지 못하면 손실된 것으로 간주됩니다. 제한 시간은 패킷의 내용에 따라 달라집니다. 예를 들어 암호화를 설정하고 연결을 구성하는 데 필요한 패킷은 QUIC 핸드셰이크 성능에 필수적이므로 제한 시간이 더 짧습니다.
• 패킷이 손실된 것으로 판단되면 누락된 프레임은 새 시퀀스 번호가 부여된 새 패킷으로 재전송됩니다.
• 패킷 수신자는 패킷의 스트림 ID와 오프셋을 사용하여 전송된 데이터를 올바른 순서로 조합합니다. 패킷 번호는 전송 순서만 나타낼 뿐, 패킷을 조합하는 방식은 결정하지 않습니다.
• 수신 측의 데이터 조립은 전송 순서와 무관하므로, 패킷이 손실되거나 지연되더라도 연결의 모든 스트림이 아니라 해당 패킷에 포함된 개별 스트림에만 영향을 줍니다. 따라서 스트림이 전송 계층에 속하지 않아 HTTP/1.HOL 블로킹 및 HTTP/2에서 발생하는 문제가 해결됩니다. HTTP/1.x 및 HTTP/2에서는 스트림이 전송 계층에 속하지 않기 때문에 이 문제가 발생합니다.

손실 감지에 대한 전체 설명은 이 입문서의 범위를 벗어납니다. 타임아웃을 결정하는 메커니즘과 전송 중인 상태로 허용되는 미확인 데이터의 양에 대한 자세한 내용은 RFC 9002 「QUIC 손실 감지 및 혼잡 제어」를 참조하세요.

클라이언트 IP 주소 변경을 원활하게 관리하기

클라이언트의 IP 주소(애플리케이션 세션의 맥락에서는 소스 IP 주소라고 함)는 세션 도중 변경될 수 있습니다. 예를 들어 VPN이나 게이트웨이의 공인 주소가 변경되거나 스마트폰 사용자가 Wi-Fi 서비스 지역을 벗어나 셀룰러 네트워크로 전환해야 하는 경우가 이에 해당합니다. 또한 네트워크 관리자는 전통적으로 UDP 트래픽의 제한 시간을 TCP 연결보다 짧게 설정해 왔으며, 이로 인해 네트워크 주소 변환(NAT) 리바인딩이 발생할 가능성이 높아집니다.

QUIC은 이로 인해 발생할 수 있는 중단을 줄이기 위해 두 가지 메커니즘을 제공합니다. 클라이언트는 자신의 주소가 변경될 예정임을 서버에 미리 알릴 수 있으며, 서버는 예기치 않은 클라이언트 주소 변경에도 원활하게 대응할 수 있습니다. 전환 과정에서도 연결 ID가 동일하게 유지되므로, 확인 응답을 받지 못한 프레임을 새 IP 주소로 재전송할 수 있습니다.

QUIC 세션 중 소스 IP 주소가 변경되면 소스 IP 주소와 포트를 사용하여 특정 UDP 데이터그램을 수신할 업스트림 서버를 결정하는 다운스트림 로드 밸런서(또는 기타 레이어 4 네트워킹 구성 요소)에 문제가 발생할 수 있습니다. 트래픽을 올바르게 관리하려면 레이어 4 네트워크 장치 공급업체가 QUIC 연결 ID를 처리할 수 있도록 장치를 업데이트해야 합니다. 로드 밸런싱과 QUIC의 미래에 대해 자세히 알아보려면 IETF 초안 QUIC‑LB: 라우팅 가능한 QUIC 연결 ID 생성을 참조하세요.

암호화

In 연결 설정에서는 초기 QUIC 핸드셰이크가 단순히 연결을 설정하는 것 이상의 역할을 한다고 언급했습니다. TCP의 TLS 핸드셰이크와 달리 UDP에서는 키와 TLS 1.3 암호화 매개변수의 교환이 초기 연결 과정의 일부로 이루어집니다. 이 기능은 여러 차례의 데이터 교환을 없애고 클라이언트가 이전 연결을 재개할 때 제로 왕복 시간(0-RTT)을 지원합니다.

QUIC은 암호화 핸드셰이크를 연결 설정 과정에 통합할 뿐만 아니라 TCP+TLS보다 더 많은 메타데이터를 암호화합니다. 키 교환이 이루어지기 전에도 초기 연결 패킷이 암호화됩니다. 도청자가 여전히 키를 알아낼 수는 있지만, 암호화되지 않은 패킷에서 키를 알아내는 것보다 더 많은 노력이 필요합니다. 이를 통해 공격자와 잠재적인 국가 차원의 검열 기관 모두가 관심을 가질 수 있는 서버 이름 표시(SNI) 등의 데이터를 더욱 안전하게 보호할 수 있습니다. 그림 5는 QUIC이 TCP+TLS보다 잠재적으로 민감한 메타데이터(빨간색)를 더 많이 암호화하는 방식을 보여 줍니다.

QUIC 페이로드의 모든 데이터는 TLS 1.3을 사용하여 암호화됩니다. 여기에는 두 가지 장점이 있습니다. 오래되고 취약한 암호 스위트와 해싱 알고리즘은 허용되지 않으며 순방향 비밀성(FS) 키 교환 메커니즘이 필수입니다. 순방향 비밀성은 공격자가 개인 키와 트래픽 사본을 확보하더라도 데이터를 복호화하지 못하도록 합니다.

낮은 RTT 및 제로 RTT 연결로 지연 시간 단축

애플리케이션 데이터를 전송하기 전에 클라이언트와 서버 간에 필요한 왕복 통신 횟수를 줄이면 애플리케이션 성능이 향상되며, 특히 지연 시간이 긴 네트워크에서 그 효과가 큽니다.

TLS 1.3에서는 암호화된 연결을 설정하는 데 한 번의 왕복 통신만 필요하고 연결을 재개할 때는 왕복 통신이 필요하지 않지만, TCP를 사용할 경우 TLS Client Hello 전에 핸드셰이크가 이루어져야 합니다.

QUIC은 암호화 작업과 연결 설정을 결합하므로, 클라이언트가 첫 번째 QUIC 패킷에서 바로 요청을 보낼 수 있는 진정한 0‑RTT 연결 재설정을 제공합니다. 이를 통해 첫 요청 전에 연결을 설정하기 위한 초기 왕복 과정이 없어져 지연 시간이 단축됩니다.

이 경우 클라이언트는 이전 연결에서 사용한 매개변수로 암호화된 HTTP 요청을 전송하며, 주소 검증을 위해 이전 연결 중 서버가 제공한 토큰을 포함합니다.

안타깝게도 0‑RTT 연결 재개는 순방향 비밀성을 제공하지 않으므로, 클라이언트의 최초 요청은 해당 통신의 다른 트래픽만큼 안전하게 암호화되지 않습니다. 최초 요청 이후의 요청과 응답은 순방향 비밀성으로 보호됩니다. 더 큰 문제가 될 수 있는 점은 최초 요청이 재전송 공격에도 취약하다는 것입니다. 공격자는 최초 요청을 가로챈 후 서버에 여러 번 재전송할 수 있습니다.

많은 애플리케이션과 웹사이트에서는 0‑RTT 연결 재개로 얻는 성능 향상이 이러한 잠재적 취약점보다 더 큰 이점을 제공하지만, 이에 대한 판단은 직접 내려야 합니다.

이 기능은 NGINX에서 기본적으로 비활성화되어 있습니다. 활성화하려면 ssl_early_data 지시어를 on으로 설정하세요.

Moving from HTTP/1.1 to HTTP/3 with the Alt-Svc 헤더를 사용하여 HTTP/1.1에서 HTTP/3로 전환

거의 모든 클라이언트(특히 브라우저)는 처음에 TCP/TLS를 통해 연결합니다. 서버가 QUIC+HTTP/3를 지원하는 경우, h3 매개변수가 포함된 Alt-Svc 헤더를 HTTP/1.1 응답으로 반환하여 이를 클라이언트에 알립니다. 그러면 클라이언트는 QUIC+HTTP/3를 사용할지, 아니면 이전 버전의 HTTP를 계속 사용할지 선택합니다. (참고로 Alt-Svc 헤더는 RFC 7838에 정의되어 있으며, QUIC보다 먼저 등장했고 다른 용도로도 사용할 수 있습니다.)

The Alt-Svc 헤더는 동일한 서비스를 대체 호스트, 프로토콜 또는 포트(혹은 이들의 조합)에서도 사용할 수 있음을 클라이언트에 알립니다. 또한 클라이언트는 이 서비스를 계속 사용할 수 있다고 안전하게 간주할 수 있는 기간도 안내받을 수 있습니다.

몇 가지 예:

Alt-Svc: h3=":443" 이 서버의 443번 포트에서 HTTP/3를 사용할 수 있습니다.Alt-Svc: h3="new.example.com:8443" 서버 new.example.com의 8443번 포트에서 HTTP/3를 사용할 수 있습니다.Alt-Svc: h3=":8443"; ma=600 이 서버의 8443번 포트에서 HTTP/3를 사용할 수 있으며, 최소 10분 동안 사용할 수 있습니다.

필수 사항은 아니지만, 대부분의 경우 서버는 TCP+TLS와 동일한 포트에서 QUIC 연결에 응답하도록 구성됩니다.

NGINX가 Alt-Svc 헤더를 포함하도록 구성하려면 add_header 지시어를 사용합니다. 이 예에서 $server_port 변수는 NGINX가 클라이언트가 TCP+TLS 요청을 보낸 포트에서 QUIC 연결을 수락한다는 의미이며, 86,400은 24시간을 의미합니다:

add_header Alt-Svc 'h3=":$server_port"; ma=86400';

결론

이 블로그에서는 QUIC의 기본 개념을 알기 쉽게 설명하며, QUIC에 사용되는 주요 네트워킹 및 암호화 작업을 이해하는 데 필요한 전반적인 내용을 제공합니다.

QUIC + HTTP/3용 NGINX 구성에 대해 더 자세히 알아보려면 블로그에서 NGINX QUIC+HTTP/3 프리뷰 구현을 위한 바이너리 패키지 출시를 읽거나 웨비나 NGINX 및 QUIC+HTTP/3 실습을 시청하세요. QUIC+HTTP/3용 NGINX 지시어 전체에 대한 자세한 내용과 사전 빌드된 바이너리를 설치하거나 소스에서 빌드하는 전체 지침은 NGINX QUIC 웹페이지를 참조하세요.

작성자 소개

Robert Haynes기술 마케팅 매니저

Robert Haynes의 다른 블로그 게시물