1. 웹이 느린 이유 중 하나는 프로토콜이다
웹 성능을 이야기할 때 이미지 최적화, 코드 최소화 같은 것을 많이 언급하지만, 데이터를 주고받는 프로토콜 자체도 성능에 큰 영향을 미칩니다.
HTTP/1.1은 1997년에 표준화됐습니다. 그 이후 웹은 폭발적으로 성장했고, 한 페이지가 수십에서 수백 개의 리소스(이미지, CSS, JS, 폰트 등)를 요청하는 환경이 됐습니다. HTTP/1.1은 이런 현대 웹에 맞지 않는 구조적 한계가 있었습니다.
HTTP/2는 이 한계를 해결하기 위해 2015년에 공개됐습니다.
2. HTTP/1.1의 한계
HOL(Head-of-Line) Blocking 문제 HTTP/1.1은 하나의 TCP 연결에서 한 번에 하나의 요청만 처리합니다. 첫 번째 요청의 응답이 오기 전까지 두 번째 요청을 보낼 수 없습니다.
이를 해결하기 위해 브라우저는 도메인당 6개 정도의 병렬 연결을 만들어 동시에 요청을 보냅니다. 하지만 이 방법은 여전히 제한적이고, 각 연결마다 TCP 핸드셰이크 비용이 발생합니다.
큰 헤더 크기 HTTP/1.1에서는 매 요청마다 쿠키, 사용자 에이전트 같은 헤더가 반복 전송됩니다. 수백 개의 리소스를 요청할 때 이 헤더들이 불필요하게 많은 데이터를 차지합니다.
도메인 샤딩 같은 우회 방법의 필요성 개발자들은 HTTP/1.1의 한계를 극복하기 위해 여러 우회 방법을 사용했습니다. 여러 도메인에 리소스를 분산하는 도메인 샤딩, 여러 파일을 하나로 합치는 파일 번들링 등이 그 예입니다. 이런 방법들은 복잡성을 높이고 관리가 어렵습니다.
3. HTTP/2의 핵심 개선점
HTTP/2는 HTTP/1.1의 문제를 근본적으로 해결했습니다. 기본적인 개념(요청-응답 패러다임, 메서드, 상태 코드 등)은 유지하면서 전송 방식을 완전히 바꿨습니다.
주요 개선점은 멀티플렉싱, 헤더 압축, 서버 푸시, 우선순위 지정입니다.
4. 멀티플렉싱 – 여러 요청을 동시에 처리하기
**멀티플렉싱(Multiplexing)**은 HTTP/2의 가장 핵심적인 개선점입니다.
HTTP/1.1에서는 하나의 연결로 하나의 요청만 처리했지만, HTTP/2에서는 하나의 TCP 연결로 여러 요청과 응답을 동시에 처리합니다. 각 요청은 스트림(Stream)으로 나뉘어 독립적으로 처리됩니다.
도로로 비유하면 이렇습니다. HTTP/1.1은 왕복 1차선 도로로 한 차가 지나가야 반대편 차가 출발할 수 있습니다. HTTP/2는 고속도로처럼 여러 차선이 있어 여러 차가 동시에 달릴 수 있습니다.
멀티플렉싱 덕분에 HTTP/1.1 시절의 도메인 샤딩이나 파일 번들링 같은 우회 방법이 필요 없어졌습니다.
5. 헤더 압축과 서버 푸시
헤더 압축(Header Compression) HTTP/2는 HPACK이라는 압축 알고리즘으로 헤더를 압축합니다. 첫 요청에서 헤더 전체를 전송하고, 이후 요청에서는 이전 요청과 다른 부분만 전송합니다. 반복되는 쿠키나 사용자 에이전트 같은 헤더를 매번 보내지 않아도 됩니다.
서버 푸시(Server Push) 클라이언트가 요청하기 전에 서버가 필요할 것 같은 리소스를 미리 전송하는 기능입니다. HTML을 요청받으면 그 HTML이 필요로 하는 CSS와 JS를 자동으로 먼저 보낼 수 있습니다.
다만 서버 푸시는 실제 운영에서는 효과가 제한적이고 오히려 성능을 저하시킬 수 있어, 많은 서비스에서 비활성화하고 있습니다. HTTP/3에서는 서버 푸시가 축소됐습니다.
6. HTTP/2를 사용하려면 무엇이 필요한가?
HTTP/2는 HTTPS가 필수입니다. 기술 명세상 HTTP도 가능하지만 실제로 모든 주요 브라우저가 HTTPS에서만 HTTP/2를 지원합니다.
Nginx에서 HTTP/2를 활성화하는 방법입니다. SSL 설정에 http2 키워드를 추가합니다.
listen 443 ssl http2;
Certbot으로 HTTPS를 설정한 경우 Nginx가 자동으로 이 설정을 포함시키기도 합니다. HTTP/2가 적용됐는지는 브라우저 개발자 도구 Network 탭에서 Protocol 컬럼에서 확인할 수 있습니다.
클라우드 서비스(Cloudflare, AWS CloudFront 등)를 사용한다면 별도 설정 없이 HTTP/2가 자동으로 적용됩니다.
7. HTTP/3 – 이미 다음 버전이 나왔다
HTTP/3는 2022년 공식 표준으로 채택됐습니다. HTTP/2가 TCP 위에서 동작한다면, HTTP/3는 QUIC이라는 새로운 프로토콜 위에서 동작합니다.
QUIC은 UDP 기반으로 TCP의 연결 설정 시간을 크게 줄이고, 패킷 손실이 발생해도 다른 스트림에 영향을 주지 않는 구조입니다.
HTTP/3의 가장 큰 장점은 불안정한 모바일 네트워크 환경에서 성능이 크게 개선된다는 점입니다.
Cloudflare, Google은 이미 HTTP/3를 지원합니다. Nginx도 실험적 지원을 제공하고 있습니다.
8. 정리 및 다음 단계
오늘 배운 핵심을 정리합니다.
- HTTP/1.1은 연결당 하나의 요청만 처리해 현대 웹에서 병목이 됩니다.
- HTTP/2는 멀티플렉싱으로 하나의 연결에서 여러 요청을 동시 처리합니다.
- HTTP/2는 HTTPS가 필수이며, Nginx에서 listen 443 ssl http2로 활성화합니다.
- HTTP/3는 QUIC 기반으로 더 빠른 연결과 안정성을 제공합니다.
다음 글에서는 Cloudflare CDN을 무료로 설정해 사이트 속도를 높이는 실전 방법을 알아보겠습니다.