한양과기고 에듀테크 수업도구 대시보드

HTTP의 진화 — 1.1 → 2 → 3

웹 페이지 하나를 열면 브라우저는 HTML·CSS·JS·이미지 등 수십 개의 파일을 서버에서 받아와야 한다. HTTP/1.1은 연결 하나에서 요청을 한 줄로 세워 처리해서, 앞 요청이 끝나야 다음이 시작된다 (Head-of-Line 블로킹). 브라우저는 이걸 연결 6개를 동시에 열어 버텼다. HTTP/2는 연결 하나에서 요청들을 잘게 쪼개 동시에 실어 나른다(멀티플렉싱). 대신 그 밑의 TCP가 패킷 하나만 잃어버려도 모든 스트림이 함께 멈춘다. HTTP/3는 아예 TCP를 버리고 UDP 위의 QUIC으로 갈아타, 잃어버린 패킷이 속한 그 스트림 하나만 기다린다.

로딩 시뮬레이터 — 같은 페이지를 세 버전으로

파일 수 12 패킷 손실 발생

– 현재 버전 로드 완료

같은 조건 비교 HTTP/1.1 – HTTP/2 – HTTP/3 –

버전 탭을 바꾸거나 다시 로드를 눌러 워터폴을 비교해 보세요. 단위는 상대적인 시간이며, RTT(왕복 지연)를 1로 잡았습니다.

패킷 하나를 잃으면 — HoL 블로킹의 위치

HTTP/1.1: 연결 6개가 서로 독립이라, 패킷을 잃은 그 연결에 걸린 파일들만 재전송을 기다린다. 다만 애초에 요청을 6줄로 세우느라 전체가 느리다.
HTTP/2: 연결이 딱 하나. TCP는 "바이트를 순서대로" 넘겨주므로, 중간 패킷 하나가 빠지면 뒤에 이미 도착한 다른 스트림의 데이터까지 애플리케이션에 전달되지 못하고 대기한다 → TCP HoL 블로킹. 시뮬레이터에서 손실을 켜면 모든 막대가 동시에 빨간 줄무늬(재전송 대기)로 멈춘다.
HTTP/3 (QUIC): 스트림별로 순서를 따로 관리한다. 잃어버린 패킷이 속한 스트림만 멈추고, 나머지는 계속 받는다. 손실을 켜도 막대 하나만 빨갛게 멈춘다.

한눈에 비교

항목	HTTP/1.1 (1997)	HTTP/2 (2015)	HTTP/3 (2022)
전송 계층	TCP	TCP	QUIC (UDP 위)
한 연결의 동시 요청	1개 (직렬)	다중 (멀티플렉싱)	다중 (멀티플렉싱)
브라우저가 여는 연결 수	도메인당 ~6	1	1
HTTP 레벨 HoL	있음	없음	없음
전송 레벨(TCP) HoL	있음	있음	없음
헤더 압축	없음	HPACK	QPACK
연결 수립 비용	TCP 1-RTT (+TLS 2-RTT)	TCP 1-RTT (+TLS 1~2-RTT)	1-RTT · 재방문 0-RTT
Wi-Fi↔LTE 전환	연결 끊김	연결 끊김	연결 ID로 유지 (마이그레이션)
서버 푸시	없음	있음 (사실상 폐기)	없음

HTTP/2가 "서버 푸시"로 리소스를 미리 밀어주려 했지만 캐시와 잘 안 맞아 크롬이 2022년에 지원을 뺐다. 요즘은 103 Early Hints 나 <link rel="preload"> 로 대체한다.

내 브라우저는 몇 버전을 쓸까

# curl 로 협상 결과 확인 (HTTP/2)
curl -I --http2 https://offset0xf.com
#  → HTTP/2 200  이면 h2 로 협상됨

# HTTP/3 시도 (curl 이 QUIC 지원 빌드여야 함)
curl -I --http3 https://www.google.com

# 서버가 HTTP/3 를 알리는 응답 헤더
alt-svc: h3=":443"; ma=86400

크롬 개발자도구 → Network 탭에서 우클릭 → Protocol 열을 켜면 파일마다 h2·h3·http/1.1 이 보인다.
버전은 협상된다. TLS 핸드셰이크의 ALPN 확장에서 브라우저가 h2·http/1.1 목록을 보내고 서버가 하나를 고른다. HTTP/3 는 먼저 h2 로 붙은 뒤 alt-svc 를 보고 다음 접속부터 QUIC 로 전환한다.
HTTP/2 부터는 사실상 HTTPS 필수 — 평문 h2(h2c)를 지원하는 브라우저는 없다.