NGINX의 QUIC 네트워킹 및 암호화 가이드

여러분과 마찬가지로 저희도 이제 곧 QUIC 구현이 NGINX 오픈 소스 메인스트림 브랜치에 통합되기를 간절히 기대하고 있습니다. 오랜 기간의 준비 기간을 감안할 때, QUIC에 대해 많이 생각해보지 않으셨다면 충분히 이해하실 수 있습니다.

그러나 이 시점에서 개발자 또는 사이트 관리자는 QUIC이 일부 네트워킹 세부 사항에 대한 책임을 운영체제에서 NGINX(및 모든 HTTP 앱)로 어떻게 이전하는지 알고 있어야 합니다. 네트워킹에 익숙하지 않더라도 QUIC을 도입하면 네트워크에 대한 걱정을 조금이라도 덜 수 있습니다.

이 포스트에서는 명확성을 추구하기 위해 일부 세부 사항을 간소화하고 필수적이지 않은 정보는 생략한 채 QUIC에 사용되는 주요 네트워킹 및 암호화 개념을 자세히 살펴봅니다. 이 과정에서 약간의 뉘앙스가 사라질 수도 있지만, 트위터의 의도는 사용자가 자신의 환경에 QUIC을 효과적으로 도입할 수 있도록 충분한 정보를 제공하거나 최소한 지식을 쌓을 수 있는 토대를 제공하는 것입니다.

QUIC에 대한 보다 상세하고 완전한 설명을 보시려면 이 문서 전체에 링크된 추가 자료와 함께 IETC QUIC 워킹 그룹에서 작성한 ‘QUIC 전송 프로토콜의 우수한 관리 가능성‘ 문서를 참고하시기 바랍니다.

목차

1. QUIC에서 네트워킹과 암호화에 관심을 가져야 하는 이유는 무엇인가요?
2. TCP와 UDP 비교
3. 단순화된 QUIC 네트워크 분석
4. 연결 설정
5. QUIC 손실 감지
6. 클라이언트 IP 주소 변경을 유연하게 관리하기
7. 암호화
8. Low 및 Zero-RTT 연결로 지연 시간 단축
9. Alt-Svc 헤더를 사용하여 HTTP/1.1에서 HTTP/3으로 이동하기
10. 결론

1. QUIC 에서 네트워킹과 암호화에 관심을 가져야 하는 이유는 무엇인가요?

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

그러나 QUIC을 사용하면 연결 생성, 유효성 검사 및 관리에 대한 책임이 기본 운영체제에서 NGINX로 이동합니다. 이제 NGINX는 설정된 TCP 연결을 받는 대신 User Datagram Protocol(UDP) 데이터그램 스트림을 받아 클라이언트 연결과 스트림으로 파싱해야 합니다. 이제 패킷 손실, 연결 재시작, 혼잡 제어도 NGINX가 처리합니다.

또한 QUIC은 연결 시작, 버전 협상 및 암호화 key 교환을 단일 연결 설정 작업으로 결합합니다. 그리고 TLS 암호화는 QUIC+HTTP/3과 TCP+HTTP/1+2 모두에서 대체로 유사한 방식으로 처리되지만, Layer 4 로드 밸런서, 방화벽, 보안 어플라이언스와 같은 다운스트림 디바이스에는 중요한 차이점이 있을 수 있습니다.

궁극적으로 이러한 변경 사항의 전반적인 효과는 사용자에게 더 안전하고, 더 빠르고, 저 안정적인 환경을 제공하는 것이며, NGINX 구성이나 운영에는 거의 변화가 없습니다. 하지만 문제 발생 시 평균 무고장 시간을 최대한 짧게 유지하기 위해서라도 NGINX 관리자는 QUIC 및 NGINX에서 어떤 일이 일어나고 있는지 최소한 어느 정도는 이해해야 합니다.

(이 글에서는 HTTP/3에 QUIC이 필요하기 때문에 HTTP 작업에 초점을 맞추고 있지만, QUIC은 다른 프로토콜에도 사용될 수 있다는 점에 주목할 가치가 있습니다. 좋은 예로 RFC 9250, DNS를 통한 전용 QUIC 연결에 정의된 DNS over QUIC을 들 수 있습니다.)

소개를 마치고 이제 QUIC 네트워킹에 대해 자세히 알아보겠습니다.

2. TCP와 UDP 비교

QUIC은 클라이언트와 서버 간에 HTTP 애플리케이션 데이터를 전송하는 데 사용되는 기본 네트워크 프로토콜에 중요한 변경 사항을 도입했습니다.

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

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

또 다른 문제는 많은 시나리오에서 클라이언트와 서버 간의 HTTP 트래픽이 방화벽이나 로드 밸런서(통칭 “미들박스”라고 함)와 같은 여러 TCP 처리 디바이스를 통과하기 때문에 TCP 표준 변경 사항을 구현하는 속도가 느릴 수 있다는 점입니다.

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

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

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

3. 단순화된 QUIC 네트워크 분석

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

사진 1: QUIC 스트림 분석

외부에서 시작하는 논리적 계층과 객체가 있습니다:

• UDP 데이터그램 – 원본 및 대상 포트를 지정하는 헤더(길이 및 체크섬 데이터와 함께)와 하나 이상의 QUIC 패킷이 포함됩니다. 데이터그램은 네트워크를 통해 클라이언트에서 서버로 전송되는 정보의 단위입니다.
• QUIC 패킷 – 하나의 QUIC 헤더와 하나 이상의 QUIC 프레임을 포함합니다.
• QUIC 헤더 – 패킷에 대한 메타데이터를 포함합니다. 헤더에는 두 가지 유형이 있습니다.
  • 연결 설정 중에 사용되는 긴 헤더입니다.
  • 짧은 헤더는 연결이 설정된 후에 사용됩니다. 여기에는 연결 ID, 패킷 번호, key 단계(key 로테이션을 지원하기 위해 패킷을 암호화하는 데 사용된 key를 추적하는 데 사용됨)가 포함됩니다. 패킷 번호는 특정 연결 및 key 단계에 대해 고유하며 항상 증가합니다.
• 프레임 – 유형, 스트림 ID, 오프셋 및 스트림 데이터를 포함합니다. 스트림 데이터는 여러 프레임에 걸쳐 분산되어 있지만 연결ID, 스트림 ID, 오프셋을 사용하여 데이터 청크를 올바른 순서로 표시하는데 사용되는 연결 ID, 스트림 ID, 오프셋을 조합할 수 있습니다.
• 스트림 – 단일 QUIC 연결 내의 단방향 또는 양방향 데이터 흐름입니다. 각 QUIC 연결을 각각 고유한 스트림 ID를 가진 여러 개의 독립 스트림을 지원할 수 있습니다. 일부 스트림이 포함된 QUIC 패킷이 손실되더라도 손실된 패킷에 포함되지 않은 스트림의 진행에는 영향을 미치지 않습니다(이는 HTTP/2에서 발생하는 head-of-line blocking을 피하는 데 중요합니다). 스트림은 양방향이 될 수 있으며, 양쪽 엔드포인트에서 생성할 수 있습니다.

4. 연결 설정

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

사진 2: TCP 연결을 설정하는 3방향 핸드셰이크

QUIC 연결을 설정하는 단계는 비슷하지만, 더 효율적입니다. 또한 암호화 핸드셰이크의 일부로 연결 설정에 주소 유효성 검사를 구축합니다. 주소 유효성 검사는 악의적인 공격자가 의도한 공격 대상의 스푸핑 된 Source IP 정보가 포함된 패킷을 서버로 전송하는 트래픽 증폭 공격을 방어합니다. 공격자는 서버가 공격자가 자체적으로 생성할 수 있는 것보다 더 많은 또는 큰 패킷을 피해자에게 생성하여 압도적인 양의 트래픽을 발생시키기를 희망합니다. (자세한 내용은 RFC 9000의 섹션 8, QUIC:UDP 기반 다중화 및 보안 전송을 참조하세요.)

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

그러나 QUIC 연결의 초기 설정에는 TLS 암호화 key 교환 작업도 포함되므로 서버는 TCP 연결을 설정하는 동안 생성하는 단순한 SYN-ACK 응답보다 계산 비용이 더 많이 듭니다. 또한 key 교환 작업이 수행되기 전에 클라이언트 IP 주소의 유효성이 검사되지 않기 때문에 DDoS 공격의 잠재적 벡터가 될 수 있습니다.

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

사진 3: 재시도 패킷 유무에 따른 QUIC 연결 설정

이 메커니즘은 3자 TCP 핸드셰이크와 비슷하며, 중요한 것은 클라이언트가 제시하는 source IP 주소를 소유하고 있는지 확인하는 것입니다. 이 확인 기능이 없으면 NGINX와 같은 QUIC 서버는 스푸핑 된 source IP 주소를 사용하는 쉬운 DoS 공격에 취약할 수 있습니다. (이러한 공격을 완화하는 또 다른 QUIC 메커니즘은 모든 초기 연결 패킷을 최소 1200Byte로 패딩해야 한다는 요구 사항으로, 패킷을 전송하는 데 더 많은 비용이 듭니다.)

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

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

5. QUIC 손실 감지

연결이 설정되면(아래에서 자세히 설명하는 암호화가 활성화됨) 클라이언트와 NGINX 간에 HTTP 요청과 응답이 오갈 수 있습니다. UDP 데이터그램이 송수신됩니다. 그러나 이러한 데이터그램 중 일부가 손실되거나 지연될 수 있는 요인이 많이 있습니다.

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

• 클라이언트와 서버 모두 수신하는 각 QUIC 패킷에 대해 명시적인 승인을 보냅니다(우선순위가 낮은 프레임만 포함된 패킷은 즉시 승인되지 않음).
• 안정적인 전송이 필요한 프레임이 포함된 패킷이 설정된 시간 초과 기간이 지나도 승인되지 않으면 손실된 것으로 간주됩니다.
  
  시간 초과 기간은 패킷의 내용에 따라 달라집니다. 예를 들어, 암호화 설정 및 연결 설정에 필요한 패킷의 경우 QUIC 핸드셰이크 성능에 필수적이므로 시간 초과 기간이 더 짧습니다.
• 패킷이 손실된 것으로 간주되면 누락된 프레임은 새 시퀀스 번호가 있는 새 패킷으로 재전송됩니다.
• 패킷 수신자는 패킷의 스트림 ID와 오프셋을 사용하여 전송된 데이터를 올바른 순서로 조합합니다. 패킷 번호는 전송 순서만 지정할 뿐 패킷을 조립하는 방법은 지정하지 않습니다.
• 수신기에서의 데이터 조립은 전송 순서와 무관하므로 패킷이 손실되거나 지연되면 연결의 모든 스트림이 아니라 패킷에 포함된 개별 스트림에만 영향을 미칩니다. 따라서 스트림이 전송 계층의 일부가 아니기 때문에 HTTP/1.x 및 HTTP/2에 영향을 미치는 head-of-line blocking 문제가 발생하지 않습니다.

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

6. 클라이언트 IP 주소 변경을 유연하게 관리하기

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

QUIC은 클라이언트가 서버에 주소가 변경될 것임을 사전에 알리고, 서버는 클라이언트 주소의 예기치 않은 변경을 정상적으로 처리할 수 있는 두 가지 메커니즘을 제공하여 이로 인해 발생할 수 있는 중단을 줄입니다. 연결 ID는 전환하는 동안 일관되게 유지되므로 승인되지 않은 프레임은 새 IP 주소로 재전송될 수 있습니다.

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

7. 암호화

연결 설정에서 초기 QUIC 핸드셰이크가 단순히 연결을 설정하는 것 이상의 역할을 한다는 사실을 언급했습니다. TCP의 TLS 핸드셰이크와 달리, UDP에서는 초기 연결의 일부로 key와 TLS 1.3 암호화 매개변수의 교환이 이루어집니다. 이 기능은 여러 번의 교환을 없애고 클라이언트가 이전 연결을 재개할 때 0-RTT(zero round-trip tip)를 가능하게 합니다.

사진 4: TCP+TLS/1.3과 QUIC의 암호화 핸드셰이크 비교

QUIC은 연결 설정 프로세스에 암호화 핸드셰이크를 포함할 뿐만 아니라, TCP+TLS보다 더 많은 양의 메타데이터를 암호화합니다. Key 교환이 이루어지기 전에도 초기 연결 패킷이 암호화되므로 도청자가 key를 알아낼 수는 있지만 암호화되지 않은 패킷보다 더 많은 노력이 필요합니다. 이렇게 하면 공격자와 잠재적인 국가 수준의 검열자 모두와 관련된 서버 이름 표시기(SNI)와 같은 데이터를 더 잘 보호할 수 있습니다. 사진 5는 QUIC이 잠재적으로 민감한 메타데이터(빨간색)를 TCP+TLS보다 더 많이 암호화하는 방법을 보여줍니다.

사진 5: QUIC는 TCL+TLS보다 더 민감한 메타데이터를 암호화합니다.

QUIC 페이로드의 모든 데이터는 TLS 1.3을 사용하여 암호화됩니다. 두 가지 장점이 있습니다. 오래되고 취약한 암호 제품군과 해싱 알고리즘은 허용되지 않으며, Forward secrecy(FS) key 교환 메커니즘이 필수입니다. 순방향 비밀성은 공격자가 key와 트래픽 사본을 캡처하더라도 데이터를 해독할 수 없도록 합니다.

8. Low 및 Zero-RTT 연결로 지연 시간 단축

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

TLS 1.3에서는 암호화된 연결을 설정하기 위해 한 번의 왕복이 필요하고 연결을 재개하기 위해 0번의 왕복을 도입했습니다. 그러나 TCP에서는 TLS 클라이언트 Hello 전에 핸드셰이크가 발생해야 합니다.

QUIC은 암호화 작업과 연결 설정을 결합하기 때문에 클라이언트가 첫 번째 QUIC 패킷에서 요청을 보낼 수 있는 진정한 0-RTT 연결 재설정을 제공합니다. 이렇게 하면 첫 번째 요청 전에 연결 설정을 위한 초기 라운드 트립을 제거하여 지연 시간을 줄일 수 있습니다.

사진 6: TCP+TLS와 QUIC으로 연결을 재설정하는 데 필요한 메시지 비교

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

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

많은 애플리케이션과 웹사이트의 경우 0-RTT 연결 재개를 통한 성능 향상이 이러한 잠재적 취약성보다 더 크지만, 이는 사용자가 직접 결정해야 하는 문제입니다.

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

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

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

그림 7: Alt-Svc 헤더가 HTTP/1.1에서 HTTP/3로 연결을 변환

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

몇 가지 예를 들면 다음과 같습니다:

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

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

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

10. 결론

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

QUIC + HTTP/3용 NGINX 구성에 대한 보다 포괄적인 내용은 NGINX STORE에서 NGINX QUIC+HTTP/3 구현을 위한 바이너리 패키지를 읽어보세요.

NGINX Plus를 직접 사용해 보시려면 30일 무료 평가판을 신청하거나 NGINX STORE에 연락하여 문의하십시오.

NGINX에 대한 최신 정보들을 빠르게 전달받고 싶으시다면, 아래의 뉴스레터를 구독하세요.