네트워크
HTTP/1.1 → HTTP/2 → HTTP/3
HOL blocking, 멀티플렉싱, QUIC까지 — HTTP가 진화해 온 이유.
- 초기 상태
- T = 1
- T = 2
- T = 3
Stream 1: GET /index.html
Stream 2: GET /style.css
Stream 3: GET /app.js
HTTP/1.1순차 전송 — 한 요청 끝나야 다음 시작
0 / 9 framesHTTP/2멀티플렉싱 — 프레임이 인터리브됨
0 / 9 frames3개의 HTTP 요청을 한 연결로 동시에 보내고 싶습니다. HTTP/1.1과 HTTP/2가 같은 9개의 프레임을 어떻게 다르게 처리하는지 단계별로 비교합니다.
핵심 개념
HOL Blocking (Head-of-Line)
앞 요청이 막히면 뒤 요청도 같이 막히는 현상. HTTP/1.1의 핵심 약점.
HTTP/2 멀티플렉싱
하나의 TCP 연결 위에서 여러 스트림을 동시에 주고받음. 바이너리 프레이밍 + 헤더 압축(HPACK).
HTTP/3 + QUIC
전송 계층을 TCP에서 UDP 기반 QUIC으로 교체. 0-RTT 연결, 패킷 손실에도 다른 스트림 안 막힘.
왜 UDP 위에 QUIC?
TCP는 OS 커널과 미들박스에 박혀있어 진화가 어려움. UDP 위에 새 프로토콜을 얹어 빠르게 반복 개선.
면접 단골 질문
- Q1.HTTP/1.1의 keep-alive와 파이프라이닝의 한계는 무엇인가요?
- Q2.HTTP/2의 멀티플렉싱이 어떻게 HOL blocking을 해결하나요? 완전히 해결되나요?
- Q3.HTTP/3는 왜 TCP가 아닌 UDP 기반으로 만들어졌나요?
- Q4.Server Push (HTTP/2)는 왜 사실상 폐기되었나요?
- Q5.HTTPS와 HTTP/2의 관계 — H2가 사실상 HTTPS 전제인 이유는?