network · medium priority
HTTP/2 & HTTP/3
웹 프로토콜의 진화 — 왜 빠른가
intermediate 난이도2시간토스카카오네이버당근
시작 전
이해도
매우 낮음
학습 개요
탄생 배경
쉬운 설명
복잡한 개념을 실생활 비유로 설명합니다.
“고속도로 차선”
HTTP/1.1은 편도 1차선 도로입니다. 앞차가 막히면 뒷차 전부 대기입니다. HTTP/2는 8차선 고속도로로, 여러 차(요청)가 동시에 달립니다. HTTP/3은 아예 도로 재질을 바꿔(TCP→UDP) 한 차선 사고가 다른 차선에 영향을 주지 않게 만들었습니다.
핵심 개념
HOL (Head-of-Line) Blocking
HTTP/1.1 파이프라이닝: 요청을 순서대로 보내도 앞 요청의 응답이 늦으면 뒷 요청이 모두 대기. 브라우저는 도메인당 최대 6개 병렬 연결로 우회했지만 근본 해결책이 아님.
HTTP 버전별 특징
| 버전 | 연결 | 멀티플렉싱 | 헤더 압축 | 전송 계층 |
|---|---|---|---|---|
| HTTP/1.1 | 요청마다 연결 or 재사용 | 없음 (파이프라이닝 한계) | 없음 (반복 전송) | TCP |
| HTTP/2 | 단일 연결 재사용 | ✅ 멀티플렉싱 | ✅ HPACK | TCP + TLS |
| HTTP/3 | 단일 연결 재사용 | ✅ 멀티플렉싱 | ✅ QPACK | QUIC (UDP + TLS 1.3) |
실무 적용
어떤 상황에서 사용하는가
웹 앱이 많은 API 요청과 정적 리소스를 로드할 때 네트워크 병목이 발생하는 상황
어떻게 적용하는가
Vercel·Netlify·Cloudflare는 HTTP/2·HTTP/3 자동 지원. 직접 서버 운영 시 nginx에 http2 옵션 추가. DevTools Network 탭 Protocol 열에서 버전 확인. HTTP/2에서는 domain sharding 불필요 — 오히려 역효과.
흔한 실수와 안티패턴
- HTTP/2는 HTTPS 없이 동작하지 않음 (실질적 표준) — 로컬 개발환경에서 확인 불가
- HTTP/1.1 최적화 기법(domain sharding, CSS sprite)은 HTTP/2에서 불필요하거나 역효과
- 서버 푸시는 캐시된 클라이언트에 불필요한 리소스를 전송해 오히려 느려질 수 있음
면접 질문
중급토스카카오네이버
답변 방향 힌트
HOL Blocking, 병렬 연결
반드시 언급할 키워드
- HOL Blocking 해결
- 단일 연결 재사용
- 스트림 동시 처리
예상 꼬리 질문
- HTTP/3의 QUIC이 TCP 대신 UDP를 사용하는 이유는?
- HTTP/2 환경에서 domain sharding이 오히려 나쁜 이유는?