today keys : HTTP, HTTP/1.1, HTTP/2, 웹 통신, Apache httpd, TLS, ALPN, 브라우저 협상, 패킷 분석
웹 서비스를 운영하다 보면 HTTP라는 단어는 이미 너무 익숙해서 깊게 생각하지 않고 지나가게 됩니다. 브라우저로 웹사이트에 접속하고, 서버가 응답을 반환하는 흐름이 너무 자연스럽기 때문입니다. 그런데 같은 웹 접속처럼 보여도 내부에서는 HTTP/1.1로 동작할 수도 있고 HTTP/2로 동작할 수도 있습니다.
이번 포스팅에서는 이 두 프로토콜을 함께 봐야 하는 이유와 앞으로 이 시리즈가 어떤 흐름으로 전개될지를 먼저 정리합니다.
HTTP/1.1은 여전히 현재진행형
HTTP/1.1은 단순히 "예전 버전"이 아닙니다.
RFC 9112는 HTTP/1.1을 메시지 문법, 메시지 파싱, 연결 관리, 그리고 관련 보안 고려사항을 정의한 프로토콜로 설명합니다.
오늘날에도 웹 서버와 프록시, 중간 장비, 그리고 다양한 애플리케이션이 기본 전제로 삼고 있는 프로토콜입니다.
텍스트 기반이라 흐름을 따라가기 쉽고, 문제를 분석할 때도 비교적 직관적으로 접근할 수 있습니다.
HTTP/2가 바꾸려 한 것
HTTP/2는 HTTP의 의미 자체를 바꾸려고 나온 버전이 아닙니다.
같은 HTTP 의미를 더 효율적으로 전달하기 위해 등장했습니다.
RFC 9113은 HTTP/2가 필드 압축과 단일 연결에서의 다중 교환 처리를 통해 네트워크 자원을 더 효율적으로 사용하고 지연 시간을 줄인다고 설명합니다.
HTTP/2를 이해한다는 것은 새 버전을 아는 것에 그치지 않습니다.
왜 어떤 웹 서비스가 더 빠르게 느껴지는지, 같은 HTTPS라도 내부 동작이 왜 달라지는지를 이해하는 것과 직결됩니다.
다만 "HTTP/2가 최신이니 무조건 더 좋다"고 단순하게 결론 내리기는 어렵습니다.
HTTP/2는 구조적으로 더 효율적이지만, 프레임·스트림·동시성 같은 개념을 별도로 이해해야 하고 패킷 분석 방식도 HTTP/1.1과 달라집니다.
두 버전은 우열 관계가 아니라, 웹 통신을 서로 다른 방식으로 구현한 두 개의 기준점으로 보는 편이 정확합니다.
브라우저와 서버는 프로토콜을 협상
브라우저가 웹사이트에 접속할 때 HTTP 버전은 무작위로 결정되지 않습니다.
HTTPS 환경에서는 TLS 핸드셰이크 안에서 ALPN이라는 확장을 통해 어떤 애플리케이션 프로토콜을 사용할지 협상합니다.
RFC 7301은 이 협상이 추가적인 네트워크 왕복 없이 TLS 핸드셰이크 안에서 이뤄진다고 설명합니다.
이 과정에서 HTTP/2는 h2, HTTP/1.1은 http/1.1이라는 값으로 식별됩니다.
사용자가 브라우저 주소창에 https://로 시작하는 주소를 입력하면,
브라우저는 "나는 이런 방식으로 통신할 수 있다"는 후보를 서버에 제시합니다.
서버는 그 중 하나를 선택하고, 그 이후에야 실제 HTTP 요청과 응답이 오갑니다.
개발자도구에서 보이는 h2나 http/1.1은 접속 순간에 이미 협상이 끝난 결과입니다.
서버 설정과의 연결 고리
이 내용은 서버 운영 관점에서 Apache httpd 설정과도 바로 연결됩니다.
Apache 공식 문서에 따르면 HTTP/2는 자동으로 활성화되지 않습니다.
mod_http2 모듈과 Protocols 설정을 통해 명시적으로 켜야 합니다.
또한 Apache는 TLS 기반의 h2와 평문 TCP 기반의 h2c를 구분해서 처리합니다.
"왜 여기는 HTTP/2로 붙고, 저기는 HTTP/1.1로 붙지?"라는 질문은 결국 서버 설정과 맞닿아 있습니다.
이 시리즈에서 다룰 내용
이번 시리즈는 개념 설명으로만 끝내지 않을 예정입니다.
- HTTP/1.1과 HTTP/2의 구조, 차이, 장단점 비교
- HTTPS, TLS, ALPN 협상 과정에서 브라우저와 서버가 버전을 선택하는 흐름
- 실제 리눅스 환경에 Apache httpd를 올려 HTTP/1.1, HTTP/2 각각 활성화 및 브라우저 확인
- 브라우저 개발자도구와 패킷 캡처로 실제 네트워크에서 동작하는 모습 검증
개념, 협상 원리, 서버 설정, 실제 검증까지 한 흐름으로 이어보는 것이 이번 시리즈의 핵심입니다.
