HTTP/2 훑어보고 AWS에서 적용해보기

HTTP/1의 구조적 한계를 짚고 HTTP/2가 이를 어떻게 해결하는지 정리한 뒤, AWS CloudFront와 Application Load Balancer(ALB)에서 실제로 HTTP/2를 적용하는 방법을 단계별로 안내한다. 이론 정리와 실습이 함께 있어 HTTP/2를 처음 접하는 개발자에게 좋은 입문 자료다.

핵심 포인트 - HTTP/1의 3대 문제: Head-of-Line(HOL) Blocking(응답 순서 강제로 인한 지연), RTT 증가(매 연결마다 3-way handshake), 헤더 중복 전송(쿠키 포함 메타정보 매 요청 반복) - HTTP/2 핵심 기능: Multiplexing(단일 커넥션에서 다수 스트림 동시 처리), Binary Protocol(파싱 속도 향상), HPACK 헤더 압축, Server Push, Stream Prioritization - Multiplexing이 HOL Blocking을 해결하는 원리: 독립적으로 처리되는 스트림이 서로 영향을 주지 않아 한 요청 지연이 전체에 영향 안 미침 - AWS CloudFront HTTP/2 적용: Distribution 설정의 "지원되는 HTTP 버전" 에서 HTTP/2 체크 — 버튼 하나로 전환 가능 - AWS ALB HTTP/2 적용: Elastic Beanstalk 환경 생성 시 로드밸런서에 HTTPS(443포트) 리스너 추가 — ALB ↔ 클라이언트 구간만 HTTP/2로 설정, 로드밸런서 ↔ 웹서버는 HTTP/1로도 충분 - 성능 측정 결과: 이미지 30개 포함 페이지에서 DomContentLoaded HTTP/1 14.65초 vs HTTP/2 11.45초 (약 20% 개선)

상세 정리 - HTTP/1은 1999년 1.1 버전 이후 20년 이상 사용. 현재 웹 평균 페이지 용량은 2MB 이상으로 당시와 전혀 다른 환경 - 기존 HTTP/1 최적화 기법(소스 번들링, 이미지 스프라이트, 도메인 샤딩)은 HTTP/2에서 오히려 역효과 가능 - HTTP/2에서 이미지 스프라이트: 불필요한 CSS 연산 증가, 캐싱 복잡화. 도메인 샤딩: 커넥션 분산으로 HTTP/2의 Multiplexing 이점 무력화 - SPDY: HTTP/2의 전신인 구글의 비표준 프로토콜. HTTP를 대체하는 게 아니라 확장 - Server Push: 클라이언트가 page.html 요청 시 서버가 index.js/index.css를 미리 Push해 latency 감소 - 로드밸런서 ↔ 웹서버 구간은 브라우저 연결 개수 제한 없고 RTT가 짧아 HTTP/1로도 HOL Blocking이 큰 이슈 아님 - HTTP/3: UDP 기반으로 전환하여 TCP 레벨의 HOL Blocking까지 해결. 현재 도입 진행 중

왜 읽나: HTTP/2의 작동 원리와 AWS 서비스별 적용 방법을 한 번에 익히고, 기존 HTTP/1 최적화 기법을 HTTP/2 환경에서 재검토해야 하는 이유까지 이해할 수 있다.