HTTP/3: 진화에 가까운 변화

이준혁·2023년 9월 13일

HTTP/2가 출시되고 나서 얼마 지나지 않아 HTTP/3이 출시되었다. HTTP/1과 HTTP/2 사이의 공백에 비하면 좀 이르다는 생각도 든다. 이 짧은 기간 동안 진화에 가까운 변화가 있었는데, 그 변화를 중심으로 HTTP/3에 대해 알아보자.

HTTP/3은 TCP를 사용하지 않는다.

HTTP/3의 원래 이름은 HTTP-over-QUIC이다. 이름에서 알 수 있듯이 QUIC을 기반으로 통신하는데, 여기서 QUIC은 TCP가 아닌 UDP 기반의 프로토콜이다.

QUIC

HTTP에 적합한 안정적인 전송 프로토콜로, 기존의 TCP+TLS+HTTP/2 기반 통신의 단점을 해결한다. 단순히 HTTP에만 국한되는 것이 아니라, 전반적인 통신과정에서 사용자가 필요한 정보를 더욱 빠르게 전달하는 것을 목표로 설계되었다.

그런데 왜 TCP를 사용하지 않고, UDP를 기반으로 만들었을까?

TCP는 수정하기 어렵다.

HTTP/3의 목표는 더욱 빠른 정보 전달이다. 그렇다면 기존의 통신 방식에서 무언가 더 개선을 해야 하는데, 이미 정의된 TCP를 개선하는 것은 쉬운 일이 아니다.

인터넷상에는 네트워크가 정상적으로 동작할 수 있도록 통신 과정에 필요한 네트워크 주소, 프로토콜 등의 정보를 미리 알고 있는 미들 박스라는 장비들이 있다. 미들 박스가 가지고 있는 정보들은 오랜 기간 동안 꾸준히 쌓인 것이기 때문에 빠르게 바꿀 수 없다. 또, 변경된 사항을 잘못된 것이라 판단하고 아예 연결을 차단할 수도 있다. 이를 프로토콜 고착화라고 하며, 이런 문제 때문에 이미 정의된 TCP를 개선하는 것보다 새로운 UDP를 응용하는 것이 더 유리하다.

👉 미들 박스란?
라우터, 스위치, 방화벽 등 네트워크 사이에서 IP 패킷을 라우팅하고, 악성 트래픽을 차단하는 역할들을 수행한다.

이 외에도 UDP가 주는 이점들이 있다. 자세한 내용은 잠시 후에 알아보도록 하자.

근데 UDP는 신뢰성이 없지 않나?

TCP의 단점을 해결할 수 있다고는 해도 기존의 UDP의 신뢰성 문제를 무시할 수는 없다. UDP 자체는 데이터 전송의 신뢰성을 보장하지 않는 것이 사실이다. 하지만 UDP에 결함이 있다기 보다, 제공하는 기능이 없어서 발생하는 문제다. 반대로 생각하면 적절한 기능만 추가해 준다면 얼마든지 장점을 살릴 수 있다.

HTTP/3은 QUIC이라는 새로운 계층을 UDP 위에 추가함으로써 통신의 신뢰성을 제공한다. QUIC은 TCP에 존재하는 패킷 재전송, 혼잡 제어, 속도 조정 및 다른 기능들을 제공하기 때문에 UDP의 신뢰성 부족 문제를 보완할 수 있다.

HTTP/3의 개선사항

HTTP/3은 UDP의 특성과 QUIC이 제공하는 기능을 바탕으로 개선되었다. UDP는 TCP의 단점을 극복하고, QUIC은 UDP의 단점을 보완한다. 구체적으로 어떻게 적용되는지 알아보자.

HOLB 문제 해결

TCP는 에러 복구 방식으로 ARQ(Automatic Repeat Request)를 사용하는데, 패킷 전송 과정에서 문제가 발생하면 해당 요청을 재전송하도록 설계되어 있다. 이 과정에서 전송 흐름이 중지되어 병목이 발생하는데 이를 HOLB(head-of-line blocking)라고 한다.

QUIC은 항상 재전송 요청을 보내지 않으며, 패킷의 손실과 유실에 따라 다르게 작동한다. QUIC은 UDP의 에러 복구 방식인 FEC(Forward Error Correction)를 사용한다. FEC 방식은 패킷이 손실되었더라도 재전송하지 않고, 정정 비트를 통해 훼손된 비트를 복구하도록 설계되어 있다.

반면, 패킷이 유실된 경우에는 재전송 요청을 보낸다. 하지만 패킷이 유실된 스트림만 중지시키기 때문에 다른 스트림의 전송에는 영향을 미치지 않는다. 여기서 스트림이란 데이터를 전송하는 실행 흐름으로, QUIC은 하나의 연결 안에서 여러 스트림으로 데이터를 전송하는 멀티 플렉싱을 제공한다.

QUIC이 단지 멀티 플렉싱을 사용해서 HOLB 문제를 해결하는 것은 아니다. HTTP/2도 멀티 플렉싱을 지원하지만 하나의 스트림이 재전송 요청을 보낼 때, 모든 스트림이 중지되기 때문에 HOLB 문제를 해결하지 못한다. QUIC이 HOLB 문제를 해결할 수 있는 이유는 내부적으로 스트림의 독립성을 보장하기 때문이다.

이처럼 QUIC은 FEC와 독립적인 스트림을 통해 기존의 HOLB 문제를 해결한다.

통신 대기시간 감소

TCP 통신은 연결 과정에서 3-way handshake 과정을 거친다. 여기에 TLS의 handshake까지 더해지면 TCP+TLS+HTTP/2 통신의 대기시간은 3RTT이다.

👉 RTT(Round Trip Time)란?
네트워크 요청을 시작한 후 응답을 받는 데 걸리는 시간, 패킷이 왕복하는데 걸리는 시간을 의미한다.

반면, HTTP/3은 UDP 기반의 통신으로 3-way handshake 과정을 거치지 않는다. 물론 통신을 위해 연결하는 과정은 있지만, "Connection ID"로 생성한 초기화 키를 사용해서 연결과 동시에 데이터를 바로 전송한다. 이를 통해 통신까지 대기시간은 1RTT만 소요된다.

또, QUIC 기반 통신이 연결되면 서버에서 해당 설정을 캐싱 해두고, 다음 연결에도 사용하기 때문에 0RTT만으로도 통신할 수 있게 된다.

간편한 RTT 측정

통신 과정에서 클라이언트가 일정 시간 동안 적절한 응답을 받지 못한다면, 패킷이 유실되었다고 판단하고 요청을 재전송한다. 이때, 일정 시간을 RTO(Retransmission Time Out)라고 하며, RTT를 기반으로 설정한다. 만약 RTT를 모르는 상태에서 패킷을 재전송했다면, 어떤 요청의 응답인지 확인하기 힘들어진다.

이렇게 RTT를 계산하기 힘들어지는 상황을 재전송 모호성이라고 하는데, TCP 통신에서 이 문제를 해결하려면 패킷을 식별할 수 있는 별도의 방법을 사용해야 한다.

QUIC은 전송할 때마다 패킷 번호를 헤더에 추가하기 때문에 손쉽게 문제를 해결할 수 있다. TCP의 시퀀스 번호와 다르게 QUIC의 패킷 번호는 규칙적으로 증가하며, 전송 순서 자체를 나타낸다. 따라서 패킷의 순서를 명확하게 파악할 수 있고, RTT도 정확하게 계산할 수 있다.

연결 마이그레이션

HTTP/3는 UDP 포트와 IP 주소로 목적지를 찾아가지만 결국 연결에 사용되는 것은 "Connection ID"다. 서버가 데이터를 수신할 때, "Connection ID"로 클라이언트를 식별하기 때문에 도중에 IP 주소가 변경되어도 동일한 연결을 유지할 수 있다.

HTTP/3의 보급 한계

이제까지 UDP 기반의 QUIC을 통해 얻는 이점에 대해서만 설명했지만, 다음과 같은 한계들도 존재한다.

CPU 부하

Linux 등의 운영체제에서 UDP와 관련된 부분이 TCP 만큼 최적화되어 있지 않다. 같은 트래픽을 기준으로 HTTP/2를 사용할 때보다 CPU 자원이 거의 2배 가까이 필요하다.

오랫동안 TCP를 사용해왔기 때문에 하드웨어가 TCP에 최적화되어 있지만, UDP나 QUIC에 대해서는 최적화가 거의 되어있지 않다.

UDP에 보수적인 인식

UDP는 DDOS와 같은 공격에 사용되기도 하기 때문에 기업 또는 네트워크에서는 아예 UDP 트래픽을 차단하거나 데이터 크기를 제한한다. 그래서 UDP 통신 자체가 불가능하거나 제약 조건으로 인해 TCP 기반 통신보다 성능이 좋지 않을 수도 있다.

정리

이곳에서 여러 기술들의 점유율을 파악할 수 있는데, 2023년 7월 10일 기준으로 HTTP/3의 점유율이 상승 중이라고 한다. UDP 통신을 위한 인프라가 갖춰지는 것이 제일 힘들 것이라 생각했는데, 이렇게 점유율이 높아진다면 HTTP/3도 빠르게 자리 잡을 수 있을 것 같다.

간단하게 정리하면서 마무리해보자.

HTTP/3는 TCP 기반이 아니라 QUIC을 사용하는 UDP 기반의 프로토콜이다.
- TCP는 이미 고착화되어 있어 개선하기 힘들다.
- QUIC은 TCP와 비슷한 기능들을 제공함으로써 UDP 통신의 신뢰성을 보완한다.
HTTP/3의 개선사항
- FEC 방식의 손실 복구와, 스트림의 독립성을 보장함으로써 HOLB 문제를 해결한다.
- 연결과 동시에 데이터를 전송하기 때문에 대기시간은 0~1RTT까지 감소한다.
- 패킷마다 순서를 표시하는 패킷 번호가 있어 RTT를 간편하게 계산할 수 있다.
- "Connection ID"로 클라이언트를 식별하기 때문에 IP 주소가 변해도 연결이 유지된다.
HTTP/3의 한계
- 운영체제에서 UDP에 대한 최적화가 이뤄지지 않아 CPU 사용량이 높다.
- 기업 또는 네트워크에서 UDP 통신에 보수적이다.