[HTTP 이해하기 4편] HTTP/1.1과 HTTP/2, 무엇이 어떻게 다르고 언제 무엇을 써야 할까
Today Key : HTTP/1.1, HTTP/2, 비교, 연결 관리, 멀티플렉싱, 바이너리 프레이밍, ALPN, Apache httpd, h2, h2c
HTTP/1.1, HTTP/2 두 프로토콜은 버전이 달라도 HTTP는 공통된 의미 체계를 공유합니다.
RFC 9112는 그 의미를 HTTP/1.1의 메시지 문법과 연결 관리 방식으로 전달하는 방법을 정의하고,
RFC 9113은 HTTP/2를 같은 HTTP 의미를 더 효율적으로 표현한 버전으로 설명합니다.
두 버전은 전혀 다른 프로토콜이라기보다, 같은 HTTP를 서로 다른 방식으로 실어 나르는 두 개의 구현 모델에 가깝습니다.
이번 포스팅에서는 HTTP/1.1과 HTTP/2의 차이와 언제 사용하는지에 대해서 알아봅니다.
메시지를 전달하는 방식의 차이
HTTP/1.1과 HTTP/2의 가장 큰 차이는 "무슨 요청을 보내느냐"보다 "그 요청을 어떤 형태로 전달하느냐"에 있습니다.
HTTP/1.1은 사람이 읽을 수 있는 텍스트 메시지 형식으로 의미를 전달합니다.
반면 HTTP/2는 메시지를 프레임 단위로 나누고, pseudo-header 같은 구조를 사용해 같은 의미를 더 효율적인 형태로 표현합니다.
HTTP/1.1에서는 요청 첫 줄에 메서드와 경로, 버전이 들어가고, 그 아래에 헤더가 붙고, 마지막에 필요하면 본문이 따라오는 구조입니다.
HTTP/2에서는 같은 의미가 여러 프레임으로 쪼개져 전달되고, 그 프레임이 스트림이라는 논리적 단위 위에서 처리됩니다.
HTTP/1.1은 "메시지를 읽는 감각"이 강하고, HTTP/2는 "프레임과 스트림을 해석하는 감각"이 더 강하다고 볼 수 있습니다.
연결을 바라보는 방식의 차이
연결 관리에서도 두 버전의 차이는 분명합니다.
RFC 9112는 HTTP/1.1 구현이 연결을 유지하고 재사용하며, 필요하면 새 연결을 만들고 닫는 connection management를 수행해야 한다고 설명합니다.
실제 클라이언트들은 병렬 처리를 위해 같은 서버 엔드포인트에 대해 여러 연결을 유지하기도 합니다.
RFC 9113은 HTTP/2가 같은 연결 위에서 여러 교환을 동시에 처리할 수 있고, 같은 연결 안에서 메시지를 interleave할 수 있다고 설명합니다.
정리하면 HTTP/1.1은 연결을 여러 개 써서 병렬성을 확보하는 방향이고, HTTP/2는 연결 하나를 더 잘 활용하는 방향입니다.
성능 측면에서 HTTP/2가 주목받는 이유
RFC 9113은 HTTP/2가 필드 압축과 단일 연결 내 다중 동시 처리를 통해 네트워크 자원을 더 효율적으로 사용하고 지연을 줄인다고 설명합니다.
HTTP/2의 장점은 단순히 "버전이 더 높다"가 아닙니다.
요청 수가 많고 리소스가 많은 환경에서 연결 수를 불필요하게 늘리지 않으면서도 동시성을 확보할 수 있다는 데 있습니다.
한 페이지 안에서 여러 요청이 짧은 시간 안에 집중되는 브라우저 기반 서비스에서 이 구조적 이점이 크게 작용합니다.
HTTP/1.1이 여전히 중요한 이유
그렇다고 HTTP/1.1이 쓸모없다는 뜻은 아닙니다.
구조가 단순하고 해석이 직관적이며, 다양한 서버, 프록시, 중간 장비, 애플리케이션과의 호환성이 좋습니다.
실무에서는 HTTP/2를 운영하더라도 문제를 분석할 때 HTTP/1.1의 요청/응답 구조를 먼저 떠올리는 경우가 많습니다.
HTTP/1.1이 가장 이해하기 쉬운 기본 모델이기 때문입니다.
운영과 디버깅 관점에서도 차이가 있습니다.
HTTP/1.1은 텍스트 기반 메시지라 로그, 프록시, 디버그 출력에서 흐름을 눈으로 따라가기 쉽습니다.
반면 HTTP/2는 프레임, 스트림, pseudo-header 개념을 통해 같은 의미를 표현하므로, 도구가 해석해 주는 계층을 함께 봐야 하는 경우가 많습니다.
HTTP/2는 성능 면에서 장점이 크지만, 내부 동작을 처음 추적할 때는 HTTP/1.1보다 한 단계 더 추상화된 감각이 필요합니다.
서버 설정과 협상, h2와 h2c
브라우저가 접속하는 일반적인 웹 서비스에서는 HTTP/2를 이해하고 활용할 이유가 분명합니다.
Apache는 mod_http2를 통해 HTTP/2를 지원하지만, Apache 공식 문서가 명시하듯 HTTP/2는 자동으로 켜지는 기능이 아닙니다.
Protocols 설정을 통해 명시적으로 활성화해야 하며, TLS 기반의 h2와 평문 TCP 기반의 h2c를 구분합니다.
HTTP/2는 서버가 명시적으로 준비해야 사용할 수 있는 기능입니다.
여러 프로토콜을 같은 포트에서 지원해야 할 때는 협상 방식도 중요해집니다.
RFC 7301은 ALPN을 TLS 핸드셰이크 안에서 어떤 애플리케이션 프로토콜을 사용할지 정하는 확장으로 정의합니다.
Apache 문서도 Protocols h2 http/1.1 설정을 통해 TLS ALPN으로 HTTP/2를 협상할 수 있다고 설명합니다.
브라우저와 서버가 둘 다 HTTP/2를 지원하더라도, 실제 어떤 버전이 사용될지는 TLS 초기 협상 단계에서 결정됩니다.
이 부분이 바로 다음 편에서 다룰 핵심 주제입니다.
프론트엔드와 백엔드의 선택은 항상 같을 필요가 없다
실무적으로 프론트엔드와 백엔드의 프로토콜 선택이 항상 일치할 필요는 없습니다.
Apache의 mod_proxy_http2 문서는 프론트엔드 요청이 HTTP/1.1이든 HTTP/2든 백엔드와는 가능한 한 하나의 TCP 연결을 재사용해 HTTP/2로 통신할 수 있다고 설명합니다.
다만 이 모듈은 HTTP/2만 지원하고 HTTP/1.1로 자동 다운그레이드하지 않기 때문에, 백엔드가 HTTP/2를 지원해야 합니다.
HTTP/2를 쓴다"는 말이 서비스 전체 구간에서 같은 의미를 가지는 것은 아닙니다.
정리하면 HTTP/1.1은 여전히 웹 통신의 기본 문법과 해석 기준을 제공하는 가장 중요한 기준점이고, HTTP/2는 그 같은 의미를 더 효율적으로 전달하기 위한 구조적 개선판입니다.
HTTP/1.1은 단순하고 직관적이며, HTTP/2는 멀티플렉싱과 헤더 압축을 통해 현대 웹 환경에서 더 나은 효율을 제공합니다.
결국 둘 중 하나만 알면 되는 것이 아니라, 둘을 함께 알아야 현재의 웹 통신이 왜 그렇게 보이는지 제대로 이해할 수 있습니다.
다음 포스팅에서는 브라우저와 서버가 실제 HTTPS 연결을 시작할 때 어떤 과정으로 프로토콜을 정하는지, ALPN과 TLS 핸드셰이크가 어떤 역할을 하는지 이어서 살펴보겠습니다.