[Network] HTTP 1.1 vs HTTP 2.0 : 구조적 한계

웹 생태계의 복잡도가 증가함에 따라 HTTP 1.1 표준은 성능상의 한계로 HTTP 2.0 이 등장하였다. 요즘 회사에서도 (옆 팀에서) MSA 에 관한 주제로 많은 이야기를 하고 있으며 HTTP 2.0 이 언급되었다. 

1. HTTP 1.1 의 한계: 직렬 처리의 병목

HTTP 1.1은 기본적으로 텍스트 기반이며, 요청과 응답이 순차적으로 이루어지는 구조를 가진다. 이는 현대의 웹 환경에서 두 가지 치명적인 비효율을 야기했다.

HOL Blocking (Head of Line Blocking)

HTTP 1.1은 한 번에 하나의 요청만 처리 가능하다(Pipelining이 존재했으나 안정성 문제로 사장됨). 앞선 요청의 처리가 지연되면 후속 요청들이 모두 대기해야 하는 병목 현상이 발생한다.

헤더의 중복 전송

매 요청마다 User-Agent, Cookie 등 동일한 헤더 정보를 반복해서 전송한다. 요청 본문(Body)보다 헤더가 더 큰 경우가 발생하여 네트워크 대역폭을 낭비한다.

2. HTTP 2.0의 혁신: 성능을 위한 재설계

HTTP 2.0 은 기존 1.1의 의미론(Method, Status Code 등)은 유지하되, 데이터 전송 방식(Transport)을 완전히 재설계하였다.

멀티플렉싱 (Multiplexing)

가장 핵심적인 변화다. 단일 TCP 연결(Connection) 내에서 여러 개의 데이터 스트림(Stream)을 사용하여 다수의 요청과 응답을 동시에 주고받는다.

• 작동 원리: 데이터를 잘게 쪼갠 '프레임(Frame)' 단위로 전송하며, 수신 측에서 이를 스트림 ID에 따라 재조립한다. 이로써 HTTP 레벨의 HOL Blocking 문제를 완벽히 해결하였다.

바이너리 프레이밍 (Binary Framing)

사람이 읽을 수 있는 텍스트(Text) 기반이었던 1.1과 달리, 2.0은 데이터를 바이너리(0과 1)로 변환하여 전송한다.

• 장점: 파싱(Parsing) 속도가 비약적으로 상승하며, 텍스트 전송 시 발생할 수 있는 공백이나 줄 바꿈 등의 오류 가능성을 차단한다.

헤더 압축 (HPACK)

HTTP 2.0은 HPACK 알고리즘을 도입하여 헤더의 크기를 획기적으로 줄였다.

• 방식: 클라이언트와 서버가 서로 헤더 정보의 테이블(Dynamic/Static Table)을 유지한다. 중복된 헤더는 인덱스(Index)만 전송하고, 변경된 값만 실제 데이터로 보내 대역폭을 절약한다.

3. HTTP 2.0의 구조적 한계점 (TCP의 딜레마)

HTTP 2.0이 웹 성능을 크게 개선한 것은 사실이나, 근본적인 전송 계층 프로토콜인 TCP(Transmission Control Protocol) 위에서 동작하기 때문에 발생하는 태생적 한계가 존재한다.

TCP 수준의 HOL Blocking (Packet Level Blocking)

HTTP 2.0은 HTTP 메시지 수준의 줄 서기 문제는 해결했으나, TCP 패킷 수준의 줄 서기 문제는 해결하지 못했다.

• 현상: TCP는 신뢰성을 보장하기 위해 패킷의 순서를 엄격히 지킨다. 만약 패킷 하나가 네트워크에서 유실(Loss)되면, 해당 패킷이 재전송되어 도착할 때까지 그 뒤의 모든 패킷 처리가 중단된다.
• 역설: HTTP 2.0은 단일 연결(Single Connection)을 사용하므로, 패킷 유실이 발생할 경우 연결된 모든 스트림이 동시에 멈추는 현상이 발생한다. 네트워크 환경이 불안정할 경우, 다중 연결을 사용하는 HTTP 1.1보다 오히려 속도가 느려질 수 있다.

TCP 연결 수립의 지연 (Handshake Overhead)

데이터를 보내기 전, TCP 연결을 위한 3-Way Handshake와 암호화를 위한 TLS Handshake 과정이 반드시 선행되어야 한다. 이는 실제 데이터를 전송하기 전까지 상당한 시간(RTT)을 소모하게 만들며, 모바일 네트워크처럼 연결이 자주 끊기는 환경에서는 큰 오버헤드로 작용한다.

4. Deep Dive

HTTP 2.0 은 HTTPS 가 필수인가?

• 표준(RFC)의 입장: No. 표준 스펙상으로는 암호화되지 않은 TCP(h2c) 위에서도 HTTP 2.0을 구현할 수 있다.
• 브라우저의 입장: 맞다. Yes. Chrome, Firefox 등 대다수의 모던 브라우저는 보안상의 이유로 암호화된 연결(HTTPS)일 때만 HTTP 2.0 통신을 지원한다. 따라서 실무에서 HTTP 2.0을 사용하려면 HTTPS 적용이 선행되어야 한다.

Server Push 의 몰락과 Early Hints

HTTP 2.0의 주요 기능으로 소개되던 'Server Push'(클라이언트 요청 없이 리소스를 미리 밀어 넣어주는 기능)는 현재 사용이 권장되지 않는다.

• 이유: 구현이 복잡하고, 브라우저 캐시를 고려하지 않고 무조건 데이터를 보내는 비효율성 문제가 제기되었다.
• 현황: Google Chrome은 2022년 106 버전부터 Server Push 지원을 기본 비활성화했다. 대신, 리소스 로딩 힌트만 주는 HTTP 103 Early Hints가 그 대안으로 떠오르고 있다.

개발자 도구로 프로토콜 확인하기

1. 브라우저에서 F12를 눌러 개발자 도구를 연다.
2. Network 탭으로 이동한다.
3. 헤더 칼럼(Name, Status 등) 우클릭 -> Protocol을 체크한다.
4. h2라고 표시되면 HTTP 2.0, http/1.1이면 HTTP 1.1 통신 중이다.