HTTP3?
HTTP의 3번째 메이저 버전으로 HTTP/2의 차기 버전이다.
HTTP/1 및 HTTP/2가 TCP로 통신하는 것과는 달리 HTTP/3는 UDP 기반의 QUIC 프로토콜을 사용하여 통신한다.
TCP의 단점
기존엔 HTTP에서 데이터 전송에 TCP가 기본 프로토콜로 사용되었다.
그러나 모바일 인터넷이 계속 발전함에 따라 실시간 상호작용과 더 다양한 네트워크 시나리오에 대한 수요가 증가하고 되었고. 또한, 스마트폰 및 휴대용 장치가 점점 주류로 자리 잡으며 현재 인터넷 트래픽의 60% 이상이 무선으로 전송되고 있다.
현재 40년 이상 사용된 전통적인 TCP는 성능 병목 현상을 가지고 있다. 이는 주로 다음과 같은 이유다.
TLS 핸드셰이크로 인한 TCP 연결 설정 지연.
많은 단기 네트워크통신 시나리오에서는 이러한 핸드셰이크 지연이 상당한 영향을 미친다.
TCP 스트림의 Head-of-line Blocking
다른 스트림으로 여러 데이터 요청이 동일한 TCP 연결에 전송되며, 응용 프로그램 계층에서 모든 스트림은 순차적으로 처리되어야 한다.
하나의 스트림 데이터가 손실되면 해당 데이터 뒤에 있는 다른 스트림의 데이터가 손실된 데이터가 재전송될 때까지 차단되며 병복현상이 발생한다.
이 문제를 TCP 스트림의 Head-of-line Blocking이라고 한다.
TCP 패킷의 무거움과 확장의 어려움
TCP는 70년대 개발된 이래 인터넷의 중추적인 전송 프로토콜 역할을 하고있다. 하지만 오래전에 설계된 프로토콜인 관계로 복잡함의 이유로 확장의 어려움을 가진다.
또한 패킷 자체가 굉장히 무겁다.
TCP 헤더 구조
반면 UDP헤더의 구조는 간단하다.
UDP 헤더 구조
이러한 관계로 기존 TCP에 무언가 수정을해서 단점을 없애려고 하는것이 너무 어렵기때문에 아주 가벼운 UDP 프로토콜에 단점을 없애고 무언가 추가해서 사용하고자 만든것이 바로 QUIC이다. 이다.
QUIC (Quick UDP Internet Connection)
QUIC(Quick UDP Internet Connection)는 TCP의 한계를 극복하기위해 구글에서 설계한 UDP 기반의 프로토콜이다.
어떻게 한계를 극복했는지 한번 살펴보자
빠른 핸드셰이크 및 연결 설정
UDP는 연결 지향이 아닌 무연결 프로토콜이지만, QUIC은 TLS 1.3 핸드쉐이크 과정을 통해 가상의 연결을 구축하여 TCP와 유사한 기능을 제공한다. 또한 TCP의 핸드셰이크 과정을 간단하게 줄였다.
Handshake 과정과 암호화된 데이터를 주고받는 과정을 함께 전송 및 응답하는 방식으로 1번의 왕복만으로 핸드쉐이크 연결 설정이 가능하다.
또한 재 요청시에도 첫번째 연결로 캐시된 정보를 재사용하여 0번의 왕복으로 연결설정이 가능하다. (이는 TLS 1.3에 도입된것이다.)
연결 ID
각 연결은 연결 식별자나 연결 ID를 가지므로 이를 통해 연결을 식별한다.
이 연결 ID의 주요 기능은 하위 프로토콜 계층(UDP, IP 혹은 그 아래 계층)에서 주소가 변경되더라도 QUIC 연결의 패킷이 잘못된 엔드포인트로 전달되지 않도록 보장하는 것이다.
연결 ID를 이용하면 IP 주소와 네트워크 인터페이스 사이에서 연결이 마이그레이션 될 수 있다.
예를 들면 사용자가 무언가 다운로드중일때 wifi에서 셀룰러 데이터로 변경하는경우 다운로드는 중지되거나 실패할지 모른다. 만약 1,2,3,4 번 패킷을 보내고 있다고 생각해보자.
1번과 2번 패킷을 보내는중 wifi에서 셀룰러 데이터로 변경했다 하더라도 3, 4번의 연결 ID는 동일하기때문에 3, 4번 패킷 역시 동일한곳에서 온 패킷이라고 보장이 되는것이다. 그렇기때문에 QUIC는 이 마이그레이션을 통해 이어서 다운로드가 진행된다.
Head-of-line Blocking 방지
QUIC은 연결에서 여러 스트림을 다중화하는 개념을 도입했다. QUIC은 각 스트림에 대해 별도의 흐름 제어를 할수 있게 구현되었다.
단일 QUIC 연결에서 여러 HTTP 요청(스트림)을 동시에 보낼 수 있다. 단일 연결의 각 스트림 간에 순차적 종속성이 없다. 즉, 스트림 1, 2, 3이 있다면 스트림 2에서 패킷이 손실되더라도 스트림 1이나 3에대한 데이터 전송을 차단 하지않는다.
이렇기 때문에 스트림 2의 패킷을 복구하는 시간동안 1, 3의 전송이 중지되지 않는다는것이다.
이는 HTTP/2에서는 불가능했던것이다.
