목차
QUIC란 무엇인가?
QUIC(Quick UDP Internet Connections)는 인터넷 연결 속도, 신뢰성 및 보안을 개선하는 최신 전송 프로토콜입니다. UDP를 기반으로 구축된 QUIC은 연결 설정 대기 시간을 최소화하고 전송 제어 프로토콜(TCP)의 주요 제한 사항인 HOL 블로킹을 제거합니다. 이는 HTTP/3의 기본 전송 프로토콜로서 다양한 네트워크 조건에서 더 빠른 데이터 전달과 더 안정적인 성능을 가능하게 합니다.
원래 Google에서 개발되고 이후 IETF에서 표준화된 QUIC은 현재 웹 통신의 증가하는 부분을 지원합니다. W3Techs에 따르면, QUIC은 전체 웹사이트의 8.9%에서 사용되며, HTTP/3 도입율은 38.7%에 도달했습니다.
아래 섹션에서는 QUIC의 작동 방식, 중요한 이유 및 사용되는 위치를 설명합니다.
QUIC은 어떻게 작동하나요?
QUIC 프로토콜을 이해하는 한 가지 방법은 네트워크 프로토콜 스택에서 UDP를 통해 전송 계층에서 작동하는 HTTP/2 + TLS + UDP로 생각하는 것입니다.
핵심적으로, QUIC은 전송 계층으로 UDP 프로토콜을 사용하여 TCP 프로토콜보다 낮은 대기 시간과 높은 처리량을 제공하면서 TCP 연결을 방해하는 네트워크 미들박스를 우회합니다.
QUIC은 전송 계층 보안(TLS 1.3)을 통합하여 엔드포인트 간에 암호화된 TLS 연결을 설정함으로써 이전 버전(TLS 1.2)보다 성능과 보안을 개선하여 제3자가 트래픽을 가로채거나 조작하기 훨씬 더 어렵게 만듭니다.
UDP의 효율성, TLS의 보안 및 상위 계층에서 HTTP/2의 다중화 기능을 결합함으로써 QUIC은 오늘날의 인터넷 통신을 위한 고성능 전송을 제공합니다.
QUIC이 TCP보다 나은 이유는 무엇인가?
기존의 TCP 기반 프로토콜은 특히 대기 시간, 유연성 및 신뢰성 측면에서 현대 네트워크 환경의 한계에 직면합니다.
QUIC은 몇 가지 주요 개선 사항을 통해 이러한 과제를 해결합니다:
1. 빠른 핸드셰이크 및 연결 설정
TCP 및 TLS 핸드셰이크는 여러 번의 왕복이 필요하여 연결 설정에 눈에 띄는 지연이 발생합니다.
QUIC은 전송 계층에서 UDP 프로토콜을 사용하고 TLS 1.3을 핸드셰이크 프로세스에 직접 통합하여 이 오버헤드를 줄입니다.
1-RTT 연결 설정을 지원하고 캐시된 세션 키를 사용하여 재방문 클라이언트를 위한 0-RTT 재개를 가능하게 합니다. 결과적으로 클라이언트는 요청 시작 후 훨씬 더 일찍 데이터를 보낼 수 있어 최신 웹 애플리케이션의 성능을 개선합니다.
2. 인증 및 암호화된 패킷
TCP 프로토콜 헤더는 암호화되거나 인증되지 않아 변조, 주입 및 도청 중개자에게 취약합니다.
반면에 QUIC 패킷은 보안을 위해 강력하게 보호됩니다. 초기 핸드셰이크 중에 사용되는 소수의 보호되지 않는 패킷(초기 및 재시도 패킷 등)을 제외하고 모든 메시지 본문은 암호화됩니다. 따라서 QUIC 패킷의 수정은 수신 측에서 신속하게 감지되어 보안 위험을 효과적으로 줄일 수 있습니다.
아래 그림에서 보라색 콘텐츠는 스트림 프레임 패킷의 인증된 헤더이고 노란색 부분은 암호화된 데이터입니다:
3. HOL 블로킹을 피하기 위한 다중화 개선
TCP 연결에서 HOL 블로킹은 단일 패킷이 손실될 때 모든 스트림을 지연시킬 수 있습니다.
HTTP/2에서는 여러 데이터 스트림이 단일 TCP 연결을 공유하며 순서대로 전달되어야 합니다. 패킷이 손실되면 다른 스트림이 이미 도착했더라도 누락된 패킷이 재전송될 때까지 후속 데이터를 처리할 수 없습니다.
QUIC은 전송 계층에서 다중화를 도입하여 각 스트림이 UDP를 통해 독립적으로 작동하도록 함으로써, 웹 서버가 여러 동시 연결을 효율적으로 처리할 수 있도록 돕고 전체 연결에 영향을 미치는 HOL 블로킹 문제를 해결합니다.
예를 들어, 아래 그림의 스트림 1에서 패킷 손실이 발생하면 해당 스트림만 영향을 받고 다른 스트림(스트림 2 및 3)은 중단 없이 데이터 전송을 계속합니다.
또한, HPACK 헤더 압축의 변형인 QPACK은 중복 데이터 전송을 줄이고 불안정한 네트워크 조건에서 성능을 더욱 향상시킵니다.
4. 플러그 가능한 혼잡 제어
기존 네트워크 스택에서 혼잡 제어는 운영 체제의 TCP 구현과 밀접하게 결합되어 있어 업데이트나 사용자 정의가 어렵습니다.
QUIC은 Cubic, BBR, Reno와 같은 플러그 가능한 혼잡 제어 알고리즘과 특정 시나리오를 위한 사용자 정의 알고리즘을 지원합니다. QUIC은 일반적으로 사용자 공간에 배포되므로 이러한 알고리즘은 운영 체제나 커널 지원 없이 애플리케이션 계층에서 구현할 수 있습니다.
동일한 애플리케이션 내의 다른 연결은 다른 혼잡 제어 전략을 사용할 수 있으며, 업데이트는 시스템 업그레이드나 서비스 중단 없이 적용할 수 있습니다.
5. 연결 마이그레이션
TCP 연결은 소스 IP, 소스 포트, 대상 IP, 대상 포트의 4개 요소로 구성된 튜플을 기반으로 합니다. 이러한 값 중 하나라도 변경되면 연결이 끊어집니다.
그러나 QUIC 연결은 가변 길이 연결 ID를 기반으로 합니다. 연결 ID가 동일하게 유지되는 한 연결은 끊어짐 없이 지속되며 재연결이 필요하지 않습니다.
예를 들어, 클라이언트가 IP1을 사용하여 패킷 1과 2를 보낸 다음 네트워크를 전환하여 IP2로 변경하고 패킷 3과 4를 보내는 경우, 서버는 패킷 헤더의 연결 ID 필드를 기반으로 네 패킷 모두 동일한 클라이언트에서 왔음을 인식할 수 있습니다.
QUIC은 기본 UDP가 비연결형이기 때문에 연결 마이그레이션을 달성할 수 있습니다.
6. FEC
패킷 손실은 특히 불안정한 네트워크 환경에서 성능에 큰 영향을 미칠 수 있습니다.
QUIC은 FEC를 지원하여 수신자가 중복 패킷을 사용하여 손실된 데이터를 복구할 수 있도록 하여 재전송 필요성을 줄이고 열악한 네트워크 조건에서 신뢰성을 향상시킵니다.
7. 지속적인 진화를 위한 버전 관리
TCP와 같은 전송 프로토콜은 업데이트가 종종 운영 체제 변경에 의존하기 때문에 진화하기 어렵습니다.
QUIC은 내장된 버전 관리를 도입하여 여러 프로토콜 버전이 공존할 수 있도록 하고 기존 연결을 중단하지 않고 점진적인 업그레이드를 가능하게 합니다.
8. 사용자 정의 프레임을 통한 확장성
QUIC은 또한 확장 프레임을 지원하여 핵심 프로토콜을 수정하지 않고도 새로운 기능을 도입할 수 있습니다. 확장은 표준화되거나 특정 시나리오를 위해 비공개로 사용될 수 있어 상호 운용성을 유지하면서 프로토콜 수준의 혁신을 가능하게 합니다.
QUIC과 HTTP/3은 현재 어디에 사용되나요?
HTTP/3과 QUIC의 채택이 널리 퍼짐에 따라 대기 시간, 신뢰성 및 연결 안정성 측면에서의 이점은 다양한 네트워크 환경에서 증가하는 사용 사례를 가능하게 하고 있습니다.
실시간 통신 및 스트리밍
HTTP/3과 QUIC은 낮은 대기 시간과 안정적인 연결이 중요한 화상 회의, 온라인 게임, 라이브 스트리밍과 같은 실시간 통신 및 스트리밍에 매우 적합합니다.
QUIC의 연결 마이그레이션과 열악한 네트워크 조건에서의 개선된 성능은 시작 지연, 버퍼링 및 요청 실패를 줄이는 데 도움이 됩니다.
IoT
IoT 환경에서 장치는 고속 이동, 해양 작업, 산악 지형과 같이 불안정하고 자원이 제한된 조건에서 작동하는 경우가 많습니다. MQTT와 같은 TCP 기반 프로토콜은 빈번한 재연결과 더 높은 오버헤드로 어려움을 겪을 수 있습니다.
QUIC은 더 빠른 연결 설정과 신뢰할 수 없는 네트워크에서의 향상된 성능으로 효율성을 개선하여 중단과 전송 비용을 줄입니다.
클라우드 컴퓨팅
더 많은 서비스가 클라우드로 이동함에 따라 효율적이고 안정적인 클라이언트-서버 통신이 점점 더 중요해지고 있습니다. QUIC은 다중화된 스트림과 더 빠른 연결 설정을 지원하여 분산 애플리케이션의 응답성을 개선함으로써 클라우드 성능을 향상시킵니다.
전자상거래 및 디지털 결제
전자상거래 및 결제 시스템의 경우 성능과 신뢰성은 사용자 경험과 거래 성공에 직접적인 영향을 미칩니다. QUIC은 더 빠른 페이지 로드, 트래픽 피크 시간대의 더 안정적인 연결 및 중요한 작업을 위한 안전한 데이터 전송을 보장하는 데 도움이 됩니다.
CDNetworks, 완전한 QUIC 프로토콜 지원 제공
CDNetworks는 QUIC 프로토콜의 잠재력을 일찍 인식하고 그 개발을 선도했습니다.
CDNetworks는 전체 플랫폼에서 HTTP/3 및 QUIC을 지원하며, 모든 버전의 gQUIC(Google QUIC)과 표준화된 iQUIC(IETF QUIC)을 지원하도록 완전히 업그레이드되었습니다.
내부적으로 CDNetworks는 플랫폼의 프레임 처리 용량을 개선하고 플랫폼 성능을 최적화하여 리소스 소비를 줄였습니다.
내부 벤치마킹에 따르면 1Mbps의 QUIC 스트림 풀 시나리오에서 동일한 동시성 조건에서 대역폭 성능이 41% 향상된 반면 평균 CPU 사용량은 28% 감소했습니다.
특히 미디어 전송의 경우, CDNetworks는 QUIC의 재전송 효율성과 속도 샘플링 정확도를 개선하기 위해 광범위한 최적화를 수행했습니다. 또한 UDP 패킷 전송 및 GSO 전략을 개선하여 열악한 지역 간 네트워크 조건에서 불안정한 비디오 품질 문제를 효과적으로 해결했습니다.
라이브 스트리밍 풀 시나리오에서 QUIC과 TCP를 통한 비디오 재생을 비교한 내부 테스트를 기반으로 다음과 같은 주요 결과가 관찰되었습니다:
- 네트워크 손실 상태에서의 비트레이트 안정성
안정적인 네트워크에서 QUIC과 TCP는 유사하게 작동합니다. 20% 패킷 손실 상태에서 QUIC은 안정적인 코드율을 유지하는 반면 TCP 성능은 크게 저하됩니다.
- 다양한 네트워크 조건에서의 재생 부드러움
패킷 손실이 없는 환경에서는 QUIC이 애플리케이션 계층의 추가 암호화 오버헤드로 인해 약간 낮은 부드러움을 보여줍니다. 그러나 패킷 손실 조건에서는 QUIC이 TCP보다 훨씬 우수한 성능을 보입니다.
- 패킷 손실 조건에서의 TTFB
QUIC은 20% 패킷 손실 상태에서 일관된 최초 바이트 대기 시간을 유지하는 반면 TCP는 눈에 띄는 지연을 경험합니다.
CDNetworks가 가장 빠른 QUIC 스트리밍으로 어떻게 도움을 줄 수 있는지 자세히 알아보려면 저희에게 문의하거나 무료 평가판을 위해 여기를 클릭하십시오.
QUIC FAQ
어떤 앱이 QUIC을 사용하나요?
Chrome, YouTube, Gmail, Google Maps, Facebook과 같은 많은 웹 브라우저가 모두 QUIC을 사용합니다. 많은 스트리밍 플랫폼과 클라우드 서비스도 QUIC을 채택하고 있습니다.
QUIC을 차단해야 하나요?
QUIC 차단은 심층 트래픽 검사가 필요한 기업에 적합하지만 사용자 경험을 저하시키고 콘텐츠 전송 속도를 늦출 수 있습니다.
QUIC이 TLS 프로토콜을 대체하나요?
QUIC은 TLS 1.3을 자체 프로토콜에 직접 통합하여 보안 표준으로서 TLS를 대체하기보다는 향상시킵니다.
QUIC이 보안 우려가 될 수 있는 이유는 무엇인가요?
암호화된 UDP 트래픽은 레거시 방화벽의 가시성을 제한하고 트래픽 검사를 복잡하게 만들 수 있습니다.