2022년 5월 1일
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주소 변경으로 인하여 재연결을 수행해야 하는 경우에도, TCP 및 SCTP와는 달리 0-RTT 기능을 활용하여 전송 성능 및 높은 QoE(Quality of Experience)를 유지할 수 있다. 이러한 특징으로 인하여 재연결이 많은 이동 환경에서도 QUIC은 매우 좋은 QoE를 제공할 수 있어 이동통신 환경에서 실시간 스트리밍 서비스 등 다양한 서비스로 활용 가능
[참고]
- IETF Draft, “QUIC: A UDP-Based Multiplexed and Secure Transport”, 2021
- 한국정보처리학회, “웹 및 스트리밍 서비스에 대한 QUIC 프로토콜 성능 분석”, 2021
About The Author
도리
3 Comments
위에 HTTP/2에서 HOL이 언급되었는데 HOL문제는 HTTP/1.1의 Persistent Connection에서의 문제이지 HTTP/2의 문제가 아닙니다.
HTTP/2는 각각의 요청된 스트림에 대해 응답을 순서데로 할 필요는 없어요.
말씀해주신 내용과 같이 HOL Blocking 문제는 Application 계층 기준으로 HTTP/1.1에서 발생하는 문제이고, HTTP/2에서 메시지 병렬 처리를 통해 해결되었으므로 본문의 잘못된 내용 삭제 및 HTTP/1.1에서 발생하는 것으로 명확화 하였습니다. 잘못된 내용 지적 감사드립니다.