HTTP/3

HTTP/3은 웹의 차세대 전송 프로토콜로, 기존의 TCP 기반 프로토콜 대신 QUIC(Quick UDP Internet Connections)이라는 UDP 기반 프로토콜을 사용해 더 빠르고 안전한 데이터 전송을 제공한다. HTTP/3은 이전 버전들에 비해 성능이 대폭 개선되었으며, 연결 성립 시간 단축, 지연 시간 감소, 멀티플렉싱 최적화와 같은 다양한 이점을 갖고 있다. 특히, HTTP/3은 인터넷 연결 환경이 불안정할 때도 안정적인 데이터 전송을 유지할 수 있어, 모바일 환경이나 대규모 트래픽을 다루는 서비스에서 큰 장점을 발휘한다.

HTTP/3의 등장 배경

HTTP/3은 기존의 웹 전송 방식이 가진 한계를 극복하기 위해 등장하였다. HTTP/1.x는 초기 웹 환경에서 큰 성공을 거두었지만, 점점 복잡해지는 웹 애플리케이션과 사용자의 요구를 충족시키는 데 한계를 보였다. HTTP/1.x는 하나의 연결에서 하나의 요청만 처리할 수 있어, 여러 요청을 동시에 처리할 때 속도가 느려지고 지연이 발생하는 문제를 안고 있었다. 이를 개선한 HTTP/2는 멀티플렉싱 기술을 도입해 여러 요청을 하나의 연결에서 동시에 처리할 수 있게 했지만, 여전히 TCP 기반에서 발생하는 HOL(Head-Of-Line) 블로킹 문제가 남아 있었다.

 

[그림 1] HTTP 버전 비교

 

HOL 블로킹은 TCP의 신뢰성 보장을 위한 재전송 메커니즘에서 비롯된 문제로, 하나의 패킷이 손실되면 그 이후의 모든 패킷도 전달이 지연되는 현상을 말한다. 이로 인해 HTTP/2에서도 여전히 연결 성능이 저하될 수 있었다. 또한, TCP 연결 과정에서 발생하는 핸드셰이크와 TLS(전송 계층 보안) 설정 시간이 웹 성능에 부정적인 영향을 미쳤다.

 

HOL(Head-Of-Line) 블로킹이란 네트워크에서 같은 큐에 있는 패킷이 첫 번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상이다.

 

[그림 2] HOL

 

이러한 문제를 해결하기 위해 구글에서 개발한 QUIC 프로토콜이 등장하면서 HTTP/3의 기반이 마련되었다. QUIC는 TCP가 아닌 UDP를 기반으로 동작하여 TCP의 한계를 뛰어넘었다. 특히, QUIC는 연결 복원 기능과 멀티플렉싱을 UDP 수준에서 지원하여 HOL 블로킹 문제를 해결했으며, TLS 보안을 기본적으로 통합하여 성능과 보안을 동시에 강화하였다.

QUIC Protocol : Quic UDP Internet Connections

QUIC(Quick UDP Internet Connections)는 기존의 TCP 기반 전송 프로토콜의 한계를 극복하기 위해 UDP 기반으로 설계된 최신 전송 프로토콜이다. HTTP/3는 바로 이 QUIC 프로토콜을 기반으로 동작하며, 성능 개선과 안정성을 목표로 한다.

 

QUIC의 핵심 특징 중 하나는 각 스트림(stream)을 일급 시민으로 취급한다는 점이다. 이는 하나의 연결을 통해 여러 요청을 동시에 처리할 수 있다는 것을 의미하며, 스트림 간 독립성을 보장해 준다. 즉, 하나의 스트림에서 패킷 손실이 발생하더라도 다른 스트림에 영향을 주지 않아, HTTP/2에서 발생하던 HOL blocking 문제가 QUIC에서는 발생하지 않는다. 이를 통해 데이터 전송 속도와 효율이 크게 개선된다.

 

또한, QUIC는 모바일 환경에서의 인터넷 사용량 증가를 고려하여 설계되었다. 모바일 기기 사용 시 자주 발생하는 네트워크 전환(예: Wi-Fi에서 LTE로 전환) 상황에서도 연결이 끊기지 않고 유지될 수 있도록, Connection ID라는 개념을 도입하였다. Connection ID는 네트워크 변경 시에도 기존 연결을 그대로 유지할 수 있게 해 주며, 이를 통해 빠르고 안정적인 연결 전환이 가능하다.

 

QUIC는 보안성 면에서도 큰 진보를 이루었다. 기존에는 전송 계층과 보안 계층(TCP와 TLS)이 따로 동작했지만, QUIC는 TLS 1.3을 프로토콜에 기본적으로 통합하여 보안과 전송을 한꺼번에 처리한다. 이로 인해 핸드셰이크 과정이 간소화되며 연결 성립 시간이 단축되고 보안 또한 강화된다.

 

[그림 3] 기존 HTTPS 스택에서의 QUIC

 

새로운 전송 레이어를 만들지 않고 UDP 위에 QUIC 프로토콜을 구현한 이유는

이미 널리 사용되고 있는 네트워크 인프라와의 호환성을 유지하면서 기존의 문제를 해결하기 위함이다. TCP와 달리, UDP는 단순하고 연결을 필요로 하지 않기 때문에 이를 기반으로 하는 프로토콜을 구축하면 더 유연하고 빠른 전송이 가능하다. 동시에, TCP처럼 새로운 전송 레이어를 개발할 경우 전 세계 네트워크 장비와 호환성을 고려한 대규모 업데이트가 필요했을 것이다. 하지만 UDP는 이미 방화벽과 네트워크 장비에서 광범위하게 허용되고 있으며, 그 위에서 동작하는 QUIC은 기존의 인프라를 그대로 활용하면서도 TCP의 단점을 보완할 수 있는 이상적인 선택이었다.

[그림 4] QUIC과 TCP 비교 그래프

 

이 그래프는 QUIC와 TCP 간의 핸드셰이크 지연 시간을 비교한 것으로, 각 연결의 최소 RTT(Round-Trip Time)에 따른 핸드셰이크 지연 시간을 보여준다. 

 

• 오렌지색 선(TCPᵍ)은 TCP 연결에서의 핸드셰이크 지연 시간을 나타내며, RTT가 증가함에 따라 지연 시간이 선형적으로 증가하는 것을 볼 수 있다. TCP는 신뢰성 있는 데이터 전송을 위해 다단계 핸드셰이크 과정을 거쳐야 하기 때문에, 네트워크 지연이 클수록 핸드셰이크 지연도 크게 증가한다.
• 파란색 실선(QUICᵍ)은 모든 QUIC 연결에서의 평균 핸드셰이크 지연 시간을 나타내며, 이는 0-RTT(0 Round-Trip Time) 핸드셰이크를 포함한 경우이다. 여기서 0-RTT 핸드셰이크란 이전에 연결된 적이 있는 클라이언트가 서버에 재접속할 때, 핸드셰이크 없이 데이터를 즉시 전송할 수 있게 하는 기능이다. 이로 인해 RTT가 증가하더라도 지연 시간이 상대적으로 낮게 유지된다.
• 파란색 점선(QUICᵍ 1-RTT+)은 0-RTT 핸드셰이크를 달성하지 못한 QUIC 연결에 대한 지연 시간을 나타낸다. 이 경우에도 RTT가 증가함에 따라 핸드셰이크 지연 시간이 증가하지만, 여전히 TCP보다는 더 낮은 수준을 유지하고 있다.

이 데이터는 데스크탑 연결을 기준으로 한 것이며, 모바일 연결에서도 유사한 패턴이 나타난다고 설명하고 있다. QUIC의 0-RTT 핸드셰이크 기능 덕분에 RTT가 높은 환경에서도 상대적으로 낮은 지연 시간을 유지할 수 있으며, 이는 특히 모바일과 같은 네트워크 환경에서 매우 유용하다.

---

QUIC 프로토콜의 주요 특징과 HTTP/3에서 어떻게 활용되고 있는지에 대해 알아보았다. QUIC은 기존의 TCP 기반 HTTP/2가 가진 한계를 극복하고, 더 빠르고 안정적인 데이터 전송을 목표로 설계된 최신 프로토콜이다. HOL 블로킹 문제 해결, 빠른 핸드셰이크, 모바일 환경에서의 네트워크 전환 지원 등은 웹 성능을 크게 향상하며, HTTP/3가 차세대 웹 전송의 핵심으로 자리 잡게 한다. 

앞으로 QUIC과 HTTP/3의 채택이 더욱 확대되면서, 사용자들은 더 빠르고 끊김 없는 웹 경험을 누릴 수 있을 것이다. 웹 개발자들에게는 새로운 기회와 도전이 주어지며, 이러한 변화에 발맞춰 웹 기술을 활용하는 방법을 고민할 필요가 있다.