QUIC 프로토콜 이해하기

Damon Kwon·2022년 1월 21일

quic 프로토콜

찍먹 시리즈

목록 보기

1/2

신기술이 최고인줄 알았던 때가 있었다.
하지만 기술 가리는 개발자는 크게 성장 못한다고들 하더라.
물론, 지금도 Java보다 Go를 좋아하는 것 처럼 어린애같은 마음이 남아있긴 함. ㅋㅋ

언젠가 지나가면서 HTTP3 관련 글을 본 적 있다.
그 때 들었던 생각은,

"오? 신기술 좋지 나도 함 써볼까?"
"내 사이드 프로젝트에는 QUIC 프로토콜 써야지~"

미리 공부해두면 나중에 QUIC 프로토콜 상용화 될 때 남들 보다 조금 더 빨리 치고나갈 수 있을까? (사실 나중되면 다 까먹을듯)

하여튼 우선 QUIC 프로토콜이 뭔지 맛보기로 보고 가야겠다.

QUIC (Quick UDP Internet Connection) 소개

2013년 6월 : 구글에서 QUIC 프로토콜 설계 후 공개.
국제 인터넷 표준화 기구(IETF)에 표준화 제안.
Google-QUIC는 HTTP만 전송했었으나, IETF QUIC 워킹 그룹을 통해 나온 IETF-QUIC는 TLS 1.3의 암호화 보안을 적용해 개선됨.
2018년 11월 : HTTP-over-QUIC는 HTTP/3으로 개명함.
2019년 7월 : QUIC 버전 1의 최종 명세 발표됨.
2021년 5월 : RFC Proposed Standard, (RFC9000)

뭐 대충~ 열심히 드래프트 상태에 있다가 발표된지 얼마 안된 따끈따끈한 HTTP3다. 우리 보안도 신경썼어요~ 속도도 빨라요~ 이런 느낌쓰.

go로 포매팅도 되어있음 ㅋㅋ (https://github.com/lucas-clemente/quic-go)

QUIC 프로토콜

TCP가 TLS handshake로 인해 RTT가 증가하는 현상 해결.
TCP의 HOL 블로킹 문제 해결
UDP의 데이터 손실로인한 신뢰성 문제 해결

long Header는 1-RTT 패킷 보호가 모두 시작되고, 버전 협상이 완료 될 때 까지 초기 교환에 사용된다.

Long form packets are used for the initial exchange - until both 1-RTT packet protection can be started AND version negotiation is complete.

1-RTT packets protection?

short Header는 대량의 데이터를 전달하기 위해 사용한다.

Short form packets carry the bulk of the data.

long header

Long Header Packet {
  Header Form (1) = 1,
  Version-Specific Bits (7),
  Version (32),
  Destination Connection ID Length (8),
  Destination Connection ID (0..2040),
  Source Connection ID Length (8),
  Source Connection ID (0..2040),
  Version-Specific Data (..),
}

long header QUIC 패킷은 첫 번째 바이트의 높은 비트를 1로 설정한다. 그 바이트의 다른 모든 비트는 버전에 따라 다르다.
Version 필드는 32비트 버전 필드가 포함된다.
Destination Connection ID Length는 다음에 오는 대상 연결 ID 필드의 길이(바이트)를 포함한다. 이 길이는 8비트 부호 없는 정수로 인코딩된다.
Destination Connection ID 필드는 Destination Connection ID Length 필드를 따르며 길이는 0에서 255바이트 사이이다.
Source Connection ID Length(byte)는 8비트 부호 없는 정수로 인코딩된다.
Source Connection ID 필드는 Source Connection ID Length 필드를 따르며 길이는 0에서 255바이트 사이입니다.
나머지 패킷은 버전별 콘텐츠를 포함한다.

short header

Short Header Packet {
  Header Form (1) = 0,
  Version-Specific Bits (7),
  Destination Connection ID (..),
  Version-Specific Data (..),
}

short header QUIC 패킷은 첫 번째 바이트의 높은 비트를 0으로 설정한다.
short header QUIC 패킷에는 Destination Connection ID length, Source Connection ID 또는 Version 필드가 포함되지 않는다. Destination Connection ID의 길이는 헤더가 짧은 패킷으로 인코딩되지 않으며 이 규격에 의해 제한되지 않는다.
나머지 패킷은 버전별 의미 체계를 가지고 있다.

Connection ID?

주요 기능 : 하위 프로토콜 계층(UDP, IP 및 이하)에서 주소 변경으로 인해 QUIC 연결이 잘못된 QUIC 끝점에 전달되는 패킷이 발생하지 않도록 하는 것
각 QUIC 패킷이 올바른 엔드포인트 인스턴스로 전달될 수 있도록 이를 지원하는 중간자와 엔드포인트에 의해 사용됨
엔드포인트에서 연결 ID는 패킷이 어떤 QUIC 연결을 의도하는지 식별하는 데 사용함
동일한 QUIC 연결을 위한 패킷은 다른 Connection ID 값을 사용할 수 있다.

Version Field

4바이트 식별자가 포함
QUIC 버전을 식별하기 위해 엔드포인트에서 사용됨.
값이 0x00000000인 버전 필드는 Version negotiation을 위해 예약된 것임.
Version negotiation?
long header quic packet과 패킷이 이해되지 않거나 지원하지 않는 버전을 수신하는 QUIC Endpoint는 response로 버전 협상 패킷을 보낼 수 있다

당장 완전 깊게 파고 들 필요 없으니까 대충 이정도까지 알아둬야지.
제발 나 개발자로 일하는 동안 상용화 되어줘~ 서비스 제품에다가 써보고 싶다 ㅋㅋ