📄
HTTP/1.1 (1997년)
지금도 널리 쓰이는 기본 형태의 HTTP로, 연결을 재사용하는 Keep-Alive 기능이 도입되어 매 요청마다 새로 연결을 맺어야 했던 HTTP/1.0의 비효율을 개선했습니다.
다만 한 연결 안에서 요청을 보내면 응답이 올 때까지 다음 요청을 보낼 수 없는 순차 처리 구조라, 브라우저는 이를 우회하기 위해 한 사이트에 여러 개의 연결(보통 6개 안팎)을 동시에 열어 여러 리소스를 병렬로 받는 방식을 써왔습니다. 이 방식은 연결 수가 늘어날수록 서버와 네트워크에 부담을 줍니다.
🚧
HTTP/1.1의 한계: 헤드 오브 라인(HOL) 블로킹
한 연결에서 앞선 요청의 응답이 늦어지면 뒤에 대기 중인 요청까지 모두 지연되는 현상을 헤드 오브 라인 블로킹이라고 합니다.
이미지, CSS, JS 파일이 많은 현대 웹페이지에서는 이 지연이 누적되어 전체 로딩 속도에 영향을 줍니다. 브라우저가 여러 연결을 동시에 여는 것도 결국 이 문제를 임시로 우회하기 위한 방편이었으며, 근본적인 해결은 HTTP/2에서 이뤄집니다.
🔀
HTTP/2 (2015년)
요청과 응답을 작은 바이너리 프레임으로 쪼개 하나의 연결 위에서 여러 스트림을 동시에 주고받는 멀티플렉싱을 도입해 HOL 블로킹 문제를 크게 줄였습니다.
텍스트 기반이던 HTTP/1.1과 달리 바이너리 프레이밍 계층을 사용하고, 반복되는 헤더 정보를 압축하는 HPACK 기술로 오버헤드를 줄였습니다. 서버가 클라이언트 요청 없이도 필요할 리소스를 미리 보내주는 "서버 푸시" 기능도 도입되었지만, 실효성 논란으로 최신 브라우저 대부분에서는 지원이 중단되었습니다.
🧱
HTTP/2도 완전히 해결하지 못한 문제
HTTP/2는 애플리케이션 계층의 HOL 블로킹은 해결했지만, 그 아래 TCP 계층에서 패킷 손실이 생기면 여전히 모든 스트림이 함께 지연됩니다.
TCP는 데이터를 순서대로 전달해야 하는 프로토콜이라, 하나의 연결 위에서 여러 스트림을 함께 보내다가 패킷 하나가 유실되면 재전송이 끝날 때까지 같은 연결의 다른 모든 스트림도 기다려야 합니다. 이 TCP 계층의 한계는 프로토콜을 아예 UDP 기반으로 바꾼 HTTP/3에서 해결됩니다.
⚡
HTTP/3와 QUIC (2022년 표준화)
TCP 대신 UDP 위에서 동작하는 구글 개발의 QUIC 프로토콜을 기반으로 하여, 한 스트림의 패킷 손실이 다른 스트림에 영향을 주지 않도록 설계되었습니다.
QUIC은 TCP와 TLS 암호화 과정을 통합해 연결을 맺는 데 걸리는 왕복 횟수를 줄이고, 이미 접속한 적 있는 서버에는 0-RTT(왕복 없이 즉시 데이터 전송)로 더 빠르게 재연결할 수 있습니다. 또한 스트림마다 독립적으로 순서를 관리해 진짜 의미의 멀티플렉싱을 구현했습니다.
🔍
내가 보는 사이트가 어떤 버전을 쓰는지 확인하는 법
크롬·엣지 등 브라우저의 개발자 도구(F12)에서 네트워크 탭을 열고 프로토콜(Protocol) 열을 추가하면 각 요청이 h1.1·h2·h3 중 무엇을 썼는지 바로 확인할 수 있습니다.
네트워크 탭에서 열 머리글을 마우스 오른쪽 버튼으로 클릭해 "Protocol" 항목을 체크하면 열이 추가됩니다. 대부분의 대형 웹사이트와 CDN은 이미 HTTP/2를, 상당수는 HTTP/3까지 지원하고 있으며, 서버와 클라이언트가 모두 지원하는 가장 높은 버전이 자동으로 협상되어 사용됩니다.
📊
실제로 체감할 수 있는 속도 차이
이미지·스크립트가 많은 복잡한 페이지에서는 HTTP/2·3의 이점이 뚜렷하지만, 리소스가 하나뿐인 단순한 요청은 버전 차이를 체감하기 어렵습니다.
이커머스나 뉴스 사이트처럼 수십~수백 개의 파일을 동시에 불러오는 페이지일수록 멀티플렉싱과 헤더 압축의 효과가 크게 나타납니다. 반대로 API 서버에 단일 요청 하나만 보내는 경우처럼 병렬로 받을 리소스가 적다면 버전에 따른 체감 속도 차이는 크지 않을 수 있습니다.