QUIC는 어떻게 Head-of-Line(HOL) Blocking를 피할 수 있을까?

 

🌱 HTTP에 대해 공부를 하다가 HTTP/3.0의 특징에서 QUIC 프로토콜을 사용하여 HOL Blocking 현상을 제거했다고 알게 되었다. TCP와는 달리 스트림 별로 독립적인 전송을 제공하기 때문에 제거를 할 수 있었다고 하는데, “스트림 별로 독립적인 전송을 한다는 것은 어떤 의미일까?”라는 의문이 생겨 공부하게 되었다.

 

HOL Blocking 현상은 HTTP, TCP, 스위치 및 라우터, 데이터베이스 시스템 등에서 발생하는 현상이다. 이 중에서 우리가 알아갈 것은 HTTP, TCP의 HOL Blocking 현상이 어떻게 발생하며, QUIC이 이를 해결한 방법이다.

 

먼저 QUIC에 대해 간단하게 알아보자.

QUIC은 왜 등장 했을까?

QUIC이 등장한 배경은 인터넷의 급격한 발전과 변화에 대응하기 위함이다. 과거에는 간단한 웹 페이지 로딩에도 1~2분 이상의 시간이 소요되곤 했으며, 저해상도 동영상을 보려면 재생 직후 일시 정지하여 버퍼링을 기다렸다. 그러나 현재 사용자들은 인터넷 서핑을 할 때 대기 시간 없이 원활하게 정보를 얻기를 원하고, 4K 화질의 동영상도 버퍼링이나 픽셀화 없이 즉각적으로 스트리밍하길 바란다. 이런 사용자의 니즈와 기대에 부응하기 위해 인터넷 기술은 끊임없이 발전했지만, 기본적으로 사용되던 인터넷 프로토콜인 TCP는 그 자체로는 이러한 현대의 요구사항을 완벽히 만족시키기 어려웠다. 물론, TCP는 그 자체로 탁월한 프로토콜이다. 그러나 현대 인터넷 환경에서 더 높은 퍼포먼스와 반응성을 요구하는 서비스를 위해 TCP를 직접 수정하기는 어렵다. 이러한 문제점을 해결하고자 QUIC이 탄생하게 되었다.

그래서 QUIC, 왜 빠른데?

연결 지역 시간 단축

QUIC은 보안 네트워크 연결을 위해 TCP와 TLS의 두 번의 핸드쉐이크를 기다릴 필요가 없다. 덕분에 연결이 끊긴 후에도 빠르게 복구된다. 처음 서비스에 연결할 때 데이터를 더 신속하게 받을 수 있으며, 재연결 시에는 더욱 빠르게 데이터 전송이 가능하다. QUIC 1.0은 모든 데이터 전송에 TLS 1.3 기반 암호화를 적용한다. TCP를 사용할 때는 3-way-handshake로 인해 최소 1-RTT의 지연이 발생한다. HTTPS를 사용하면 TLS 핸드쉐이크로 인해 추가 RTT가 발생한다. 그러나 QUIC은 TCP와 TLS의 핸드쉐이크 과정을 한 번에 처리하여 시간을 단축한다.

연결 재사용

QUIC은 스트림과 세션 티켓을 활용하여 세션을 재사용한다. 단일 QUIC 세션에는 여러 스트림이 동시에 존재할 수 있으며, 서버는 전체 핸드쉐이크 과정 없이 세션 티켓을 이용해 클라이언트와 안전하게 재연결할 수 있다. 특히, QUIC은 한 번 이상의 데이터 전송 경험이 있는 클라이언트와 서버 사이에는 0-RTT로 작동하여 빠른 재연결을 가능하게 한다.

Connection Migration

QUIC은 IP 주소 변경에도 불구하고 연결을 유지한다. 예를 들어, 유선 LAN에 연결된 노트북을 WiFi로 전환할 경우, TCP를 사용하면 연결을 종료하고 WiFi IP로 새로운 연결을 시작해야 한다. 반면 QUIC는 서버에 Connection ID를 제공하여, 새 IP 주소에서도 기존 연결을 유지하게 만든다.

HTTP에서 HOL Blocking이 발생하는 이유는 뭘까?

QUIC이 어떻게 HOL Blocking을 피했는지 알려면 왜 발생을 하는지 먼저 알아야할 것이다. TCP에서의 HOL Blocking을 알기 전에 HTTP에서의 HOL Blocking을 먼저 알아보자.

HTTP / 1.0

HTTP/1.0에서 클라이언트는 HTML, CSS, JS 같은 자원들을 요청하기 위해 별도의 TCP 연결을 맺어야 한다. 특히, HTTP/1.0의 특성상 한 TCP 연결에서는 단 하나의 요청만 처리할 수 있으며, 요청에 대한 응답이 도착한 후 해당 TCP 연결은 종료된다. 예를 들어, 클라이언트가 HTML 파일을 요청할 때 첫 번째 TCP 연결을 사용하게 되고, 해당 연결은 HTML에 대한 응답을 받은 후에 종료된다. 그 다음 CSS 파일을 요청하기 위해서는 새로운 TCP 연결을 열어야 한다. 이런 방식의 결과로, 클라이언트는 연속된 여러 요청을 순차적으로 처리해야 하며, 한 요청에 대한 응답이 도착하기 전까지는 다음 요청을 보낼 수 없다. 이 현상을 "HOL (Head Of Line) Blocking"이라고 부른다. 이로 인해, 만약 HTML에 대한 응답이 10분이 걸린다면, CSS에 대한 응답이 실제로는 1초만에 가능하더라도, HTML의 응답을 기다리는 10분 동안 대기해야만 한다. 이렇게 HTTP/1.0의 구조는 효율적이지 않아, 웹 성능에 큰 제약을 가하게 된다.

HTTP / 1.1

HTTP/1.1에서는 클라이언트가 HTML, CSS, JS 같은 자원들을 요청할 때, 하나의 TCP 연결을 통해 여러 요청과 응답을 주고 받을 수 있게 되었다. 이러한 기술을 '파이프라이닝(pipelining)'이라고 부른다. 이로 인해, 매번 새로운 연결을 수립하는데 필요한 3-way-handshake와 4-way-handshake의 반복이 줄어들어, HTTP/1.0에 비해 페이지 로딩 속도가 개선되었다. 그러나 HOL (Head Of Line) Blocking 문제는 HTTP/1.1에서도 여전히 존재했다. 예를 들어, HTML, CSS, JS에 대한 요청을 연속적으로 보냈을 때, 클라이언트는 요청한 순서대로 응답을 받게 되는데, 첫 번째 요청의 응답이 지연되면, 뒤이은 요청들에 대한 응답도 그 지연 시간만큼 기다려야 한다. 이는 곧 TCP 연결은 하나로 줄어들었지만, HTTP/1.0에서의 HOL Blocking 문제가 그대로 남아 있음을 의미한다.

그럼 TCP에서 발생하는 HOL Blocking은 뭘까?

HTTP / 2.0

HTTP/2.0의 주요 도입된 기술 중 하나는 "스트림"이라는 개념이다. 스트림은 하나의 TCP 연결 내에서 여러 요청과 응답을 병렬로 처리할 수 있게 해주며, 이를 '멀티플렉싱(multiplexing)'이라고도 부른다. 각각의 스트림은 독립적으로 동작하기 때문에, 한 스트림에서의 지연이 다른 스트림의 처리에 영향을 주지 않는다. 그러나 TCP는 패킷의 순서를 보장하는 프로토콜이기 때문에, 만약 한 패킷이 손실될 경우 그 뒤따르는 패킷들은 손실된 패킷이 도착할 때까지 대기해야 한다. 이 현상을 'TCP의 HOL Blocking'이라고 부른다. 먼저 HTTP/2.0에서 어떻게 데이터들이 전송되는지에 대한 과정을 알아보자.

클라이언트가 HTML, CSS, JS를 각각 요청한다고 가정해보면, 각 요청마다 하나의 스트림이 생성될 것이다. 만약 요청 데이터의 크기가 크다면, 이 데이터는 여러 "프레임"으로 나눠져 전송될 것이다. 이때, 세 가지 자원 요청으로 인해 세 개의 스트림이 생성되고, 각 스트림은 독립적으로 프레임들을 TCP 전송 계층에 보낼 수 있다. 하지만 실제로 TCP 연결을 통해 전송되는 순서는 정해져 있기 때문에, 이 프레임들은 순차적으로 전송될 것이다. 결론적으로, HTTP/2.0은 스트림과 멀티플렉싱을 도입하여 여러 요청을 병렬로 처리할 수 있게 되었지만, TCP의 패킷 순서 보장 특성 때문에 완전히 HOL Blocking 문제를 제거할 수는 없었다.

Frame? packet과 같은 단위일까?

결론은 아니다. 그림에서 볼 수 있듯이, 단 하나의 프레임은 여러 TCP 패킷에 나눠져 전송될 수 있다. 반면, 여러 프레임들이 하나의 패킷 안에 포함되어 전송될 수도 있다. 또한 프레임의 크기와 패킷의 최대 전송 단위(MTU)에 따라서 하나의 프레임만이 단일 패킷에 포함되어 전송될 수도 있다.

HTTP/2.0에서 왜 HOL Blocking이 일어날까?

HTTP/2.0은 HTTP 계층에서의 HOL Blocking 문제를 해결하였다. 그러나, 전송 계층에서의 TCP HOL Blocking은 여전히 존재한다. 클라이언트가 HTML, CSS, JS 요청을 세 번 보내는 상황을 상상해보자. HTTP/2.0의 구조 상, 이러한 요청들은 각기 별도의 스트림으로 생성되어 병렬적으로 전송 계층으로 프레임이 전송된다. 따라서 HTTP 계층에서는 HOL Blocking 문제가 발생하지 않는다. 그러나 전송 계층에서는 다르다. 위 그림에서 볼 수 있듯이, 패킷2가 어떤 이유로 손실되었다고 가정하면, TCP는 패킷의 순서를 보장하기 위해 패킷2를 재전송 받을 때까지 그 뒤에 오는 패킷들을 기다려야 한다. 결과적으로 이 과정에서 TCP HOL Blocking이 발생하게 된다. 이런 방식으로, HTTP/2.0은 응용 계층에서의 HOL Blocking은 해결했지만, 전송 계층의 TCP HOL Blocking 문제는 여전히 존재하게 된다.

🌳 QUIC이 어떻게 해결했을까?

QUIC은 스트림 다중화(Stream Multiplexing) 기능을 통해 하나의 연결 안에서 여러 데이터를 동시에 전송한다. 동일한 스트림 내의 모든 데이터는 순서대로 전달되지만, 어떤 스트림에서 데이터 손실이 발생하더라도 다른 스트림의 데이터 전송을 차단하지 않는다. 이를 통해 HOL Blocking 문제를 해결한다. UDP는 상태 정보를 유지하지 않는 프로토콜로, 이러한 특성 덕분에 병렬 처리와 멀티플렉싱에 적합하다. 그래서 QUIC은 UDP를 기반으로 설계되었다. QUIC 내에서 여러 스트림의 데이터는 하나의 연결을 통해 멀티플렉싱되어 전송된다. 또한, 각 스트림별로 흐름 제어 기능이 있어 데이터 전송 속도를 독립적으로 조절할 수 있다.

HTTP / 3.0

클라이언트가 HTML, CSS, JS 각각에 대해 요청을 보낸다고 상상해보자. 각 요청마다 스트림이 생성된다. TCP와 달리, QUIC에서는 전송 계층까지 스트림 개념이 확장되었다. 따라서, 각 스트림은 독립적으로 작동하며, 다른 스트림의 영향을 받지 않는다. QUIC의 설계 자체에서 각 스트림에 대한 흐름 제어 기능을 제공한다. HTTP/2.0에서는 응용 계층에서만 적용되던 스트림 다중화가 QUIC를 통해 전송 계층까지 확장되었다. 이로 인해, 그림에서 보이듯이 CSS 요청의 packet 2에서 데이터 손실이 발생해도, HTML과 JS 요청에 대한 전송은 차단되지 않고 계속 이루어진다. 또한, QUIC에서의 frame은 HTTP/2.0과 마찬가지로 여러 패킷에 분할되어 전송될 수 있고, 여러 frame이 하나의 패킷에 포함될 수도 있다.

마무리

QUIC에 대해서 공부한 내용은 더 많았지만 HOL Blocking 관점에서만 정리를 했다. QUIC은 여러 측면에서 빠르다는 장점이 특징인 것 같지만 유연성에 더 많은 관심이 생긴다. 빠르게 변화하는 이 시대에서 QUIC의 버전 관리가 기대된다. TCP가 오래된 프로토콜인 만큼 안정성 측면에서 뛰어나지만 더 확장할 수 없는 (그만큼 완벽한?) 프로토콜이라는 것도 이번 기회에 알게 되었다.

 

QUIC의 HOL Blocking에 꽂혀 두서 없이 개인이 이해한 내용을 바탕으로 정리를 해보았다. 공부하는 과정에서 작성한 내용이라 틀린 내용이 있을 수 있다.