HTTP/3란? 유튜브가 빨라진 진짜 이유

크롬 개발자도구 Network 탭을 켰더니 프로토콜 칸에 h3라고 찍혀 있다. 아니면 VPN이 HTTP/3를 지원하지 않는다는 글을 어디서 읽고 찾아봤을 거다. 알고 보면 이게 유튜브가 왜 예전보다 빨라졌는지, 왜 와이파이 끊겨도 영상이 이어지는지 전부 연결된 이야기다.

유튜브에서 영상 보다가 와이파이 끊기면 어떻게 되는지 기억날 것이다. 예전엔 LTE로 전환되는 순간 버퍼링이 걸리거나, 아예 새로고침을 해야 했다.

요즘은 그냥 이어진다. 와이파이에서 LTE로, LTE에서 와이파이로 — 끊김 없이.

이게 HTTP/3 덕분이다.

HTTP가 뭔데

HTTP는 브라우저가 서버에서 웹페이지를 가져오는 규칙이다. 주소창에 URL을 치면, 브라우저가 “이 페이지 데이터 보내줘”라고 서버에 요청을 보내고, 서버가 응답하는 — 그 대화 방식의 규칙이 HTTP다.

1997년에 나온 HTTP/1.1은 한 번에 하나씩만 요청을 처리했다. 웹페이지에 이미지가 10개면, 하나 받고 → 다음 하나 받고 → 또 다음 하나. 줄 서서 기다리는 구조다.

2015년에 나온 HTTP/2는 이걸 개선했다. 한 번에 여러 요청을 동시에 보내는 게 가능해졌다. 근데 한 가지 근본적인 한계가 있었다.

HTTP/2의 문제 — 하나가 막히면 전부 멈춘다

HTTP/2는 TCP라는 전송 기술 위에서 동작한다. TCP(Transmission Control Protocol)는 인터넷에서 데이터를 주고받는 가장 기본적인 방식인데, 핵심 특징은 “순서 보장”이다. 1번 → 2번 → 3번 순서대로 데이터를 보내면, 받는 쪽도 반드시 1 → 2 → 3 순서대로 받는다.

문제는, 2번이 중간에 유실되면 3번도 기다려야 한다는 거다.

유튜브 영상을 보면서 동시에 댓글을 로딩하는 상황을 생각해 보겠다. HTTP/2에서는 영상 데이터랑 댓글 데이터가 같은 TCP 연결을 공유한다. 영상 데이터 조각 하나가 유실되면? 댓글 데이터도 같이 멈춘다. 댓글은 영상이랑 아무 상관 없는데도.

이걸 Head-of-Line Blocking(줄 맨 앞이 막히면 뒤가 전부 서는 현상)이라고 한다.

모바일에서 특히 문제다. 와이파이 신호가 약해지거나, 지하철에서 기지국이 바뀌거나 — 패킷 유실이 잦은 환경에서 TCP의 “순서 보장” 특성이 오히려 발목을 잡는다.

HTTP/3가 바꾼 것 — QUIC

HTTP/3는 TCP를 버렸다. 대신 QUIC라는 새로운 프로토콜을 쓴다.

QUIC는 UDP(User Datagram Protocol) 위에서 동작한다. UDP는 TCP와 달리 순서 보장을 하지 않는다. “일단 보내고 본다”는 방식이다. 이렇게만 들으면 불안하게 느껴지지만, QUIC가 UDP 위에 자체적으로 신뢰성 기능을 얹었다.

핵심은 이거다. QUIC에서는 영상 데이터와 댓글 데이터가 완전히 독립적인 스트림(흐름)으로 처리된다. 영상 데이터 조각 하나가 유실돼도, 댓글 데이터는 영향을 받지 않고 계속 흘러간다.

하나가 막혀도 나머지는 멈추지 않는다.

와이파이에서 LTE로 바꿔도 안 끊기는 이유

TCP는 연결을 IP 주소로 식별한다. 와이파이에서 LTE로 전환하면 IP가 바뀐다. IP가 바뀌면 TCP 입장에서는 “다른 사람”이 된 거라, 연결을 처음부터 다시 맺어야 한다. 그래서 끊겼던 거다.

QUIC는 Connection ID라는 별도의 식별자를 쓴다. IP가 바뀌어도 Connection ID가 같으면 “같은 연결”로 인식한다. 그래서 와이파이 → LTE 전환이 일어나도, 유튜브 영상이 끊기지 않고 이어지는 거다.

Google이 QUIC를 처음 만든 이유가 이거다. 모바일 환경에서 YouTube 재생 품질을 올리기 위해서.

첫 접속도 빠르다 — 0-RTT

웹사이트에 처음 접속할 때, 브라우저와 서버는 “악수(handshake)“를 한다. “나 이런 암호화 방식 쓸 수 있어” → “좋아, 그럼 이걸로 하자” → “확인” — 이 과정이 TCP + TLS에서는 2~3번 왕복(RTT, Round Trip Time)이 필요하다.

QUIC는 이걸 1번으로 줄였다. 암호화(TLS 1.3)가 프로토콜 자체에 내장돼 있어서, 연결 설정과 암호화 설정을 동시에 처리한다.

한번 방문했던 사이트는 더 빠르다. 0-RTT — 왕복 없이 바로 데이터를 보낸다. 이전 방문에서 저장된 정보를 재사용하기 때문이다. 체감 로딩 속도에서 가장 큰 차이가 나는 부분이다.

실제로 얼마나 빨라지나

Cloudflare의 2023년 측정 결과를 보면, 패킷 손실 1% 환경(모바일에서 흔한 수준)에서 HTTP/3가 HTTP/2보다 약 30% 빠르다. 첫 방문 페이지 로딩은 약 10~15% 개선되고, 재방문 시 0-RTT 덕분에 차이가 더 벌어진다.

2024년 기준 전체 웹 트래픽의 약 30%가 이미 HTTP/3로 처리되고 있다. Google, YouTube, Facebook, Instagram, Cloudflare를 쓰는 수많은 사이트들 — 일상적으로 접속하는 대부분의 서비스가 이미 HTTP/3다.

그래서 내가 뭘 해야 하나

솔직하게 말하면 — 거의 없다.

Chrome, Firefox, Safari, Edge 모두 HTTP/3를 이미 지원한다. 브라우저가 서버와 자동으로 협상해서, 서버가 HTTP/3를 지원하면 HTTP/3로 연결하고, 아니면 HTTP/2로 연결한다. 사용자가 설정을 바꾸거나 뭔가를 설치할 필요가 없다.

궁금하면 확인하는 방법은 있다. Chrome 주소창에 chrome://flags/#enable-quic를 입력하면 QUIC 설정 상태를 볼 수 있다. 기본값이 “Enabled”로 되어 있을 거다.

HTTP/3는 “사용자가 뭘 해야 하는 기술”이 아니라, “알아서 적용돼 있는 기술”이다. 유튜브가 예전보다 빨라졌다고 느꼈다면 — 그 체감의 일부가 HTTP/3 덕분이다.