Network · 완벽 가이드 Ch.4 §5

HTTP 버전의 진화에 대해서 설명해주세요 — HTTP/1.1 vs HTTP/2 vs HTTP/3

HTTP/1.1의 HoL Blocking 한계, HTTP/2의 멀티플렉싱과 HPACK 압축, HTTP/3의 QUIC 기반 혁신까지 — 각 버전이 이전 버전의 어떤 문제를 해결했는지 인터랙티브 시각화로 이해합니다.

2026년 3월 31일 · 약 14분 읽기

Q. "HTTP/1.1, HTTP/2, HTTP/3의 차이를 설명하고, 각 버전이 이전 버전의 어떤 문제를 해결했는지 말씀해주세요."

예상 꼬리질문

답변 가이드

"HTTP 프로토콜은 버전마다 이전 버전의 핵심 병목을 해결하는 방향으로 발전했습니다. HTTP/1.1은 Keep-Alive로 TCP 연결을 재사용할 수 있게 했지만, 한 응답이 지연되면 뒤의 모든 요청이 기다려야 하는 HoL Blocking(Head-of-Line Blocking) 문제가 있었습니다."

"HTTP/2는 바이너리 프레이밍과 멀티플렉싱(Multiplexing)을 도입해 하나의 TCP 연결에서 여러 요청을 병렬로 처리할 수 있게 했습니다. 또한 HPACK 헤더 압축으로 중복 헤더 전송을 제거해 평균 88% 헤더 크기를 줄였습니다. 하지만 TCP 패킷 손실 시 전체 스트림이 멈추는 TCP 레벨 HoL Blocking은 여전히 남아 있었습니다."

"HTTP/3는 TCP 대신 QUIC(UDP 기반) 프로토콜을 채택해 이 문제를 근본적으로 해결했습니다. 각 스트림이 완전히 독립적으로 동작하며, 0-RTT 연결로 재연결 시 핸드셰이크 없이 즉시 데이터를 전송할 수 있고, 연결 마이그레이션으로 Wi-Fi에서 모바일 데이터로 전환해도 연결이 유지됩니다."

면접관이 HTTP 버전을 물어볼 때 원하는 답은 "HTTP/2는 빠르고 HTTP/3는 더 빠르다"가 아닙니다. 각 버전이 어떤 문제를 발견했고, 어떤 기술로 해결했는지를 설명할 수 있어야 합니다.

이 아티클에서는 HTTP/1.1의 한계부터 HTTP/3의 QUIC 혁신까지, 인터랙티브 시각화로 직접 체험하며 이해할 수 있습니다.

1. HTTP/1.1의 한계 — HoL Blocking이란 무엇인가?

꼬리질문: "HTTP/1.1의 HoL Blocking이 무엇이고 왜 문제인가요?"

HTTP/1.1은 Keep-Alive로 TCP 연결을 재사용할 수 있게 했지만, 한 연결에서는 요청을 직렬로만 처리합니다. 앞선 응답이 늦어지면 뒤의 모든 요청이 대기해야 하는 HoL Blocking 문제가 발생합니다. 브라우저는 이를 우회하기 위해 도메인당 최대 6개의 병렬 TCP 연결을 사용했고, 이로 인해 도메인 샤딩(Domain Sharding)이라는 기법이 등장했습니다.

"시뮬레이션 시작" 버튼을 눌러 CSS가 느린 경우 HTTP/1.1과 HTTP/2의 처리 방식 차이를 비교해 보세요.

CSS(느린 응답)가 블락을 일으키는 상황 — HTML, CSS, JS 3개 리소스 요청

HTTP/1.1 (직렬)

HTML대기

CSS (느림)대기

JS대기

HTTP/2 (병렬 멀티플렉싱)

HTML대기

CSS (느림)대기

JS대기

HoL Blocking(Head-of-Line Blocking): HTTP/1.1에서 CSS(느린 응답)가 완료될 때까지 JS 요청은 실행조차 못하고 대기합니다. HTTP/2는 3개 요청이 동시에 시작되어 각자 완료되는 대로 처리됩니다.

HTTP/1.1 시절 성능 최적화의 핵심은 "요청 수 줄이기"였습니다. JS 파일 여러 개를 하나로 합치는 번들링(Bundling), 여러 이미지를 하나로 합치는 스프라이트(Sprite), 도메인을 나눠 병렬 연결을 늘리는 도메인 샤딩 등이 대표적입니다.

2. HTTP/2 — 멀티플렉싱과 바이너리 프레이밍

꼬리질문: "HTTP/2 멀티플렉싱이 HoL Blocking을 어떻게 해결하나요?"

HTTP/2의 가장 큰 혁신은 멀티플렉싱(Multiplexing)입니다. 하나의 TCP 연결 안에서 여러 스트림(Stream)을 동시에 처리합니다. 각 스트림은 고유한 ID를 가지고 독립적으로 데이터를 주고받을 수 있어, HTTP 레벨에서의 HoL Blocking이 사라집니다. 또한 텍스트 기반 프로토콜에서 바이너리 프레이밍(Binary Framing)으로 전환해 파싱 효율을 높였습니다.

"다음" 버튼으로 단계별로 스트림이 어떻게 병렬로 처리되는지 확인해 보세요.

단일 TCP 연결 수립

HTTP/2는 하나의 TCP 연결만 사용합니다.

클라이언트

단일 TCP 연결

서버

3. HTTP/2 헤더 압축 — HPACK

꼬리질문: "HPACK 헤더 압축은 어떻게 동작하나요?"

현대 웹에서 HTTP 헤더는 평균 700~800 bytes이며, 쿠키가 포함되면 수 KB에 달합니다. HTTP/1.1은 매 요청마다 이 헤더를 전부 반복 전송합니다. HTTP/2의 HPACK은 헤더를 정적 테이블(Static Table)과 동적 테이블(Dynamic Table)로 관리하며, 한 번 전송한 헤더는 이후 인덱스 번호만 전송합니다.

버튼을 눌러 첫 번째와 두 번째 요청에서 전송되는 헤더 데이터가 얼마나 달라지는지 확인해 보세요.

HPACK: 두 번째 요청에서 변경된 헤더만 전송하고, 나머지는 인덱스 번호로 대체합니다

"1. 첫 번째 요청 전송" 버튼을 눌러 시작하세요

HPACK은 허프만 코딩(Huffman Coding)도 적용하여 헤더 값 자체도 압축합니다. 실제 평균 압축률은 85~88%로, 100개의 요청을 보낼 때 절약되는 데이터양이 상당합니다.

4. HTTP/3와 QUIC — UDP 위에서 신뢰성 구현

꼬리질문: "HTTP/2와 HTTP/3에서 패킷 손실 시 동작이 왜 다른가요?"

HTTP/2가 해결하지 못한 문제는 TCP 레벨 HoL Blocking입니다. TCP는 패킷이 하나라도 손실되면 해당 패킷을 재전송받을 때까지 모든 스트림이 멈춥니다. HTTP/3은 TCP 자체를 포기하고 UDP 위에 QUIC 프로토콜을 새로 구축했습니다. QUIC은 각 스트림을 완전히 독립적으로 관리하기 때문에, 하나의 스트림에서 패킷이 손실되어도 나머지 스트림은 영향을 받지 않습니다.

"패킷 손실 시뮬레이션 시작" 버튼으로 HTTP/2와 HTTP/3의 패킷 손실 처리 차이를 직접 확인해 보세요.

Stream 2(CSS)에서 패킷 손실 발생 — HTTP/2 vs HTTP/3 동작 비교

HTTP/2 (TCP)

TCP HoL Blocking

HTML

진행중

CSS (손실 발생)

진행중

HTTP/3 (QUIC)

스트림 독립성

HTML

진행중

CSS (손실 발생)

진행중

5. HTTP/3 — 0-RTT 연결과 연결 마이그레이션

꼬리질문: "HTTP/3의 0-RTT 연결과 연결 마이그레이션이란?"

HTTP/3의 또 다른 핵심 장점은 연결 설정 속도와 연결 마이그레이션입니다. TCP+TLS는 연결 설정에 2~3 RTT(왕복 시간)가 필요하지만, QUIC은 최초 연결에 1 RTT, 재연결에는 0 RTT로 즉시 데이터를 전송할 수 있습니다. 또한 TCP는 IP 주소와 포트를 기반으로 연결을 식별하지만, QUIC은 연결 ID(Connection ID)로 식별하여 네트워크가 바뀌어도 연결이 유지됩니다.

"RTT 비교" 탭과 "연결 마이그레이션" 탭을 전환하며 QUIC의 두 가지 핵심 장점을 확인해 보세요.

HTTP/2 (TCP + TLS)

Client

HTTP/3 (QUIC)

Client

6. 버전별 비교 및 실무 선택 가이드

꼬리질문: "어떤 서비스에서 어떤 HTTP 버전을 선택해야 하나요?"

각 HTTP 버전은 모든 상황에서 "최신 = 최고"가 아닙니다. 현재 가장 넓은 지원과 안정성을 갖춘 HTTP/2가 대부분의 프로덕션 환경에서 최선의 선택이며, HTTP/3는 모바일 사용자 비중이 높거나 패킷 손실이 잦은 환경에서 추가 성능 이득을 제공합니다.

서비스 유형을 선택하면 추천 버전이 강조됩니다.

서비스 유형을 선택하면 추천 버전이 강조됩니다

일반 웹 서비스 추천HTTP/2

HTTP/2의 멀티플렉싱과 헤더 압축이 대부분의 웹 서비스에 최적입니다. 넓은 서버 지원과 안정성이 장점입니다.

특성	HTTP/1.1	HTTP/2★	HTTP/3
기반 프로토콜	TCP	TCP	UDP (QUIC)
멀티플렉싱	없음	있음 (TCP HoL 잔존)	있음 (완전 독립)
헤더 압축	없음	HPACK (88% 감소)	QPACK
연결 설정	2~3 RTT	2~3 RTT	0~1 RTT
HoL Blocking 해결	없음	HTTP 레벨만	완전 해결
암호화	선택 (HTTP)	사실상 필수 (HTTPS)	필수 (TLS 1.3)
연결 마이그레이션	불가	불가	가능 (Connection ID)
브라우저 지원율	전체 (100%)	97%+	75%+ (2024)
서버 지원 성숙도	완전 지원	완전 지원	CDN 중심 지원

자주 발생하는 문제

실무와 면접에서 자주 혼동하는 포인트를 정리했습니다.

면접 체크리스트

이 항목들을 자신 있게 설명할 수 있다면 HTTP 버전 질문은 준비 완료입니다.

- HTTP/1.1: Keep-Alive로 연결 재사용, 그러나 HoL Blocking과 헤더 중복이 한계
- HTTP/2: 멀티플렉싱(스트림 병렬처리) + HPACK 헤더 압축으로 HTTP 레벨 HoL Blocking 해결. TCP 레벨 HoL Blocking은 여전히 존재
- HTTP/3: QUIC(UDP 기반)으로 TCP HoL Blocking 완전 해결 + 0-RTT 연결 + 연결 마이그레이션
- 실무 선택: 일반 서비스는 HTTP/2, 모바일/스트리밍 특화는 HTTP/3 CDN 활용
- 마이그레이션 주의: HTTP/1.1 최적화 기법(도메인 샤딩, 과도한 번들링)은 HTTP/2에서 역효과

퀴즈로 확인하기

배운 개념을 실제 시나리오에 적용해 보세요.

Quiz 1

HoL Blocking 이해

HTTP/1.1 Keep-Alive 연결에서 다음 3개의 요청을 순서대로 보냈습니다:
1. /large-image.jpg (처리 시간: 500ms)
2. /style.css (처리 시간: 10ms)
3. /app.js (처리 시간: 20ms)

/style.css는 이미 서버에서 처리 완료됐습니다.
/style.css 응답은 언제 클라이언트에 도달할까요?

Quiz 2

HTTP/2 스트림과 패킷 손실

HTTP/2 연결에서 클라이언트가 다음을 동시에 요청했습니다:
- Stream 1: /index.html (100ms)
- Stream 3: /style.css (30ms)
- Stream 5: /app.js (50ms)

Stream 3(CSS)의 TCP 패킷이 전송 중 손실됐습니다.
어떤 일이 발생할까요?

Quiz 3

HPACK 압축 효율

다음 두 서비스 중 HTTP/2 HPACK 헤더 압축의 효과가 더 큰 곳은?

서비스 A: 소셜 미디어 피드 API
- 매 요청마다 Authorization, Cookie, User-Agent, Accept 헤더 포함
- 평균 100개 API 요청/페이지

서비스 B: 이미지 다운로드 서비스
- 최소한의 헤더 (Authorization만)
- 이미지 1개당 요청 1회, 평균 5개 요청/페이지

Quiz 4

HTTP/3 연결 마이그레이션

사용자가 스마트폰으로 동영상을 시청 중
Wi-Fi(IP: 192.168.1.100) → LTE(IP: 10.0.0.55)로 전환되었습니다.

HTTP/3(QUIC) 연결은 어떻게 될까요?

Quiz 5

실무 HTTP 버전 선택

신규 프로젝트 아키텍처 설계 중입니다.
다음 조건에서 가장 적합한 HTTP 버전은?

- 마이크로서비스 간 내부 gRPC 통신
- 서버 간 통신, 인터넷 노출 없음
- 안정적인 데이터센터 내부 네트워크 (패킷 손실 거의 없음)
- 최대 지원 성숙도 필요

추가 학습 자료를 공유합니다.

MDN — HTTP의 진화 — HTTP/0.9부터 HTTP/3까지 역사적 맥락과 각 버전의 핵심 변경사항을 한국어로 정리한 공식 문서
Cloudflare — HTTP/3: the past, the present, and the future — QUIC과 HTTP/3를 쉽게 설명하는 Cloudflare의 기술 블로그 (영어, 그림 풍부)
Google Developers — HTTP/2 소개 (한국어) — HTTP/2의 핵심 기능을 직관적인 그림과 함께 설명하는 Google 한국어 문서

의견을 들려주세요

서비스 개선에 큰 도움이 됩니다. 익명으로 자유롭게 남겨주세요.