QUIC 프로토콜 (HTTP/3 기반)편집자 확인

TCP는 신뢰성 있는 연결을 보장하지만, 핸드셰이크 과정에서 발생하는 지연이 문제가 된다. TCP 연결을 수립하려면 3방향 핸드셰이크가 필요하며, 여기에 TLS 보안 계층을 추가하면 또 다른 핸드셰이크가 필요해진다. 이로 인해 실제 데이터 전송이 시작되기 전에 여러 번의 왕복 지연(RTT)이 발생하여 초기 연결 설정 시간이 길어진다.

TLS는 보안을 제공하지만, TCP 위에 별도의 계층으로 존재하기 때문에 프로토콜 스택이 복잡해지고 처리 오버헤드가 증가한다. 특히 TLS 1.3 이전 버전에서는 핸드셰이크 과정이 더욱 길었으며, TCP와 TLS가 각각 독립적으로 동작함에 따라 OSI 모델의 계층 간 상호작용이 비효율적이었다.

또한, TCP의 신뢰성 메커니즘 자체가 새로운 한계로 작용한다. TCP는 패킷 손실 시 손실된 패킷의 재전송을 위해 전체 연결의 데이터 전송을 일시적으로 멈추는 HOL 블로킹 현상을 유발할 수 있다. 이는 특히 무선 환경과 같이 손실률이 높은 네트워크에서 성능 저하의 주요 원인이 된다. TCP의 혼잡 제어 알고리즘은 네트워크 상태에 적응하도록 설계되었지만, 연결 초기에는 대역폭을 천천히 탐색하는 방식으로 동작하여 빠른 데이터 전송을 방해한다.

HTTP/2는 단일 TCP 연결 내에서 여러 스트림을 통해 요청과 응답을 멀티플렉싱하여 성능을 향상시켰다. 그러나 이 설계는 근본적인 한계를 가지고 있었는데, 그것이 바로 HOL 블로킹(Head-of-Line Blocking) 문제이다.

TCP는 신뢰성을 보장하기 위해 패킷의 순서와 전달을 관리한다. 하나의 TCP 연결에서 단일 패킷이 손실되거나 지연되면, 그 뒤에 오는 모든 데이터의 처리가 차단된다. HTTP/2는 이 단일 TCP 연결 위에서 여러 스트림을 동시에 전송하므로, 하나의 스트림에서 발생한 패킷 손실이 같은 연결을 공유하는 다른 모든 무관한 스트림들의 진행까지 멈추게 만든다[1]. 이는 특히 무선 네트워크처럼 패킷 손실이 빈번한 환경에서 성능 저하를 유발한다.

QUIC은 이 문제를 해결하기 위해 UDP를 기반으로 하여 각 스트림별로 독립적인 전송 제어를 구현한다. QUIC 연결 내에서 각 스트림은 별도의 시퀀스 번호 공간을 가지며, 하나의 스트림에서 패킷이 손실되어도 다른 스트림의 데이터는 계속 처리되고 전달될 수 있다. 이는 HOL 블로킹의 범위를 연결 전체에서 개별 스트림으로 제한함으로써 전반적인 지연 시간을 크게 줄인다.

QUIC은 전송 계층 프로토콜로 TCP 대신 UDP를 기반으로 구축된다. 이 설계 선택은 핵심적인 혁신인 통합된 멀티플렉싱을 가능하게 한다. TCP는 신뢰성 있는 바이트 스트림을 제공하지만, 단일 연결 내에서 여러 논리적 데이터 스트림을 독립적으로 다루는 데 한계가 있다. 반면, QUIC은 UDP 데이터그램 위에 자체적인 전송 로직을 구현하여, 단일 QUIC 연결 안에 여러 개의 독립적인 바이트 스트림을 병렬로 전송할 수 있다.

각 스트림은 고유한 식별자를 가지며, 독립적으로 데이터를 전송하고 제어한다. 이는 HTTP/2가 TCP 위에서 시도했던 멀티플렉싱과 근본적으로 다르다. HTTP/2의 멀티플렉싱은 단일 TCP 연결 내에서 여러 HTTP 스트림을 교차하여 전송하지만, 패킷 손실이 발생하면 손실된 패킷의 재전송이 완료될 때까지 연결 내의 *모든* 스트림의 처리가 지연되는 HOL 블로킹 문제를 겪는다.

QUIC의 UDP 기반 멀티플렉싱은 이 문제를 해결한다. 하나의 스트림에서 패킷 손실이 발생해도, 해당 스트림에 필요한 재전송 및 복구 절차만 진행된다. 다른 스트림들의 데이터는 영향을 받지 않고 계속 처리되어 애플리케이션 레이어로 전달될 수 있다. 이는 특히 지연에 민감한 웹 페이지 로딩 환경에서 상당한 성능 향상을 가져온다.

이러한 설계는 애플리케이션 데이터의 전송 효율성을 높이고, 네트워크 상태 변화에 더욱 탄력적으로 대응할 수 있게 한다.

QUIC 프로토콜은 보안을 핵심 설계 원칙으로 삼아, 전송 계층 보안 프로토콜인 TLS 1.3을 프로토콜 스택에 직접 통합하였다. 이는 기존의 TCP 기반 통신에서 TLS가 애플리케이션 계층에서 별도로 협상되고 처리되던 방식과 근본적으로 다르다. QUIC에서의 모든 패킷은 기본적으로 암호화되며, 평문 핸드셰이크는 초기 연결 설정을 위한 버전 협상 등 극히 일부 경우에만 허용된다[2].

이 통합 설계는 여러 보안 및 성능상의 이점을 제공한다. 첫째, TLS 1.3의 1-RTT 및 0-RTT 핸드셰이크를 활용하여 연결 설정 지연을 크게 줄인다. 특히, 이전에 서버에 연결한 적이 있는 클라이언트는 0-RTT 데이터를 즉시 전송할 수 있어 지연 시간을 최소화한다. 둘째, 프로토콜 헤더 정보 대부분이 암호화되어, 네트워크 경로상의 중간 장치가 패킷의 메타데이터(예: 패킷 번호)를 엿보거나 불법적으로 조작하는 것을 방지한다. 이는 프라이버시 강화와 프로토콜 오싱 저항성을 높인다.

통합된 보안 모델은 또한 프로토콜의 진화를 용이하게 한다. 암호화된 페이로드 내부의 프레임 포맷은 서버와 클라이언트 간의 독립적인 업데이트가 가능하여, 중간 박스에 의한 프로토콜 차단 문제를 완화한다. 결과적으로, QUIC은 보안을 선택 사항이 아닌 필수 요소로 만들어, 웹 트래픽의 기본적인 암호화를 보장하는 방향으로 인터넷 생태계를 이끈다.

QUIC 연결은 5튜플(원본 IP, 목적지 IP, 원본 포트, 목적지 포트, 전송 프로토콜) 대신 연결 ID라는 개념을 사용하여 식별합니다. 각 엔드포인트는 연결 설정 과정에서 하나 이상의 연결 ID를 선택하고 상대방에게 제공합니다. 이 연결 ID는 네트워크 계층의 주소 정보와 분리되어 있습니다.

이 설계 덕분에 클라이언트의 네트워크가 변경되어도(예: Wi-Fi에서 셀룰러 네트워크로 전환) 기존 연결을 유지할 수 있습니다. 클라이언트는 새로운 네트워크 경로에서도 동일한 연결 ID를 사용하여 패킷을 전송할 수 있으며, 서버는 패킷의 연결 ID를 통해 이를 기존 연결로 인식하고 처리합니다. 이 과정에서 추가적인 핸드셰이크나 연결 재설정이 필요하지 않습니다.

이러한 연결 마이그레이션 기능은 모바일 환경에서 특히 유용합니다. 사용자가 이동 중에 네트워크 접속점이 바뀌어도 HTTP 세션이나 스트리밍 연결이 끊기지 않고 지속될 수 있습니다. 이는 TCP 기반 연결이 네트워크 인터페이스의 IP 주소가 바뀌면 필연적으로 재설정되어야 했던 근본적인 한계를 극복한 것입니다.

QUIC 프로토콜의 데이터 단위는 패킷과 프레임의 계층적 구조로 구성된다. 최상위 계층인 패킷은 UDP 데이터그램에 캡슐화되어 전송되는 기본 단위이다. 각 QUIC 패킷은 헤더와 하나 이상의 프레임으로 이루어지며, 패킷 헤더에는 연결 식별자, 패킷 번호, 패킷 유형 등의 정보가 담긴다. 패킷 번호는 각 패킷에 고유하게 부여되어 혼잡 제어, 재전송, 보안 검증에 활용된다.

프레임은 패킷 내부에 실리는 실제 프로토콜 작업의 단위이다. 다양한 유형의 프레임이 정의되어 있으며, 각각 특정한 기능을 수행한다. 주요 프레임 유형은 다음과 같다.

이러한 구조 덕분에 QUIC는 단일 암호화된 연결 내에서 여러 논리적 데이터 스트림을 독립적으로 처리할 수 있다. 특히 STREAM 프레임은 스트림 ID, 오프셋, 데이터 길이, 그리고 실제 애플리케이션 데이터를 포함하여, 하나의 TCP 연결에서 발생하는 HOL 블로킹 문제를 해결하는 핵심 메커니즘을 제공한다.

QUIC는 TCP의 핵심 기능이었던 흐름 제어와 혼잡 제어를 계승 및 개선하여 구현한다. 두 메커니즘 모두 데이터 전송의 안정성과 효율성을 보장하지만, 서로 다른 목표를 가진다. 흐름 제어는 수신자의 버퍼 오버플로를 방지하기 위해 송신자의 데이터 전송 속도를 조절하는 반면, 혼잡 제어는 네트워크 자체의 포화 상태를 감지하고 이를 피하기 위해 전송 속도를 조절한다.

QUIC의 흐름 제어는 HTTP/2에서 사용된 창 기반 방식을 차용하지만, 스트림 수준과 연결 수준에서 독립적으로 적용된다는 점에서 더욱 세분화된다. 각 스트림은 자신의 흐름 제어 창을 가지므로, 한 스트림이 블록되어도 다른 스트림의 데이터 전송에는 영향을 미치지 않는다. 이는 HTTP/2의 HOL 블로킹 문제를 애플리케이션 계층에서 해결한 것과 유사한 원리를 전송 계층에 적용한 것이다. 수신자는 MAX_STREAM_DATA 프레임을 통해 특정 스트림의 창 크기를 증가시켜 추가 데이터 수신을 허용한다.

혼잡 제어 측면에서 QUIC는 새로운 알고리즘을 강제하지 않으며, 다양한 알고리즘을 구현할 수 있는 프레임워크를 제공한다. 표준 구현은 일반적으로 TCP의 CUBIC 또는 BBR과 같은 현대적인 혼잡 제어 알고리즘을 채택한다. QUIC의 주요 혁신은 각 연결에 고유한 연결 ID를 사용함으로써, 네트워크 경로가 변경되더라도(예: Wi-Fi에서 셀룰러로 전환) 혼잡 제어 상태를 유지할 수 있다는 점이다. TCP의 경우 경로 변경이 새로운 연결로 인식되어 혼잡 창을 처음부터 다시 시작해야 하지만, QUIC는 기존의 혼잡 상태를 이어갈 수 있어 성능 저하를 줄인다.

다음은 QUIC의 흐름 제어와 혼잡 제어의 주요 특징을 비교한 표이다.

또한 QUIC의 모든 패킷은 암호화되어 있으며, 심지어 혼잡 제어에 사용되는 ACK 패킷조차도 암호화된다. 이는 중간 네트워크 노드가 패킷 유실을 은폐하거나 악의적으로 ACK를 조작하는 것을 훨씬 더 어렵게 만든다[3]. 결과적으로, 혼잡 제어 알고리즘의 발전과 배포가 더욱 자유로워질 수 있는 기반을 마련한다.

QUIC 프로토콜은 TCP와 TLS를 사용하는 기존 HTTP/2 스택에 비해 여러 측면에서 지연 시간을 크게 줄인다. 가장 큰 개선점은 연결 설정에 필요한 왕복 횟수를 최소화하는 것이다. 기존 HTTPS 연결은 TCP 핸드셰이크(1-RTT)와 TLS 핸드셰이크(1~2 RTT)를 순차적으로 수행해야 했지만, QUIC은 TLS 1.3을 프로토콜에 통합하여 처음 연결 시 1-RTT, 재연결 시 0-RTT 핸드셰이크를 가능하게 한다. 이는 첫 번째 데이터 패킷을 보내는 시간을 상당히 앞당긴다.

또한, 멀티플렉싱 방식에서 발생하는 HOL 블로킹 문제를 해결하여 지연을 감소시킨다. HTTP/2는 단일 TCP 연결 내에서 여러 스트림을 멀티플렉싱하지만, 패킷 하나가 손실되면 해당 패킷의 재전송이 완료될 때까지 연결 내 모든 스트림의 처리가 지연되었다. QUIC은 UDP 위에서 독자적인 스트림을 구현하며, 각 스트림이 독립적으로 프레임을 전송하고 관리한다. 따라서 한 스트림의 패킷 손실이 다른 스트림에 영향을 미치지 않아 전체적인 응답성이 향상된다.

이러한 설계는 특히 불안정한 모바일 네트워크 환경에서 더 큰 효과를 발휘한다. 네트워크가 Wi-Fi에서 셀룰러 데이터로 전환되는 경우, QUIC의 연결 마이그레이션 기능은 새로운 IP 주소로 연결을 유지하며 재협의 없이 통신을 계속할 수 있게 한다. 이는 다시 연결 설정을 수행해야 하는 기존 방식에 비해 중단 시간을 제거한다. 결과적으로 사용자에게는 페이지 로드 시간 단축, 실시간 애플리케이션의 반응성 향상 등의 형태로 체감 지연 시간 감소가 나타난다.

QUIC의 핵심 장점 중 하나는 TCP와 TLS를 사용하는 기존 HTTPS 연결에 비해 연결 설정 속도가 현저히 빠르다는 점이다. 기존 방식에서는 신뢰성 있는 연결을 수립하기 위한 TCP 3-way 핸드셰이크와 보안 연결을 위한 TLS 핸드셰이크가 순차적으로 이루어져야 했다. 이 과정은 최소 2~3회의 왕복 지연(RTT)을 필요로 하여 초기 연결 지연을 발생시켰다.

QUIC은 이러한 문제를 해결하기 위해 TLS 1.3을 프로토콜 스택에 통합하고 핸드셰이크 과정을 최적화했다. QUIC 연결은 첫 번째 핸드셰이크 패킷부터 암호화된 페이로드를 포함할 수 있으며, 연결 설정과 보안 설정이 병렬적으로 진행된다. 결과적으로 대부분의 경우 단 1회의 왕복 지연(1-RTT)만으로 암호화된 데이터 전송을 시작할 수 있다. 심지어 이전에 서버와 연결한 적이 있는 클라이언트는 0-RTT 핸드셰이크를 통해 첫 번째 패킷부터 응용 프로그램 데이터를 보낼 수 있다[5].

이러한 빠른 연결 설정은 웹 페이지 로딩 시간을 단축시키고, 특히 짧은 트랜잭션이 많은 애플리케이션의 성능을 향상시킨다. 모바일 환경에서 네트워크가 자주 변경되거나 불안정한 상황에서도 재연결 시 발생하는 지연을 최소화하는 데 큰 도움이 된다.

2020년대 초반부터 주요 웹 브라우저와 서버 소프트웨어는 HTTP/3와 그 하위 전송 프로토콜인 QUIC에 대한 지원을 본격적으로 도입하기 시작했다. 이 지원은 표준화 과정과 병행하여 점진적으로 확대되었다.

서버 측에서는 CDN 업체들이 가장 적극적으로 선도했다. Cloudflare와 Google Cloud는 2020년에 상용 지원을 시작했으며, 이후 대부분의 주요 CDN 업체들이 따라갔다. 웹 서버 소프트웨어의 경우, nginx가 2021년 공식 모듈을 통해 지원을 추가했으나, 기본 빌드에는 포함되지 않아 별도 구성이 필요하다. Apache HTTP Server는 공식 지원보다는 실험적 모듈을 통한 지원 경로를 취하고 있다.

운영체제 및 라이브러리 수준에서는 curl 라이브러리가 2020년부터, Linux 커널의 통합 지원은 아직 진행 중이다. 이러한 지원 확대는 IETF의 QUIC 및 HTTP/3 표준이 2022년에 RFC 9000 시리즈로 최종 확정된 것과 궤를 같이한다.

QUIC 프로토콜은 기존 TCP 기반의 TLS 암호화 트래픽과 달리 UDP를 전송 계층으로 사용하며, 패킷 페이로드 전체를 암호화합니다. 이 설계는 보안과 성능을 향상시키지만, 네트워크 경로상에 위치한 중간 장비들이 패킷 내용을 검사하거나 최적화하는 데 어려움을 초래합니다[8].

기존 TCP/TLS 환경에서는 방화벽, 로드 밸런서, 침입 탐지 시스템(IDS), 딥 패킷 인스펙션(DPI) 장비 등이 특정 포트(예: 443)나 패킷 헤더의 정보를 통해 트래픽을 식별하고 정책을 적용하거나 모니터링할 수 있었습니다. 그러나 QUIC은 연결 설정 핸드셰이크부터 페이로드까지 광범위하게 암호화하므로, 이러한 장비들은 패킷이 QUIC 트래픽인지 식별하는 것 외에는 내부 정보를 알 수 없게 됩니다. 이로 인해 다음과 같은 운영상의 과제가 발생합니다.

이러한 투명성 문제를 해결하기 위해, IETF QUIC 워킹 그룹은 장비 제조사 및 네트워크 운영자와 협력하여 표준화를 진행하고 있습니다. 일부 접근법은 QUIC 연결의 초기 패킷에 장비가 필요한 최소한의 메타데이터(예: 연결 ID)를 포함시키거나, 네트워크 운영자를 위한 제어 채널을 별도로 정의하는 방안을 고려하고 있습니다. 그러나 이는 보안과 프라이버시 목표와 상충될 수 있어 신중한 설계가 요구됩니다. 결과적으로, QUIC의 광범위한 도입은 네트워크 인프라의 운영 패러다임이 '내용 검사'에서 '연결 메타데이터 기반 관리'로 점진적으로 전환되도록 요구합니다.