X

QUIC (Quick UDP Internet Connection)

1. QUIC(Quick UDP Internet Connection)의 개요

(1) QUIC의 개념 및 배경

개념 UDP 기반 응답 속도를 개선하고 TCP 기반 다중화와 신뢰성 있는 전송이 가능한 차세대 HTTP 프로토콜(HTTP/3)
배경 – 구글에서 처음 설계하였고, 2012년 구현 및 적용되었고, 2013년 실험 확대로서 공개 발표 후 IETF에서 기술 표준화
– 사물인터넷 등의 다양한 인터넷 서비스가 등장함에 따라, OSI 7 Layer 전송 계층 프로토콜의 한계를 극복하고 고품질의 인터넷 서비스 제공 위해 QUIC 프로토콜 개발

(2) QUIC의 특징

특징 설명
0-RTT 연결 설정 – 알려진 서버에 대한 연결은 0-RTT로 설정
– 새로운 암호화 키 교환 또는 버전 협상의 경우에만 설정 시간 증가
– 암호화 및 전송 핸드셰이크를 결합하여 설정 시간 단축
스트림 멀티플렉싱 – UDP 통해 QUIC 스트림을 다중화하여 HOL Blocking 문제 극복
– QUIC 패킷 손실은 해당 패킷의 스트림만 차단
흐름 제어 – 수신자는 발신자가 스트림당 보낼 수 있는 총 바이트 수로 지정
혼잡 제어 – 커널 공간이 아닌 사용자 공간에 존재
– 알고리즘 업데이트를 더 빠르게 수행
– CUBIC 및 BBR 알고리즘과 통합
연결 마이그레이션 – 클라이언트 IP 주소 변경 시에도 연결 유지
– Wi-Fi와 셀룰러 간 전환 시 연결 유지
  • HOL(Head-of-Line) Blocking 문제: HTTP/1.1에서 특정 요청 처리 지연 시 전체 응답이 지연되는 문제

(3) HTTP 발전 과정

  • 기존 HTTP 버전과 달리 UDP 기반 다중화, 혼잡 제어와 신뢰성 있는 전송을 통해 다양한 응용 계층에서 높은 성능 및 유연한 기능 제공

 

2. QUIC 프로토콜의 구조 및 Handshake 과정

(1) QUIC 프로토콜의 구조

– QUIC 프로토콜은 TLS 1.3 암호화 통해 단순성과 속도 개선
– QUIC 는 연결 설정 대기 시간 최소화 위해 암호화 및 전송을 위한 1회 Handshake 수행
– 기본적으로 모든 데이터는 암호화 송수신
– UDP Port 443 사용

(2) QUIC Handshake 과정 및 설명

1) QUIC Handshake 과정

2) QUIC Handshake 과정 설명

연결 과정 Client/Server 역할 설명
Initial 1-RTT Handshake Client – inchoate(empty) client hello(CHLO)를 Server로 전송
Server – 소스 주소 토큰과 서버 인증서를 포함하여 REJ(rejection)를 Client 에 전송
Client – Complete CHLO를 Server 전송하면 QUIC Handshake 완료
Successful 0-RTT Handshake Client/Server – 이전 연결의 캐시된 자격 증명을 사용해서 암호화된 요청을 즉시 서버로 전송
Rejected 0-RTT Handshake Client/Server – Client의 캐싱된 정보가 오래된 경우 1-RTT Handshake 재수행

 

3. QUIC의 구성 요소

구성 요소 용도 역할
QUIC Handshake 연결 설정
– 최초 수행 후 재 연결시 캐싱 정보 기반 Handshake 없이 암호화된 데이터 송수신 수행
TCP Cubic 혼잡 제어 – 원본과 재전송된 각 패킷에 대한 시퀀스 번호 분리시켜 전달
– 원본의 ACK과 재전송 ACK 구별해 TCP의 재전송 모호 문제 해결
전진 오류 수정(FEC) 흐름 제어 – 패리티를 사용하여 FEC 패킷과 그룹내에 패킷을 통해 복구 가능
– FEC 통해 해당 패킷에 대한 재전송을 줄임
패킷 암호화 암호화 – 초기 Handshake 패킷과 재전송 패킷을 제외한 QUIC 패킷은 인증 지원 및 암호화 전송
  • QUIC은 IP주소 변경으로 인하여 재연결을 수행해야 하는 경우에도, TCPSCTP와는 달리 0-RTT 기능을 활용하여 전송 성능 및 높은 QoE(Quality of Experience)를 유지할 수 있다. 이러한 특징으로 인하여 재연결이 많은 이동 환경에서도 QUIC은 매우 좋은 QoE를 제공할 수 있어 이동통신 환경에서 실시간 스트리밍 서비스 등 다양한 서비스로 활용 가능

[참고]

  • IETF Draft, “QUIC: A UDP-Based Multiplexed and Secure Transport”, 2021
  • 한국정보처리학회, “웹 및 스트리밍 서비스에 대한 QUIC 프로토콜 성능 분석”, 2021
Categories: 네트워크
도리:

View Comments (2)

  • 위에 HTTP/2에서 HOL이 언급되었는데 HOL문제는 HTTP/1.1의 Persistent Connection에서의 문제이지 HTTP/2의 문제가 아닙니다.

    HTTP/2는 각각의 요청된 스트림에 대해 응답을 순서데로 할 필요는 없어요.

    • 말씀해주신 내용과 같이 HOL Blocking 문제는 Application 계층 기준으로 HTTP/1.1에서 발생하는 문제이고, HTTP/2에서 메시지 병렬 처리를 통해 해결되었으므로 본문의 잘못된 내용 삭제 및 HTTP/1.1에서 발생하는 것으로 명확화 하였습니다. 잘못된 내용 지적 감사드립니다.