들어가며
Keep Alive를 공부하던 중, HTTP 1.1과 HTTP 2.0 사이에 차이가 있다는 점을 발견했습니다. 이왕 정리하는 김에 두 버전 간의 주요 차이점을 정리해보려 합니다.
HTTP 1.1의 특징
Keep Alive
HTTP 1.0에서는 요청마다 TCP 연결을 새로 생성하는 것이 기본이었습니다. 이는 연결 생성 비용이 크고 지연 시간이 발생하는 단점이 있었습니다. HTTP 1.1부터 기본적으로 Keep-Alive가 적용되어, 하나의 TCP 연결을 유지하며 요청을 처리할 수 있게 되었습니다.
HOL(Head Of Line) Blocking 문제
HTTP 1.1은 동일 TCP 연결 내에서 요청과 응답을 순차적으로 처리는 구조입니다. 따라서, 먼저 보낸 요청의 응답이 늦어질 경우, 그 뒤에 보낸 요청들의 응답도 모두 지연되는 문제가 발생합니다. 이를 HTTP 계층의 HOL Blocking 현상이라고 부릅니다. 이 문제를 해결하기 위해, 브라우저는 하나의 서버에 대해 여러 개의 TCP 연결을 생성하여 병렬로 요청을 보내는 방식을 사용했습니다. 하지만, TCP 연결 수 제한, 연결 수 증가에 따른 리소스 낭비 등의 한계가 존재합니다.
HTTP 2.0의 특징
Binary Protocol
HTTP 1.X은 사람이 읽을 수 있는 텍스트 기반 프로토콜을 사용했습니다. 예를 들어, 요청과 응답 데이터가 줄바꿈, 공백, 콜론 등을 기준으로 구분되었습니다. 하지만, 이런 방식은 파싱할 때 문자열 처리가 필요하고, 구분자 오류와 인코딩 문제들이 발생할 수 있습니다. 이로 인해, 처리 속도가 느리고 파싱 비용이 높다는 단점이 존재합니다. HTTP/2는 이러한 문제를 해결하기 위해 Binary Protocol을 사용합니다. 이는 데이터가 프레임 구조로 처리되기 때문에 구분자를 찾거나 문자열을 파싱하지 않아도 되고, Header/Body/Control 정보가 명확히 구분되어 있어 파싱 비용이 감소하고 프로토콜 해석 속도가 증가했습니다.
MultiPlexing
단일 TCP 연결에서 여러 개의 Stream 처리가 가능해졌습니다. 각 Stream은 독립적으로 동작하기 때문에, HTTP 레이어의 HOL Blocking 문제가 발생하지 않습니다. 이에 따라, 하나의 TCP 연결로 수십 ~ 수백 개의 요청 처리가 가능해졌습니다.
왜, TCP 계층의 HOL Blocking은 해결할 수 없나요?
TCP 프토토콜은 데이터를 순서대로 그리고 신뢰성 있게 전달하기 위해 설계되었기 때문입니다. 즉, TCP 프로토콜은 순서 보장을 위해 앞 패킷이 손실되면 뒤 패킷도 처리하지 않는 구조라, HOL Blocking 문제를 피할 수 없습니다.
Header Compression (HPACK)
HTTP/1.1은 매 요청마다 동일한 헤더를 전송하기 때문에, 쿠키, 토큰 등 고정 값이 많을수록 네트워크 낭비가 심해졌습니다. HTTP/2는 HPACK 압축 기법을 통해 이런 중복 헤더 데이터를 제거하고, 변경된 부분만 전송하기 때문에 특히 모바일처럼 네트워크 자원이 제한적인 환경에서 대역폭 절약 효과가 크게 나타납니다.
Server Push
클라이언트 요청이 없어도 서버가 리소스를 미리 전송할 수 있는 기능입니다. 이를 통해 HTML을 받자마자 CSS와 JS를 미리 전송하여 초기 응답 속도를 개선할 수 있습니다. 하지만, 캐싱 처리의 복잡성, 불필요한 리소스 전송 가능성 등의 이유로 최근에는 오히려 사용 빈도가 낮아지는 추세입니다.
