HTTP/1.1의 한계와 멀티플렉싱의 정의
HTTP/1.1에서는 하나의 TCP 연결로 요청을 보내면 응답이 올 때까지 다음 요청을 보낼 수 없었습니다. 이를 해결하려고 브라우저는 도메인당 6~8개의 TCP 연결을 동시에 열어 병렬로 요청을 처리했지만, 연결 수 자체에 한계가 있고 각 연결마다 TCP 핸드셰이크 비용이 발생했습니다. 만약 앞선 요청의 응답이 늦어지면 뒤에 대기 중인 요청까지 막히는 ‘Head-of-Line Blocking’ 현상도 문제였습니다.
HTTP/2의 멀티플렉싱은 하나의 TCP 연결 위에서 여러 요청과 응답을 동시에 주고받을 수 있게 만든 기술입니다. 연결을 여러 개 열 필요 없이, 단 하나의 연결로 수십 개의 요청을 병렬 처리할 수 있게 된 것입니다.
스트림과 프레임으로 동작하는 원리
HTTP/2는 요청과 응답 데이터를 ‘프레임(frame)’이라는 작은 단위로 쪼갠 뒤, 각 프레임에 ‘스트림 ID’를 붙여 전송합니다. 여러 요청의 프레임들이 하나의 연결 위에서 뒤섞여 전송되지만, 수신 측은 스트림 ID를 보고 원래 요청 단위로 다시 조립합니다.
비유하자면, HTTP/1.1은 좁은 도로에 차선이 하나뿐이라 앞차가 막히면 뒤차도 못 가는 상황과 같습니다. 반면 HTTP/2는 같은 도로 위에 여러 대의 화물차가 짐을 잘게 나눠 싣고, 각 상자에 목적지 라벨(스트림 ID)을 붙여 뒤섞어 보낸 뒤 도착지에서 라벨대로 다시 분류하는 방식입니다. 도로(연결)는 하나지만 실제로는 여러 화물이 동시에 이동하는 셈입니다.
예를 들어 이미지 3개와 CSS 파일 1개를 요청할 때, HTTP/1.1이라면 순서대로 하나씩 응답을 기다려야 했지만 HTTP/2에서는 stream 1, stream 3, stream 5, stream 7의 데이터가 하나의 연결 위에서 동시에 오갑니다.
실무에서 왜 중요한가
웹 성능 최적화 관점에서 멀티플렉싱은 큰 변화를 가져왔습니다. 기존에는 이미지 스프라이트를 만들거나 CSS/JS 파일을 하나로 합치는 ‘번들링’이 요청 수를 줄이기 위한 필수 기법이었지만, HTTP/2 환경에서는 이런 최적화의 효과가 줄어들거나 오히려 캐싱 효율을 해칠 수 있습니다.
- 연결 수가 줄어 서버 자원 소모가 감소합니다.
- TCP 핸드셰이크와 TLS 협상 비용이 줄어 초기 로딩이 빨라집니다.
- 다만 TCP 계층에서의 패킷 손실 시 모든 스트림이 영향을 받는 한계는 남아 있어, 이를 개선한 것이 HTTP/3(QUIC 기반)입니다.
결국 HTTP/2 멀티플렉싱은 ‘연결은 하나로 줄이고, 그 안에서 병렬성은 최대로 높인’ 설계로, 오늘날 대부분의 CDN과 웹 서버가 기본으로 지원하는 표준 기술이 되었습니다.