HTTP/2
9장에서 HTTP/1.1의 요청-응답 구조를 살펴보았습니다. HTTP/1.1은 웹의 폭발적 성장을 이끌었지만, 현대 웹 페이지의 복잡도가 증가하면서 성능 한계가 드러났습니다. 하나의 웹 페이지가 수십 개의 CSS, JavaScript, 이미지 파일을 필요로 하는 상황에서, HTTP/1.1의 구조적 문제가 병목이 되기 시작했습니다.
HTTP/1.1의 한계
HTTP/1.1의 대표적인 성능 한계는 Head-of-Line(HOL) Blocking입니다. 같은 연결에서 앞선 응답이 늦어지면 뒤 요청이 기다리기 쉽고, 브라우저는 이를 완화하려고 여러 TCP 연결을 동시에 열었습니다. 하지만 연결 수가 늘면 TCP/TLS 핸드셰이크, 혼잡 제어, 서버 부하가 함께 증가합니다.
개발자들은 HTTP/1.1의 연결 단위 병목을 줄이기 위해 다양한 최적화 패턴을 사용했습니다.
| 최적화 기법 | 방식 | HTTP/2 이후의 관점 |
|---|---|---|
| CSS 스프라이트 | 여러 이미지를 하나로 합침 | 요청 수 절감 효과는 줄고 유지보수 비용이 큼 |
| 도메인 샤딩 | 리소스를 여러 도메인에 분산 | HTTP/2 연결 재사용과 충돌하고 DNS/TLS 비용 증가 |
| 인라이닝 | CSS/JS를 HTML에 직접 삽입 | 초기 렌더링에는 도움 될 수 있으나 캐시 효율 저하 |
| 파일 합치기 | JS/CSS 파일 결합 | 작은 리소스를 병렬 전송할 수 있어 필요성이 줄어듦 |
HTTP/2는 이런 패턴이 의존하던 “요청 수 자체를 줄여야 한다”는 압박을 프로토콜 레벨에서 완화합니다. 다만 번들링, 인라이닝, 프리로드 같은 최적화는 애플리케이션 특성에 따라 여전히 선택적으로 사용됩니다.
바이너리 프레이밍과 멀티플렉싱
HTTP/2의 핵심 변화는 바이너리 프레이밍 계층(Binary Framing Layer)의 도입입니다. HTTP 메시지를 텍스트 줄 단위로 그대로 흘려보내지 않고, HEADERS와 DATA 같은 프레임으로 나누어 여러 스트림을 하나의 연결 위에서 동시에 진행합니다.
헤더 압축 (HPACK)
HTTP/1.1에서는 매 요청마다 비슷한 헤더가 반복 전송되었습니다. HTTP/2는 HPACK으로 헤더 필드를 인덱스와 동적 테이블 중심으로 표현해 반복 전송량을 줄입니다. 민감한 값은 동적 테이블에 넣지 않는 표현도 있어, 압축 효율과 보안 고려를 함께 다룹니다.
서버 푸시
HTTP/2의 서버 푸시(Server Push)는 서버가 클라이언트의 후속 요청을 예측하여 PUSH_PROMISE로 미리 자원을 예약하고 보내는 기능입니다. 프로토콜에는 정의되어 있지만, 실제 웹에서는 캐시 중복, 예측 실패, 우선순위 제어 문제 때문에 활용이 제한적이었고 현대 브라우저 환경에서는 대부분 비활성화되거나 제거된 방향으로 흘렀습니다.
HTTP/2의 남은 문제
HTTP/2는 HTTP 메시지 단위의 HOL Blocking을 크게 줄였지만, TCP 계층의 HOL Blocking은 여전히 남습니다. 하나의 TCP 연결 위에 여러 HTTP/2 스트림이 올라가기 때문에, 패킷 손실이 발생하면 TCP가 순서를 복구할 때까지 뒤쪽 바이트 전달이 함께 지연될 수 있습니다.
| 항목 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| 프로토콜 표현 | 텍스트 기반 메시지 | 바이너리 프레임 | 바이너리 프레임 |
| 전송 계층 | TCP | TCP | QUIC over UDP |
| 멀티플렉싱 | 제한적, 보통 여러 연결 사용 | 한 TCP 연결 안에서 여러 스트림 | QUIC 스트림 기반 |
| HOL Blocking | HTTP 계층 + TCP 계층 | HTTP 계층은 완화, TCP 계층은 남음 | TCP HOL은 제거, 스트림 단위로 완화 |
| 헤더 압축 | 없음 | HPACK | QPACK |
| 서버 푸시 | 없음 | 프로토콜 기능은 있으나 사용 축소 | 프로토콜에 정의, 사용은 제한적 |
| 연결 수립 | TCP + TLS 여부에 따라 다름 | TCP + TLS/ALPN 영향 | QUIC/TLS 1.3, 재개 시 0-RTT 가능 |
| 암호화 | 선택 | 표준상 h2/h2c 가능, 브라우저는 사실상 TLS | QUIC에 TLS 1.3 통합 |
이 문제를 줄이기 위해 QUIC 기반의 HTTP/3가 등장했습니다. 다음 절에서 QUIC이 연결 수립, 손실 복구, 스트림 처리 방식을 어떻게 바꾸는지 자세히 다루겠습니다.