TLS 성능: QUIC와 HTTP/3

HTTP/2는 하나의 TCP 연결을 통해 여러 스트림을 다중화하여 HTTP/1.1의 연결별 선두 차단 문제를 해결합니다. 그러나 TCP 자체는 전송 계층에서 선두 차단을 일으킵니다. TCP 세그먼트 하나가 손실되면 큐에서 그 뒤에 있는 모든 데이터가 재전송을 기다리므로 모든 HTTP/2 스트림이 동시에 차단됩니다. 패킷 손실률이 1%만 되어도 여러 연결을 사용하는 HTTP/1.1보다 HTTP/2의 성능이 저하될 수 있습니다. QUIC(빠른 UDP 인터넷 연결)는 UDP 위에 다중화된 스트림을 구현하여 이 문제를 해결합니다. 스트림 수준의 손실 복구가 다른 스트림을 차단하지 않기 때문입니다.

QUIC는 UDP를 기반으로 구축된 전송 프로토콜로, Google이 2012년부터 2015년까지 개발했으며 IETF가 RFC 9000(2021)으로 표준화했습니다. QUIC는 TLS 1.3을 전송 계층에 통합하므로 QUIC 위에서 별도의 TLS 핸드셰이크가 수행되지 않습니다. TLS가 QUIC 핸드셰이크 자체에 결합되어 있습니다. QUIC는 선두 차단이 없는 다중화된 스트림, 연결 마이그레이션(예: WiFi에서 LTE로 전환할 때 연결을 유지하는 기능), 반복 연결을 위한 0-RTT 연결 설정, 내장된 손실 감지 및 혼잡 제어를 제공합니다. HTTP/3(RFC 9114)는 QUIC 스트림 위에서 동작하는 HTTP 의미론입니다.

QUIC 핸드셰이크는 연결 설정과 TLS 협상을 결합합니다. 첫 번째 전송에서(QUIC 용어로 0 RTT) 클라이언트는 TLS ClientHello를 포함한 Initial 패킷을 보냅니다. 서버는 자체 Initial(ServerHello)과 함께 Handshake 패킷(암호화된 확장, 인증서, Finished)을 응답으로 보냅니다. 클라이언트는 Handshake Finished를 보내고 애플리케이션 데이터를 전송할 준비가 됩니다. 이를 1-RTT라고 합니다. 0-RTT 연결에서는 클라이언트가 이전 세션의 재개 비밀에서 파생된 키를 사용하여 ClientHello와 함께 0-RTT 패킷(애플리케이션 데이터)을 보내므로 캐시된 세션에서 추가 왕복이 전혀 필요하지 않습니다.

QUIC는 TLS 키 스케줄 단계에 대응하는 네 가지 서로 다른 암호화 수준을 사용합니다. Initial은 알려진 상수 키를 사용하는 QUIC 파생 AEAD로, 무결성을 제공하지만 정교한 공격자에 대한 기밀성은 제공하지 않습니다. Handshake는 TLS handshake_secret에서 파생되며 TLS 핸드셰이크 메시지의 기밀성을 제공합니다. 0-RTT는 이전 세션의 early_secret에서 파생되어 0-RTT 애플리케이션 데이터를 암호화합니다. 1-RTT는 TLS master_secret에서 파생되어 모든 애플리케이션 데이터를 암호화합니다. QUIC 헤더는 부분적으로 암호화됩니다. 패킷 번호와 페이로드는 암호화되지만 일부 라우팅 정보(Connection ID)는 부하 분산기를 위해 계속 표시됩니다.

QUIC 연결은 4-튜플(출발지 IP, 출발지 포트, 목적지 IP, 목적지 포트)이 아니라 Connection ID(CID)로 식별됩니다. 따라서 네트워크가 변경되어도 연결을 유지할 수 있습니다. 모바일 클라이언트가 WiFi에서 LTE로 전환하면 IP 주소는 바뀌지만 CID는 그대로 유지됩니다. 클라이언트는 새 경로에서 PATH_CHALLENGE 프레임을 보내고, 서버는 PATH_RESPONSE로 응답하여 새 주소를 검증합니다. 재협상 없이 연결이 원활하게 계속됩니다. TCP에서는 이를 지원할 수 없습니다. TCP 연결은 4-튜플에 묶여 있으므로 네트워크가 변경되면 다시 설정해야 하며, 이때 새 TLS 핸드셰이크가 필요합니다. QUIC 마이그레이션은 모바일 사용자가 체감하는 성능을 크게 향상합니다.

HTTP/3는 HTTP 의미론을 QUIC 스트림에 매핑합니다. 각 HTTP 요청-응답 쌍은 별도의 양방향 QUIC 스트림을 사용합니다. QUIC 스트림은 서로 독립적이므로 스트림 3의 손실이 스트림 7을 차단하지 않습니다. HTTP/3는 헤더 압축에 QPACK을 사용하며, 이는 HTTP/2의 HPACK을 대체합니다. QPACK은 순서가 보장된 전달을 요구하지 않도록 다시 설계되었습니다. 두 개의 전용 단방향 제어 스트림은 설정과 디코더/인코더 명령을 전달합니다. HTTP/3의 서버 푸시는 단방향 푸시 스트림을 사용합니다. 전체적으로 HTTP/3는 TCP의 선두 차단이 가장 큰 피해를 주는 패킷 손실 환경(모바일 네트워크, 혼잡한 경로)에서 HTTP/2보다 특히 뛰어난 성능을 보입니다.

실제 환경에서 QUIC와 HTTP/3의 성능을 측정한 결과는 네트워크 조건에 따라 엇갈립니다. 품질이 높은 네트워크(낮은 지연 시간, 낮은 패킷 손실)에서는 HTTP/3와 HTTP/2의 성능이 비슷합니다. QUIC의 오버헤드(더 큰 헤더와 UDP 처리 오버헤드) 때문에 HTTP/3가 오히려 약간 느려질 수도 있습니다. 손실이 있는 네트워크(패킷 손실률 1% 초과, 모바일 및 위성 네트워크에서 흔함)에서는 HTTP/3가 HTTP/2보다 크게 뛰어난 성능을 보입니다. Google은 YouTube를 QUIC로 전환했을 때 재버퍼링이 7~8% 감소했다고 보고했습니다. Facebook(Meta)은 QUIC를 사용하는 Instagram 피드에서 요청 지연 시간이 7~15% 개선되었다고 보고했습니다. 이러한 이점은 TCP 재전송으로 인한 멈춤의 영향이 가장 크게 나타나는 꼬리 지연 시간(p95, p99)에서 가장 뚜렷합니다.

QUIC는 UDP 기반이고 무상태 UDP 부하 분산기는 연결 고정성을 제공할 수 없으므로, QUIC의 부하 분산은 TCP보다 복잡합니다. IETF 초안 draft-ietf-quic-load-balancers는 다음과 같은 방식을 정의합니다. 서버가 Connection ID에 라우팅 정보를 인코딩하면 부하 분산기가 연결별 상태를 추적하지 않고도 같은 연결의 패킷을 동일한 서버로 라우팅할 수 있습니다. Connection ID에는 부하 분산기와 서버가 공유하는 키를 사용해 암호화된 서버 ID가 포함됩니다. Cloudflare, Fastly, Nginx는 이 방식의 변형을 구현합니다. NAT 통과도 고려해야 할 사항입니다. QUIC 연결은 연결 마이그레이션 메커니즘을 통해 NAT 재바인딩을 견뎌야 합니다.

주요 CDN은 대규모 환경에 QUIC와 HTTP/3를 배포했습니다. Cloudflare는 2019년부터 HTTP/3를 제공해 왔으며, 클라이언트와 서버 모두 지원하는 경우 트래픽의 약 20%가 QUIC를 사용한다고 보고합니다. Fastly, Akamai, AWS CloudFront는 엣지에서 HTTP/3를 지원합니다. Google 자체 인프라(Search, YouTube, Gmail)는 2013년부터 내부적으로 QUIC를 사용해 왔고, 현재는 HTTP/3를 공개적으로 제공합니다. CDN 배포에서는 QUIC의 0-RTT 재개 기능을 활용할 수 있습니다. 재방문자는 더 빠르게 연결을 설정하고, 연결 마이그레이션은 콘텐츠를 전송하는 동안 모바일 사용자가 액세스 지점 사이를 이동할 때 성능을 향상합니다.

QUIC의 UDP 기반 설계에는 몇 가지 고유한 보안 고려 사항이 있습니다. 증폭 공격의 경우 공격자가 출발지 IP를 위조하여 작은 Initial 패킷을 보내면 서버가 피해자에게 큰 Handshake 응답을 보내도록 만들 수 있습니다. QUIC는 주소 검증이 완료될 때까지(RETRY 메커니즘을 통해) 서버 응답을 수신한 데이터의 3배로 제한하여 이를 완화합니다. 연결 폭주를 방지하려면 QUIC 서버가 동일한 IP에서 오는 새 연결 시도를 속도 제한해야 합니다. 버전 협상 공격은 암호학적으로 보호되는 핸드셰이크에 버전을 포함하여 방지합니다. QUIC의 내장 암호화로 인해 검사 장비는 서버 인증서를 사용해 경로상에 위치하지 않는 한 QUIC 페이로드를 분석할 수 없습니다. 따라서 검사가 가능한 TCP 트래픽보다 개인정보 보호 수준이 향상됩니다.

HTTP/3를 배포하려면 다음이 필요합니다. (1) QUIC를 지원하는 서버(nginx 1.25 이상, Caddy, HAProxy 2.6 이상, LiteSpeed 또는 quic-go, aioquic, ngtcp2 라이브러리를 통한 애플리케이션 수준 구현). (2) 방화벽에서 UDP 포트 443 개방. 많은 기업 방화벽이 UDP 443을 차단하므로 QUIC가 TCP/TLS로 전환될 수 있습니다. (3) Alt-Svc 응답 헤더로 HTTP/3 지원을 알림: Alt-Svc: h3=":443"; ma=86400. 이를 통해 HTTP/2 클라이언트가 업그레이드하도록 요청합니다. (4) QUIC를 인식하는 부하 분산기 또는 L4 UDP 통과. (5) 연결 마이그레이션 이벤트, 0-RTT 수락률, 프로토콜 대체 비율과 같은 QUIC별 지표 모니터링. HTTPS로 대체되는 점진적 배포를 사용하면 QUIC를 지원하지 않는 클라이언트에도 이 과정이 투명하게 처리됩니다.

QUIC는 TCP를 통한 HTTP/2에 영향을 주는 선두 차단 문제를 어떻게 해결하나요?

QUIC는 UDP 위의 전송 계층에 TLS 1.3을 통합하고, 스트림별 독립적인 손실 복구를 통해 TCP의 선두 차단을 제거합니다. Connection ID를 사용하면 재협상 없이 네트워크가 변경되어도 연결을 마이그레이션할 수 있습니다. HTTP/3는 QPACK 헤더 압축을 사용하여 HTTP를 QUIC 스트림에 매핑합니다. 0-RTT 연결 재개는 TLS 세션 비밀을 재사용합니다. QUIC는 패킷 손실이 있는 환경(모바일 네트워크, 혼잡한 네트워크)에서 HTTP/2보다 특히 뛰어난 성능을 보입니다. QUIC의 부하 분산을 위해서는 Connection ID에 서버 라우팅 정보를 인코딩해야 합니다. 배포에는 UDP 443, QUIC를 지원하는 서버, 프로토콜을 알리기 위한 Alt-Svc 헤더가 필요합니다.