HTTP/3, HTTP over QUIC

HTTP/3는 3번째 메이저 버전으로 2022년 6월 6일 RFC 9114를 통해 표준화 되었습니다. 

HTTP/3에 대해 들어보셨다면 익히 아시겠지만, HTTP/3는 UDP 기반의 QUIC 프로토콜을 사용합니다.

그래서 RFC 9114 의 주요 내용을 읽어보면서 (그 중에서도 의미론적인 접근방법으로) HTTP/3에 대해서 간략하게 소개하고, 

TCP 프로토콜의 한계에 대해 먼저 알아보려고 합니다.

 

HTTP는 1994년 ~ 1995년에 인터넷 붐을 맞이하며, 1996년에 HTTP/1.0 을 문서화한 RFC 1945를 발표했습니다.

HTTP/2를 문서화한 RFC 7540 은 2012년 처음 제안되어서 2015년 표준화되었습니다.

그리고 이번엔 7년만에 HTTP/3가 표준화된 것인데요.

 

아래의 점유율을 보면 RFC 9114의 드래프트 문서가 마무리되어가는 2021년부터 HTTP/3의 점유율이 작지만 점점 올라가는 게 보입니다.

(벌써 이렇게 점유율을 차지하는 걸 보니 더 궁금하네요...)

 

 

HTTP/3 란

사실 HTTP/3는 꽤 오래전부터 설계되었습니다. HTTP/3가 제안된 이름은 "QUIC 경유 HTTP"였는데, 이를 IEFE에서 HTTP/3로 부르기로 결정한 것입니다. 그러니깐 QUIC을 사용하겠다는 건데, 그 특징은 RFC 9114 개요에서 이렇게 설명하고 있습니다.

QUIC 전송 프로토콜은 스트림 멀티플렉싱, 스트림 단위의 flow 제어, 연결 설정 시 레이턴시 감소와 같은 특징을 가지고 있다.

QUIC은 범용 목적의 전송 계층 통신 프로토콜로, 구글의 짐 로스킨드가 처음 설계하고 2013년 공개 발표되어 구글 크롬부터 구글 서버에 이르는 절반 이상의 연결에 사용되고 있습니다. QUIC은 가장 큰 목표는 TCP를 사용하는 연결 지향의 웹 어플리케이션 성능을 개선하기 위함인데요. 그러면 QUIC에 대해 알기 전, TCP가 가지는 특징을 먼저 알아봐야 할 것 같아요.

 

TCP 의 특징

TCP는 연결형 서비스로서 전송 순서를 보장하고 수신 여부를 확인하는 신뢰성이 높은 프로토콜입니다. 그만큼 네트워크 계층의 문제를 크게 걱정하지 않고 사용할 수 있는 반면, 여러가지 제어를 하는 만큼 전송 속도는 느립니다.

 

이런 TCP는 받을 대상 노드가 서비스 가능 상태인지를 확인해야 하는데, 3 Way Handshake 방식으로 통신을 수행합니다.

 

TCP 3 Way Handshaking

위와 같이 3단계로 나누어집니다.

위의 각 단계는 아래와 같은 과정으로 진행됩니다.

 

1. SYNC 단계: 어플리케이션이 서버에 통신을 위한 연결을 요청하는 단계

2. SYNC-ACK 단계: 서버가 어플리케이션에 자신이 활성 상태임을 알리고 어플리케이션에서도 포트를 열어 연결을 활성화하라는 요청 메시지를 전송하는 단계

3. ACK 단계: 어플리케이션이 서버의 요청 메세지를 수락하여 연결이 수립되는 단계

 

이런 일련의 과정을 거친 후에는 클라이언트와 서버가 신뢰성 있는 TCP 연결을 생성하게 되고, 데이터를 주고 받을 수 있는 상태가 됩니다.

이 과정은 연결을 끊을 때에도 마찬가지로 진행되고, 과정을 거친 후에야 연결을 종료할 수 있게 됩니다.

매번 조금 번거로운 과정을 거치다 보니, 속도가 느려지는 것이죠.

 

UDP 기반의 QUIC

그래서 QUIC은 TCP 의 핸드쉐이킹 과정을 최적화하는 것에 초점을 맞춰 UDP 를 사용하여 설계되었습니다. 

우리가 기존에 알고 있는 TCP 와 UDP는 아래와 같이 비교할 수 있습니다.

	TCP	UDP
연결 방식	연결형 서비스	비연결형 서비스
패킷 교환	가상 회선 방식	데이터그램 방식
전송 순서	전송 순서 보장함	전송 순서 바뀔 수 있음
수신 여부 확인	수신 여부 확인	수신 여부 확인하지 않음
신뢰성	높음	낮음
전송 속도	느림	빠름

그러면 QUIC도 UDP를 사용하니 패킷의 신뢰성이 낮다고 봐야 할까라고 한다면 또 그건 아니라고 합니다.

 

TCP는 오래 전에 설계되었을 뿐만 아니라 기능이 많이 포함되어 있다보니, 헤더에 공간이 거의 남아있지 않은 반면,

UDP는 전송 자체에 초점을 둔 프로토콜이기 때문에 개발자가 구현하는 것에 따라 TCP와 비슷한 수준의 기능도 가질 수 있습니다.

 

연결 설정 중 레이턴시 감소

TCP의 3 way handshaking을 보완하는 특징입니다.

클라이언트가 보낸 요청을 서버가 처리하고 다시 클라이언트로 응답해주는 사이클을 RTT(Round Trip Time)이라고 하는데, TCP는 연결을 생성하려면 1 RTT, TLS를 사용한 암호화를 한다면 3 RTT가 필요해집니다. 반면 QUIC 은 첫 연결 설정에 1 RTT 만 소요됩니다. 

 

이는 첫 연결 설정에서 필요한 정보와 데이터를 함께 보내어 해결했습니다. TCP는 데이터를 보내기 전, 신뢰를 파악하기 위한 요청을 하는 반면 QUIC은 데이터를 함께 보내어서 횟수 자체를 줄여서 시간을 절감했습니다. 

 

 

 

 

조금 급하게 공부한 내용이라 빠진 내용이나 아쉬운 부분이 많지만

계속 업데이트 하고 다른 특징들에 대해서는 다음 글에서 추가로 설명해보고자 합니다.