QUIC이란 무엇입니까? HTTP/3를 어떻게 향상합니까?

2023년 3월 7일

무료로 씨디네트웍스를 이용해보세요

지금 바로 신청하면, 씨디네트웍스의 다양한 솔루션을 한 달간 무료로 체험하실 수 있습니다.

이 게시물 공유하기

QUIC이란 무엇입니까?

HTTP/3와 그 이후로 가장 뛰어난 최신 버전의 HTTP 프로토콜을 사용하여 인터넷의 미래에 대비하십시오. HTTP3가 이미 등장하면서 웹 사이트 소유자와 인터넷 사용자 모두 이제 이전보다 더 빠르고 안정적이며 안전한 온라인 경험을 기대할 수 있습니다. 이는 모두 QUIC(빠른 UDP 인터넷 연결)로 알려진 혁신적인 새 전송 프로토콜 기반 덕분입니다.

2021년 5월에 IETF는 RFC 9000 에서 QUIC를 표준화했으며 RFC 8999 , RFC 9001 및 RFC 9002 에서 지원합니다. 그런 다음 2022년 6월 7일에 IETF는 RFC 9114 에서 QUIC 기반 HTTP/3 을 제안된 표준 으로 공식 발표했습니다.

현재 QUIC의 배치는 전 세계적으로 가속화되고 있습니다. QUIC IETF-v1 프로토콜 표준이 등장하면서 점점 더 많은 웹사이트에서 QUIC 트래픽을 사용하기 시작했습니다. W3Techs 의 통계에 따르면 현재 약 25.5%의 웹사이트가 HTTP/3를 사용하고 있습니다.
씨디네트웍스는 네트워크 분야의 선구자로서 QUIC 프로토콜의 포괄적인 지원을 완성하는 데 앞장서 왔습니다. 아래 표는 씨디네트웍스가 지원하는 현재 QUIC 버전을 보여줍니다.

어떻게 작동합니까?

한 측면에서 설명하면 QUIC = HTTP/2 + TLS + UDP인 반면 UDP + QUIC = 전송 계층입니다.

QUIC은 UDP를 전송 프로토콜로 채택하여 TCP보다 대기 시간이 짧고 처리량이 높으며 TCP를 방해할 수 있는 네트워크 미들박스를 우회할 수 있습니다. QUIC에는 TLS 1.3 기반의 내장 암호화 프로토콜이 포함되어 있어 엔드포인트 간에 보안 통신을 제공하고 제3자가 인터넷 트래픽을 가로채고 조작하는 것을 더 어렵게 만듭니다. SMB와 같은 프로토콜에서 약간의 명령과 버전 제어를 뿌린 다음 일련의 새로운 프로토콜 개념과 효율성을 혼합하여 QUIC이 등장합니다. UDP의 속도와 효율성, TLS의 보안, 다음 기능을 결합한 것입니다. 현대 인터넷을 위한 안정적인 고성능 전송 프로토콜을 만드는 HTTP/2.

QUIC이 중요한 이유는 무엇입니까?

QUIC이 출시되기 전에 TCP는 HTTP에서 데이터를 전송하기 위한 기본 프로토콜로 사용되었습니다. 그러나 모바일 인터넷이 지속적으로 발전함에 따라 실시간 상호 작용 및 보다 다양한 네트워크 시나리오에 대한 요구가 증가하고 있습니다. 또한 스마트폰과 휴대용 장치는 현재 60% 이상의 인터넷 트래픽이 무선으로 전송되면서 점차 주류가 되었습니다.

그러나 40년 이상 사용되어 온 전송 계층 통신 프로토콜인 기존 TCP는 대규모 장거리, 열악한 모바일 네트워크 및 충족할 수 없는 빈번한 네트워크 전환의 현재 상황에서 내재된 성능 병목 현상을 가지고 있습니다. 주로 다음 세 가지 이유로 인해 요구됩니다.

연결 설정 시 큰 핸드셰이크 지연

HTTP1.0/1.1이든 HTTPS, HTTP2이든 모두 전송에 TCP를 사용합니다. HTTPS 및 HTTP2도 보안 전송을 위해 TLS 프로토콜을 사용해야 합니다. 이로 인해 두 가지 핸드셰이크 지연이 발생합니다.

TCP 3방향 핸드셰이크로 인해 TCP 연결 설정이 지연됩니다.

완전한 TLS 핸드셰이크는 설정하는 데 최소 2 RTT가 필요하고 단순화된 핸드셰이크에는 1 RTT 핸드셰이크 지연이 필요합니다.

많은 짧은 연결 시나리오에서 이러한 핸드셰이크 지연은 상당한 영향을 미치며 제거할 수 없습니다.

HOL 차단

예를 들어 HTTP/2 다중화를 사용하면 여러 데이터 요청이 동일한 TCP 연결에서 서로 다른 스트림으로 전송되며 애플리케이션 계층의 모든 스트림이 순서대로 처리되어야 합니다. 스트림의 데이터가 손실되면 손실된 데이터가 재전송될 때까지 그 뒤에 있는 다른 스트림의 데이터가 차단되며 수신 측에서 이미 후속 스트림의 데이터 패킷을 수신한 경우에도 애플리케이션 계층에 알리지 않습니다. 이 문제를 TCP 스트림의 HoL(head-of-line blocking)이라고 합니다.

TCP 프로토콜에 대한 업데이트를 홍보하는 것은 쉽지 않습니다.

TCP 프로토콜은 원래 포트, 옵션 및 기능의 추가 및 수정을 지원하도록 설계되었습니다. 그러나 TCP 프로토콜의 오랜 역사와 잘 알려진 포트 및 옵션으로 인해 많은 미들박스(예: 방화벽 및 라우터)가 이러한 암시적 규칙에 의존하게 되었습니다. 결과적으로 프로토콜에 대한 변경 사항이 이러한 미들박스에서 제대로 지원되지 않아 상호 운용성 문제가 발생할 수 있습니다.

TCP 프로토콜은 운영 체제 커널에 구현되어 있지만 Windows XP와 같은 많은 오래된 시스템 플랫폼에는 여전히 많은 사용자가 있기 때문에 사용자 측 운영 체제 버전을 업그레이드하는 것은 매우 어렵습니다. 또한 TCP 사용자는 해당 기능에 익숙하며 동작에 잠재적으로 영향을 미칠 수 있는 변경 사항에 저항할 수 있습니다. 따라서 TCP 프로토콜에 대한 업데이트를 신속하게 홍보하는 것은 그리 쉬운 일이 아닙니다.

QUIC이 필요한 이유

QUIC의 등장으로 라스트 마일에서 네트워크 전송 문제가 해결되었습니다. QUIC의 주요 개선 사항은 다음과 같습니다.

빠른 핸드셰이크 및 연결 설정

QUIC은 두 가지 측면에서 최적화되었습니다.

전송 계층은 UDP를 사용하여 TCP 3방향 핸드셰이크에서 하나의 1-RTT 지연을 줄입니다.
최신 버전의 TLS 프로토콜 채택인 TLS 1.3은 클라이언트가 TLS 핸드셰이크가 완료되기 전에 애플리케이션 데이터를 보낼 수 있도록 하여 1-RTT 및 0-RTT를 모두 지원합니다. QUIC 프로토콜을 사용하면 첫 번째 핸드셰이크 협상에 1-RTT가 걸리지만 이전에 연결된 클라이언트는 캐시된 정보를 사용하여 0-1 RTT만으로 TLS 연결을 복원할 수 있습니다.

인증되고 암호화된 패킷

기존의 TCP 프로토콜 헤더는 암호화되거나 인증되지 않아 중개자에 의한 변조, 주입 및 도청에 취약합니다. 대조적으로 QUIC 패킷은 보안을 위해 강력하게 준비되어 있습니다. PUBLIC_RESET 및 CHLO와 같은 몇 가지 메시지를 제외하고 모든 패킷 헤더가 인증되고 모든 메시지 본문이 암호화됩니다. 이렇게 하면 수신 측에서 QUIC 패킷의 수정 사항을 즉시 감지하여 보안 위험을 효과적으로 줄일 수 있습니다.

아래 그림과 같이 보라색 내용은 스트림 프레임 패킷의 인증된 헤더이고 노란색 부분은 암호화된 내용입니다.

HoL 차단을 피하기 위해 멀티플렉싱 개선

QUIC은 연결에서 여러 스트림을 다중화하는 개념을 도입했습니다. QUIC은 각 스트림에 대해 별도의 흐름 제어를 설계하고 구현함으로써 전체 연결에 영향을 미치는 HOL(head-of-line) 차단 문제를 해결합니다.

QUIC의 다중화는 HTTP/2와 유사합니다. 단일 QUIC 연결에서 여러 HTTP 요청(스트림)을 동시에 보낼 수 있습니다. 그러나 QUIC의 멀티플렉싱이 HTTP/2를 능가하는 것은 단일 연결의 각 스트림 간에 순차적 종속성이 없다는 것입니다. 즉, 스트림 2에서 UDP 패킷이 손실되면 스트림 1 및 3에 대한 데이터 전송을 차단하지 않고 스트림 2의 처리에만 영향을 미칩니다. 결과적으로 이 솔루션은 HOL(Head-of-Line) 차단으로 이어지지 않습니다.

또한 QUIC의 새로운 기능인 QPACK이라는 HPACK 헤더 압축 형식의 변형은 네트워크를 통해 전송되는 중복 데이터의 양을 줄여 헤드 오브 라인 차단을 완화하도록 설계되었습니다. 이러한 방식으로 QUIC은 주간 네트워크 시나리오에서 TCP보다 더 많은 데이터를 수신할 수 있습니다.

플러그형 혼잡 제어

QUIC은 Cubic, BBR 및 Reno와 같은 플러그 가능한 혼잡 제어 알고리즘을 지원하거나 특정 시나리오를 기반으로 개인 알고리즘을 사용자 정의합니다. "플러그 가능"은 유연하게 적용, 변경 및 중지됨을 의미합니다. 다음과 같은 측면에서 반영됩니다.

운영 체제나 커널 지원 없이 응용 프로그램 계층에서 다양한 혼잡 제어 알고리즘을 구현할 수 있는 반면, 기존의 TCP 혼잡 제어는 제어 효과를 달성하기 위해 종단 간 네트워크 프로토콜 스택이 필요합니다.
서로 다른 혼잡 제어 구성을 지원하기 위해 단일 애플리케이션의 서로 다른 연결이 허용됩니다.
애플리케이션은 다운타임이나 업그레이드 없이 혼잡 제어를 변경할 수 있습니다. 우리가 하는 유일한 일은 구성을 수정하고 서버 측에서 다시 로드하는 것입니다.

연결 마이그레이션

TCP 연결은 소스 IP, 소스 포트, 대상 IP 및 대상 포트의 4튜플을 기반으로 합니다. 이러한 변경 사항이 있으면 연결을 다시 설정해야 합니다. 그러나 QUIC 연결은 64비트 연결 ID를 기반으로 하므로 연결 끊김과 재연결 없이 연결 ID가 동일하게 유지되는 한 연결을 유지할 수 있습니다.

예를 들어 클라이언트가 IP1을 사용하여 패킷 1과 2를 보낸 다음 네트워크를 전환하여 IP2로 변경하고 패킷 3과 4를 보내는 경우 서버는 패킷의 연결 ID 필드를 기반으로 4개의 패킷이 모두 동일한 클라이언트에서 온 것임을 인식할 수 있습니다. 머리글. QUIC이 연결 마이그레이션을 달성할 수 있는 근본적인 이유는 기본 UDP 프로토콜이 연결이 없기 때문입니다.

순방향 오류 수정(FEC)

QUIC은 또한 FEC(Forward Error Correction)를 지원하여 FEC 패킷을 동적으로 추가하여 열악한 네트워크 환경에서 재전송 횟수를 줄이고 전송 효율성을 높일 수 있습니다.

HTTP/3 및 QUIC은 더 많은 분야에서 그 가치를 입증할 것입니다.

HTTP/3 및 QUIC이 계속해서 견인력을 얻고 더 널리 채택됨에 따라 라이브 및 비디오 스트리밍, 주문형 비디오, 다운로드 또는 웹 가속에 관계없이 광범위한 사용 사례가 나타날 것으로 예상할 수 있습니다. 이러한 기술에 대한 가장 유망한 응용 시나리오 중 일부는 다음과 같습니다.

실시간 애플리케이션

HTTP/3 및 QUIC는 대기 시간이 짧고 처리량이 많은 연결이 필요한 실시간 애플리케이션에 이상적입니다. 여기에는 화상 회의, 온라인 게임, 라이브 스트리밍과 같은 애플리케이션이 포함됩니다. QUIC의 강력한 네트워크 불량 방지 기능 및 연결 마이그레이션을 기반으로 비디오 시작 시간을 효과적으로 개선할 수 있으며 비디오 끊김률 및 요청 실패율을 줄일 수 있습니다.

사물 인터넷

터미널 장치가 사용되는 IoT 시나리오에서 고속 이동, 해양 및 산악 환경과 같이 장치에 사용할 수 있는 네트워크 리소스가 매우 제한적이고 복잡하고 혼란스러운 경우가 많습니다. TCP를 기반으로 하는 MQTT(Message Queuing Telemetry Transport) IoT 통신 프로토콜은 종종 재연결 중에 빈번한 연결 중단과 큰 서버/클라이언트 오버헤드를 경험합니다. 그러나 QUIC의 0 RTT 재연결/1 RTT 설정 기능 및 다중화 특성의 장점은 열악하고 불안정한 네트워크에서 입증되어 콘텐츠 전송 효율성을 개선하고 사용자 경험을 향상시킬 수 있습니다.

클라우드 컴퓨팅

점점 더 많은 애플리케이션과 서비스가 클라우드로 이동함에 따라 클라이언트와 서버 간에 보다 효율적이고 안정적인 연결이 필요합니다. 멀티플렉싱된 스트림, 낮은 대기 시간 핸드셰이크 및 제로 왕복 시간 재개를 처리하는 기능을 통해 QUIC은 클라우드 기반 컴퓨팅 시스템의 성능을 향상할 수 있습니다.

전자상거래 및 금융결제

전자 상거래에서 QUIC의 향상된 안정성과 속도는 고객이 최대 트래픽 기간에도 원활하고 매끄러운 쇼핑 경험을 할 수 있도록 도와줍니다. QUIC은 빠른 페이지 로딩 시간 및 안전한 지불 거래와 같은 전자 상거래 애플리케이션을 지원하는 데 필요한 성능 및 보안 기능을 제공합니다.

기술이 계속 진화하고 성숙해짐에 따라 더욱 다양하고 혁신적인 사용 사례가 등장하여 새로운 애플리케이션 및 서비스 개발을 주도할 것으로 기대할 수 있습니다.

CDNetworks는 전체 플랫폼에서 HTTP/3 및 QUIC를 지원합니다.

씨디네트웍스는 QUIC 프로토콜의 기능 잠재력을 예견하고 개발을 주도했습니다. HTTP/3의 새로운 시대를 맞이하기 위해 씨디네트웍스는 5년 전 플랫폼에서 QUIC 프로토콜 지원을 구현했으며, HTTP/3 표준의 정식 출시 이후 시장 요구에 부응하여 전체 플랫폼을 업그레이드했습니다. gQUIC(Google QUIC) 및 iQUIC(IETF QUIC)의 모든 버전을 완벽하게 지원하는 원본 QUIC.

내부적으로 CDNetworks는 플랫폼의 프레임 처리 용량을 개선하고 성능을 최적화하여 기계 소비를 줄였습니다. 내부 테스트 데이터의 한 부분에 따르면 비트 전송률이 1Mbps인 QUIC 스트림 풀 시나리오에서 새 플랫폼은 동일한 비즈니스 동시성 조건에서 대역폭 성능을 41% 향상할 수 있으며 평균 CPU 소비는 28% 감소합니다.

라이브 스트리밍 시나리오의 경우, 씨디네트웍스는 QUIC 프로토콜의 재전송 효율성 및 속도 샘플링 계산 능력을 향상시키기 위해 고강도 품질 최적화를 수행했으며, UDP 패킷 전송 및 GSO(Generic Segmentation Offload) 전략을 최적화하여 불안정한 비디오 스트리밍 품질 문제를 효과적으로 해결했습니다. 지역 간 열악한 네트워크 환경에서 QUIC 및 TCP 프로토콜을 사용하여 비디오 재생을 비교하는 라이브 스트리밍 풀 시나리오에 대한 테스트 결과 중 하나에 따르면 볼 수 있는 데이터는 다음과 같습니다.

[코드율]

패킷 손실이 없는 환경에서 QUIC와 TCP는 비슷한 코드 속도를 갖지만 20% 패킷 손실에서 QUIC는 일관된 코드 속도를 유지하는 반면 TCP는 크게 감소합니다.

[영상 평활도]
부드러움 측면에서 각 시간 주기 동안 플레이어에 대한 버퍼 리필이 있는 경우 테스트 샘플은 끊김으로 계산됩니다. 패킷 손실이 없는 환경에서 QUIC는 애플리케이션 계층 패키징에 대한 추가 암호화 작업으로 인해 TCP보다 평활도가 약간 낮습니다. 그러나 패킷 손실 조건에서는 QUIC가 TCP보다 훨씬 낫습니다.