973. HTTP/2 멀티플렉싱 - 바이너리 프레이밍 스트림 다중화 웹 로딩 속도 최적화 HOL 차단 파이프라인 한계 극복 통신 프로토콜 진화

핵심 인사이트: 2000년대 초반에 만든 HTTP/1.1 규격. 웹페이지 하나를 띄우는데 사진 100장을 받아야 한다면, 한 장 받고 나서 다음 장을 요청하는 '1차선 도로'였다. 좀 똑똑해지려고 파이프라인(한 번에 다 시키기)을 썼더니, 앞의 큰 사진 하나가 늦게 오면 뒤에 꼬마 사진들이 줄줄이 갇혀서 웹페이지가 백지로 멈추는 대참사(HOL 블로킹)가 터졌다. 구글(SPDY) 주도로 엎어버렸다. "야! 사진 100장을 통째로 순서대로 보내지 마! 100장을 레고 블록 단위로 마구잡이로 갈기갈기 찢어서(바이너리 프레이밍) 1차선 도로에 한꺼번에 마구 섞어서 던져(멀티플렉싱)! 폰이 알아서 조립하게 해!" 웹 로딩 속도를 혁명적으로 바꾼 HTTP/2의 심장이다.

Ⅰ. HTTP/1.1의 비참한 한계 (HOL 블로킹) 🌟

  • 1 커넥션 = 1 요청 원칙: 브라우저가 서버와 랜선(TCP 커넥션) 하나를 뚫으면 한 번에 파일 1개만 요청하고 받았습니다.
  • 너무 느려서 브라우저는 꼼수로 동시 커넥션을 6개 뚫어서 사진 6개를 동시에 받았지만, 컴퓨터 자원이 엄청 깨졌습니다.
  • 파이프라이닝 실패: 1개의 선에서 사진 10개를 릴레이로 요청했지만, 서버는 무조건 순서대로 응답해야 했습니다. 1번 사진이 용량이 커서 10초가 걸리면, 2~10번 사진은 멀쩡히 준비됐는데도 출발을 못 하고 갇히는 HTTP HOL Blocking (971번 문서) 지옥이 터졌습니다.

Ⅱ. HTTP/2의 개념과 멀티플렉싱(Multiplexing) 마법 🌟

구글 SPDY 프로젝트를 기반으로 2015년 표준화된 혁명입니다.

1. 텍스트 버리고 바이너리로 (Binary Framing Layer)

  • 옛날엔 데이터와 헤더(주소)를 텍스트 글자로 보냈습니다.
  • HTTP/2는 데이터를 컴퓨터가 제일 빨리 읽는 0과 1의 바이너리 레고 블록(프레임) 단위로 무자비하게 쪼개버립니다(프레이밍).

2. 멀티플렉싱 (Multiplexing) - "섞어 찌개 전송" 🌟 핵심 🌟

  • 개념: 단 **1개의 TCP 커넥션(1차선 도로)**만 뚫어놓고, 수백 개의 사진과 텍스트를 무작위로 섞어서(다중화) 한꺼번에 쏟아버리는 기술입니다.
  • 동작:
    • 서버는 1번 사진 조각, 2번 사진 조각, 3번 사진 조각을 뒤죽박죽 섞어서 막 던집니다.
    • 1번 사진을 렌더링하다 딜레이가 걸려도, 2번 3번 사진 조각은 1번을 기다리지 않고 옆으로 추월해서 쌩쌩 날아가 폰 화면에 먼저 뜹니다(HOL 블로킹 완벽 타파).
    • 브라우저는 섞여 들어온 블록에 적힌 '스트림 번호표(ID)'를 보고 자기들끼리 퍼즐처럼 100% 깔끔하게 재조립합니다.

Ⅲ. HTTP/2의 추가 속도 뻥튀기 스킬 🌟

1. 헤더 압축 (HPACK)

  • HTTP/1.1은 매번 요청할 때마다 무거운 헤더(쿠키, 브라우저 정보 등 1KB)를 똑같이 반복해서 보냈습니다.
  • HTTP/2는 "야! 아까 보낸 헤더랑 똑같지? 그럼 바뀐 글자 하나만 보내!(델타 압축)" 라며 중복되는 헤더를 10바이트 수준으로 압축해 버리는 HPACK 알고리즘을 써서 트래픽 낭비를 0%로 만들었습니다.

2. 서버 푸시 (Server Push)

  • 옛날엔 브라우저가 "HTML 줘" ➜ (받음) ➜ "오 HTML 까보니까 CSS 파일 필요하네? CSS 줘!" (왕복 2번)
  • HTTP/2 서버의 선빵: "야, 너 HTML 달라고? 내가 볼 때 너 이거 받으면 무조건 CSS랑 이미지 파일도 필요할걸? 네가 달라고 안 했지만 걍 덤으로 묶어서 미리 쏴버릴게!(서버 푸시)" 브라우저가 뒤늦게 요청할 시간을 미리 앞당겨 절약하는 마법입니다.

Ⅳ. 남은 숙제 (TCP의 한계)

  • HTTP/2가 웹 계층의 HOL 블로킹은 다 해결했지만, 그 밑에 깔린 TCP 프로토콜 자체가 가진 **TCP HOL 블로킹(패킷 유실 시 전체 대기)**은 극복하지 못했습니다. 결국 이 마지막 한계를 부수기 위해 탄생한 것이 972번 문서의 **HTTP/3 (QUIC)**입니다.

📢 섹션 요약 비유: 구형 HTTP/1.1은 '꽉 막힌 은행 창구 1개'입니다. 내 앞사람이 대출 심사(용량 큰 사진)를 받느라 30분을 허비하면, 뒤에서 동전 하나 바꾸려는 사람(용량 작은 텍스트)도 꼼짝없이 30분을 기다려야 합니다(HOL 블로킹). 그래서 창구를 6개(멀티 커넥션) 열었지만 알바생 인건비가 터졌습니다. HTTP/2 멀티플렉싱은 '천재적인 회전초밥 컨베이어 벨트'입니다. 주방장(서버)은 손님이 주문한 음식 10개를 1개씩 순서대로 내보내지 않습니다. 조리된 순서도 무시하고, 계란초밥 접시, 연어초밥 접시를 컨베이어 벨트 1개(단일 커넥션) 위에 마구잡이로 섞어서 한 번에 미친 듯이 쏟아냅니다. 장어초밥을 굽느라 늦어져도(지연), 이미 만들어진 계란초밥은 막힘없이 손님 입(브라우저)으로 쌩쌩 굴러갑니다. 손님은 접시에 적힌 자기 이름표(스트림 ID)만 보고 쏙쏙 뽑아 먹어 웹페이지가 1초 만에 풀 로딩되는 혁명적 동시 처리 시스템입니다.