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는 이런 패턴이 의존하던 “요청 수 자체를 줄여야 한다”는 압박을 프로토콜 레벨에서 완화합니다.

다만 번들링, 인라이닝, 프리로드 같은 최적화는 애플리케이션 특성에 따라 여전히 선택적으로 사용됩니다.

HTTP/2의 핵심 변화는 바이너리 프레이밍 계층(Binary Framing Layer)의 도입입니다.

HTTP 메시지를 텍스트 줄 단위로 그대로 흘려보내지 않고, HEADERS와 DATA 같은 프레임으로 나누어 여러 스트림을 하나의 연결 위에서 동시에 진행합니다.

HTTP/1.1에서는 매 요청마다 비슷한 헤더가 반복 전송되었습니다.

HTTP/2는 HPACK으로 헤더 필드를 인덱스와 동적 테이블 중심으로 표현해 반복 전송량을 줄입니다.

민감한 값은 동적 테이블에 넣지 않는 표현도 있어, 압축 효율과 보안 고려를 함께 다룹니다.

HTTP/2의 서버 푸시(Server Push)는 서버가 클라이언트의 후속 요청을 예측하여 PUSH_PROMISE로 미리 자원을 예약하고 보내는 기능입니다.

프로토콜에는 정의되어 있지만, 실제 웹에서는 캐시 중복, 예측 실패, 우선순위 제어 문제 때문에 활용이 제한적이었고 현대 브라우저 환경에서는 대부분 비활성화되거나 제거된 방향으로 흘렀습니다.

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 통합

마지막으로 HTTP/2를 운영할 때 확인해야 할 프로토콜 상태, 실패 응답, 관측 도구, 복구 기준을 정리합니다.

이 문제를 줄이기 위해 QUIC 기반의 HTTP/3가 등장했습니다.

다음 절에서 QUIC이 연결 수립, 손실 복구, 스트림 처리 방식을 어떻게 바꾸는지 자세히 다루겠습니다.