NGINX의 QUIC 네트워킹 및 암호화에 대한 입문서

NGINX 블로그에서 QUIC과 HTTP/3가 처음 언급된 건 벌써 4년 전 입니다(!). 여러분과 마찬가지로 우리도 이제 QUIC 구현체가 NGINX 오픈 소스 메인라인 브랜치에 곧 병합될 것을 간절히 기대하고 있습니다. 오랜 시간 동안 준비한 만큼 QUIC에 대해 많은 생각을 하지 않은 것도 이해할 만합니다.

하지만 이 시점에서 개발자나 사이트 관리자라면 QUIC이 일부 네트워킹 세부 정보에 대한 책임을 운영 체제에서 NGINX(및 모든 HTTP 앱)로 어떻게 전환하는지 알아야 합니다. 네트워킹에 관심이 없더라도 QUIC을 도입하면 네트워크에 대한 걱정이 이제 (적어도 약간은) 여러분의 일이 되었다는 것을 의미합니다.

이 글에서는 QUIC에서 사용되는 주요 네트워킹 및 암호화 개념을 깊이 살펴보고, 명확성을 위해 일부 세부 정보를 간소화하고 필수적이지 않은 정보는 생략합니다. 이 과정에서 미묘한 차이가 사라질 수 있지만, 우리의 의도는 여러분이 여러분의 환경에 QUIC를 효과적으로 도입하는 데 충분한 정보를 제공하거나, 적어도 여러분의 지식을 쌓을 수 있는 기반을 제공하는 것입니다.

QUIC가 처음이시라면 먼저 이전 게시물 중 하나를 읽고 개요 영상을 시청해 보시기 바랍니다.

QUIC에 대한 보다 자세하고 완전한 설명이 필요하면 IETC QUIC 작업 그룹의 QUIC 전송 프로토콜 관리 설명서와 이 문서 전반에 링크된 추가 자료를 읽어보시기 바랍니다.

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

지금까지 클라이언트와 NGINX 간의 네트워크 연결에 대한 세부적인 내용은 대부분 사용자에게 특별히 중요하지 않았습니다. 결국 HTTP/ 1.x 와 HTTP/2에서는 운영 체제가 클라이언트와 NGINX 간의 TCP(Transmission Control Protocol) 연결을 설정합니다. NGINX는 연결이 설정되면 이를 사용합니다.

그러나 QUIC에서는 연결 생성, 검증 및 관리에 대한 책임이 기본 운영 체제에서 NGINX로 이동합니다. NGINX는 설정된 TCP 연결을 수신하는 대신 이제 User Datagram Protocol(UDP) 데이터그램 스트림을 수신하고 이를 클라이언트 연결 및 스트림으로 구문 분석해야 합니다. NGINX는 이제 패킷 손실, 연결 재시작 및 혼잡 제어를 처리하는 역할도 담당합니다.

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

결국, 이러한 변경 사항의 전반적인 효과는 NGINX 구성이나 운영에 거의 변경이 없이 사용자에게 더 안전하고, 빠르고, 더 안정적인 경험을 제공하는 것입니다. 하지만 NGINX 관리자는 문제 발생 시 무해성 상태를 유지하는 평균 시간을 최대한 짧게 유지하기 위해서라도 QUIC과 NGINX에서 무슨 일이 일어나는지 조금이라도 이해해야 합니다.

(이 게시물은 HTTP 작업에 초점을 맞추고 있지만 HTTP/3에는 QUIC가 필요하지만, QUIC은 다른 프로토콜에도 사용될 수 있다는 점에 유의하는 것이 좋습니다. 그 좋은 예로는 RFC 9250 에 정의된 DNS over QUIC( 전용 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에서 경험하는 헤드 오브 라인 차단을 피하는 데 중요합니다). 스트림은 양방향일 수 있으며 두 엔드포인트 중 하나에서 생성될 수 있습니다.

연결 설정

익숙한 SYN / SYN-ACK / ACK 3방향 핸드셰이크는 TCP 연결을 설정합니다.

QUIC 연결을 설정하는 것도 비슷한 단계로 구성되지만 더 효율적입니다. 또한 암호화 핸드셰이크의 일부로 연결 설정에 주소 유효성 검사 기능을 구축합니다. 주소 검증은 악의적인 공격자가 의도한 공격 피해자에 대한 위조된 소스 주소 정보가 포함된 패킷을 서버로 보내는 트래픽 증폭 공격을 방어합니다. 공격자는 자신이 생성할 수 있는 것보다 서버가 피해자에게 더 많거나 더 큰 패킷을 생성해 엄청난 양의 트래픽이 발생하기를 바랍니다. (자세한 내용은 다음을 참조하세요. 섹션 8 RFC 9000의 빠른: UDP 기반 다중화 및 보안 전송 .)

연결 설정의 일부로 클라이언트와 서버는 QUIC 헤더에 인코딩된 독립적인 연결 ID를 제공하여 클라이언트 소스 IP 주소와 상관없이 연결을 간단히 식별할 수 있습니다.

그러나 QUIC 연결을 처음 설정하는 과정에는 TLS 암호화 키를 교환하는 작업도 포함되므로, TCP 연결을 설정하는 동안 생성하는 간단한 SYN-ACK 응답보다 서버의 컴퓨팅 비용이 많이 듭니다. 또한 키 교환 작업이 진행되기 전에 클라이언트 IP 주소가 검증되지 않으므로 분산 서비스 거부(DDoS) 공격에 대한 잠재적인 벡터가 생성됩니다.

하지만 quic_retry 지시문을 on 으로 설정하면 복잡한 암호화 작업이 시작되기 전에 클라이언트 IP 주소의 유효성을 검사하도록 NGINX를 구성할 수 있습니다. 이 경우 NGINX는 토큰을 포함한 재시도 패킷을 클라이언트에 보내고, 클라이언트는 이 토큰을 연결 설정 패킷에 포함해야 합니다.

이 메커니즘은 3방향 TCP 핸드셰이크와 다소 유사하며, 가장 중요한 점은 클라이언트가 제시하는 소스 IP 주소를 소유하고 있다는 것을 확립한다는 것입니다. 이러한 검사가 없으면 NGINX와 같은 QUIC 서버는 위조된 소스 IP 주소를 사용한 쉬운 DoS 공격에 취약할 수 있습니다. (이러한 공격을 완화하는 또 다른 QUIC 메커니즘은 모든 초기 연결 패킷을 최소 1200바이트로 패딩해야 한다는 요구 사항으로, 이를 통해 패킷을 보내는 작업이 더 비용이 많이 듭니다.)

또한 재시도 패킷은 클라이언트에 전송하는 연결 ID에 연결 세부 정보를 인코딩하여 TCP SYN 플러딩 공격(메모리에 저장된 엄청난 수의 열려 있지만 완료되지 않은 핸드셰이크로 인해 서버 리소스가 고갈되는 공격)과 유사한 공격을 완화합니다. 이 방법에는 클라이언트가 나중에 제시한 연결 ID와 토큰을 통해 연결 정보를 재구성할 수 있으므로 서버 측 정보를 보관할 필요가 없다는 추가적인 이점이 있습니다. 이 기술은 TCP SYN 쿠키와 유사합니다. 또한 NGINX와 같은 QUIC 서버는 클라이언트에서 향후 연결에 사용할 만료 토큰을 제공하여 연결 재개 속도를 높일 수 있습니다.

연결 ID를 사용하면 연결을 기본 전송 계층과 독립적으로 유지할 수 있으므로 네트워킹이 변경되어도 연결이 끊어지지 않습니다. 이에 대해서는 클라이언트 IP 주소 변경을 우아하게 관리하는 방법 에서 설명합니다.

손실 감지

연결이 설정되고( 아래에서 더 자세히 설명할 때 암호화가 활성화됨) HTTP 요청과 응답은 클라이언트와 NGINX 사이에서 앞뒤로 흐를 수 있습니다. UDP 데이터그램이 전송되고 수신됩니다. 그러나 이러한 데이터그램 중 일부가 손실되거나 지연되는 데는 여러 가지 요소가 있습니다.

TCP는 패킷 전달을 확인하고, 패킷 손실이나 지연을 감지하고, 손실된 패킷의 재전송을 관리하고, 적절하게 순서가 지정되고 완전한 데이터를 애플리케이션 계층에 전달하는 복잡한 메커니즘을 갖추고 있습니다. UDP에는 이러한 기능이 없기 때문에 혼잡 제어와 손실 감지가 QUIC 계층에서 구현됩니다.

• 클라이언트와 서버는 모두 수신한 각 QUIC 패킷에 대해 명시적인 확인을 보냅니다(다만 우선순위가 낮은 프레임만 포함된 패킷은 즉시 확인되지 않습니다).

• 안정적인 전달이 필요한 프레임이 포함된 패킷이 정해진 시간 초과 후에도 확인되지 않으면 해당 패킷은 손실된 것으로 간주됩니다.

  시간 초과 기간은 패킷의 내용에 따라 달라집니다. 예를 들어 암호화를 설정하고 연결을 설정하는 데 필요한 패킷의 경우 시간 초과가 더 짧습니다. 이는 이러한 패킷이 QUIC 핸드셰이크 성능에 필수적이기 때문입니다.

• 패킷이 손실된 것으로 간주되면, 손실된 프레임은 새로운 패킷으로 재전송되며, 이 패킷에는 새로운 시퀀스 번호가 부여됩니다.
• 패킷 수신자는 패킷의 스트림 ID와 오프셋을 사용하여 전송된 데이터를 올바른 순서로 조립합니다. 패킷 번호는 보내는 순서만 결정할 뿐, 패킷을 어떻게 조립해야 하는지는 결정하지 않습니다.
• 수신기에서의 데이터 조립은 전송 순서와 무관하므로, 손실되거나 지연된 패킷은 연결된 모든 스트림이 아닌 패킷에 포함된 개별 스트림에만 영향을 미칩니다. 스트림이 전송 계층의 일부가 아니기 때문에 HTTP/ 1.x 및 HTTP/2에 영향을 미치는 HOL(Head-of-Line) 차단 문제가 해결됩니다.

손실 감지에 대한 완전한 설명은 이 입문서의 범위를 벗어납니다. 시간 초과를 결정하는 메커니즘과 전송 중에 허용되는 승인되지 않은 데이터의 양에 대한 자세한 내용은 RFC 9002 , QUIC 손실 감지 및 혼잡 제어를 참조하세요.

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

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

QUIC는 발생할 수 있는 중단을 줄이기 위한 두 가지 메커니즘을 제공합니다. 클라이언트는 서버에 주소가 변경될 것임을 사전에 알릴 수 있으며, 서버는 클라이언트 주소의 계획되지 않은 변경을 우아하게 처리할 수 있습니다. 연결 ID는 전환 중에도 일관되게 유지되므로 확인되지 않은 프레임은 새 IP 주소로 다시 전송될 수 있습니다.

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

암호화

연결 설정 에서 우리는 초기 QUIC 핸드셰이크가 단순히 연결을 설정하는 것 이상의 역할을 한다는 사실을 암시했습니다. TCP의 TLS 핸드셰이크와 달리 UDP의 경우 키와 TLS 1.3 암호화 매개변수 교환이 초기 연결의 일부로 이루어집니다. 이 기능을 사용하면 여러 번의 교환이 필요 없으며 클라이언트가 이전 연결을 재개할 때 왕복 시간(0‑RTT)이 0이 됩니다.

QUIC는 암호화 핸드셰이크를 연결 설정 프로세스에 포함하는 것 외에도 TCP+TLS보다 더 많은 양의 메타데이터를 암호화합니다. 키 교환이 발생하기 전에도 초기 연결 패킷은 암호화됩니다. 도청자는 여전히 키를 파생시킬 수 있지만 암호화되지 않은 패킷보다 더 많은 노력이 필요합니다. 이를 통해 공격자와 잠재적인 국가 검열자 모두에게 중요한 서버 이름 표시기(SNI)와 같은 데이터를 더 효과적으로 보호할 수 있습니다. 그림 5는 QUIC가 TCP+TLS보다 잠재적으로 더 민감한 메타데이터(빨간색)를 암호화하는 방식을 보여줍니다.

QUIC 페이로드의 모든 데이터는 TLS 1.3을 사용하여 암호화됩니다. 두 가지 장점이 있습니다. 오래되고 취약한 암호 그룹과 해싱 알고리즘이 허용되지 않으며 FS(Forward Secrecy) 키 교환 메커니즘이 필수입니다. 전방 비밀성은 공격자가 개인 키와 트래픽 사본을 획득하더라도 공격자가 데이터를 해독하는 것을 방지합니다.

낮음 및 0 RTT 연결로 대기 시간 단축

애플리케이션 데이터를 전송하기 전에 클라이언트와 서버 간에 발생해야 하는 왕복 횟수를 줄이면 애플리케이션 성능이 향상되며, 특히 지연 시간이 긴 네트워크에서 성능이 향상됩니다.

TLS 1.3은 암호화된 연결을 설정하기 위해 단일 왕복을 도입했으며 연결을 재개하기 위해 왕복을 0으로 설정했지만 TCP의 경우 TLS 클라이언트 Hello 전에 핸드셰이크가 발생해야 함을 의미합니다.

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

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

안타깝게도 0‑RTT 연결 재개는 전방 비밀성을 제공하지 않으므로 초기 클라이언트 요청은 교환에서 다른 트래픽만큼 안전하게 암호화되지 않습니다. 첫 번째 요청 이후의 요청과 응답은 전방 비밀 유지를 통해 보호됩니다. 더욱 문제가 되는 점은 초기 요청이 재생 공격 에도 취약하다는 것입니다. 즉, 공격자가 초기 요청을 캡처하여 서버에 여러 번 재생할 수 있습니다.

많은 애플리케이션과 웹사이트의 경우 0‑RTT 연결 재개로 인한 성능 개선은 이러한 잠재적 취약성보다 더 크지만, 이는 사용자가 스스로 결정해야 할 사항입니다.

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

Alt-Svc 헤더를 사용하여 HTTP/1.1에서 HTTP/3으로 이동

거의 모든 클라이언트(특히 브라우저)는 TCP/TLS를 통해 초기 연결을 만듭니다. 서버가 QUIC+HTTP/3를 지원하는 경우 Alt-Svc 헤더에 h3 매개변수를 포함하는 HTTP/1.1 응답을 반환하여 클라이언트에 해당 사실을 알립니다. 그런 다음 클라이언트는 QUIC+HTTP/3를 사용할지 아니면 이전 버전의 HTTP를 고수할지 선택합니다. (흥미로운 점으로, RFC 7838 에 정의된 Alt-Svc 헤더는 QUIC보다 먼저 나왔으며 다른 목적으로도 사용될 수 있습니다.)

Alt-Svc 헤더는 클라이언트에게 동일한 서비스가 대체 호스트, 프로토콜 또는 포트(또는 이들의 조합)에서 사용할 수 있음을 알려줍니다. 또한, 클라이언트는 이 서비스가 얼마나 오랫동안 제공될 것으로 가정해도 안전한지에 대한 정보를 받을 수 있습니다.

몇 가지 예:

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

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

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

결론

이 블로그에서는 QUIC에 대한 간단한 입문서를 제공하고, QUIC에서 사용되는 주요 네트워킹 및 암호화 작업을 이해하는 데 충분한 개요를 제공합니다.

NGINX를 QUIC + HTTP/3에 맞게 구성하는 것에 대한 보다 포괄적인 내용을 알아보려면 블로그에서 NGINX QUIC+HTTP/3 미리 보기 구현을 위한 바이너리 패키지가 출시되었음을 읽어보거나 NGINX 및 QUIC+HTTP/3를 직접 사용해 보세요라는 웨비나를 시청해 보세요 . QUIC+HTTP/3에 대한 모든 NGINX 지침에 대한 세부 정보와 사전 빌드된 바이너리를 설치하거나 소스에서 빌드하는 방법에 대한 전체 지침은 NGINX QUIC 웹페이지를 참조하세요.