Http(1.1, 2, 3) | Thomas Kim

HTTP/1.1 과 HTTP/2 의 차이에 대해서 묻는 질문은 엔지니어 면접에서 자주 등장한다.

당연히 단순히 HTTP/2 가 빠르다는 대답을 듣기 위해서는 아닐 것이다.

각 버전이 해결하려고 했던 문제가 무엇이고, 어떤 기술적 접근으로 해결했는지, 그리고 왜 HTTP/3 가 필요했는지를 이해해야 한다.

일단 HTTP/1.0 에서 개선된 HTTP/1.1 부터 살펴보자.

HTTP/1.1 (1997): 순차적 요청 - 응답의 한계

HTTP/1.1 은 텍스트 기반 프로토콜이다. 사람이 읽을 수 있는 형태의 헤더와 메서드를 사용한다.

GET /index.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html
Connection: keep-alive

주요 개선사항 (HTTP/1.0 대비)

Keep-Alive: 하나의 TCP 연결에서 여러 요청-응답 처리 가능
Host 헤더: 하나의 IP 에서 여러 도메인 호스팅 (가상 호스트)
Chunked Transfer Encoding: Content-Length 없이도 전송 가능
캐시 제어: ETag, Cache-Control 등 정교한 캐싱

많은 것이 개선되었지만, 여전히 문제는 있었다.

Head-of-Line (HOL) Blocking

가장 큰 문제는 HOL Blocking 이었다. 하나의 TCP 연결에서는 요청과 응답이 순차적으로만 처리된다.

말만 들어서는 문제가 없어보이지만 그렇지 않다. 줄이 하나뿐인 식당을 생각하면 된다.

HTTP/1.1 Pipelining: Sequential Request Processing

Pipelining 시도와 실패

HTTP/1.1 은 Pipelining 기능을 제공했다. 여러 요청을 연속으로 보낼 수 있지만, 응답은 여전히 순서대로 받아야한다.

Head-of-Line Blocking in HTTP/1.1

결과적으로 대부분의 브라우저는 Pipelining을 기본적으로 비활성화했다.

HTTP/2 (2015): 멀티플렉싱

Binary Framing Layer

HTTP/2 의 가장 근본적인 변화는 텍스트 기반에서 바이너리 프로토콜로의 전환이다.

HTTP 진화과정 이해하기 두번째 - HTTP/2.0

바이너리의 장점은:

파싱이 효율적이다.
공백, 줄바꿈 등 애매한 부분을 제거해서 오류 가능성이 감소한다.
더 작은 크기로 대역폭을 절약한다.

멀티플렉싱: Stream 과 Frame

HTTP/2의 핵심 개념은 멀티플렉싱이다. 하나의 TCP 연결에서 여러 요청-응답을 동시에 처리할 수 있다.

동시에 여러 요청을 처리하고, 순서 무관하게 응답이 가능하다는 것이다.

Stream:

각 요청-응답 쌍은 고유한 Stream ID 를 가진다.
클라이언트가 시작: 홀수 ID
서버가 시작(Server Push): 짝수 ID
동시에 수백 개의 스트림 처리 가능

A Deep Dive into HTTP: From HTTP 1 to HTTP 3

Stream 우선순위 (Priority)

HTTP/2 는 스트림간 의존성과 가중치를 지정할 수가 있다.

의존성(dependency) 의 경우 말 그대로 “D가 완료되면 C를 전송하겠다” 와 같은 것이다.

가중치(Weight) 는 형제 스트림간 대역폭 분배 비율이다. 예를들어 아래 그림에서 첫 번째를 보면, A와 B 의 전송 비율이 12:4 이다.

브라우저는 자동으로 리소스 타입별 우선순위를 설정하고, 서버는 우선순위를 힌트로 사용하여 전송 순서를 최적화한다.

근데 실제로는 구현 복잡도와 효과 대비 많이 사용되지 않는다.

Figure 12-4. HTTP/2 stream dependencies and weights

HPACK 헤더 압축

HTTP/1.1 에서는 매 요청마다 동일한 헤더를 반복 전송했다.

HTTP/2 는 HPACK 압축으로 이를 해결한다.

Figure 12-6. HPACK: Header Compression for HTTP/2

Server Push

HTTP/2 에서는 서버가 클라이언트 요청 없이도 리소스를 미리 전송할 수 있다.

High Performance with HTTP / 2 PUSH - Medianova

HTTP/2 의 남은 문제: TCP-Level HOL Blocking

HTTP/2가 Application-level HOL Blocking을 해결했지만, TCP 수준의 HOL Blocking은 여전히 존재한다.

TCP는 패킷을 전송할 때, 전달을 보장하기 때문에 패킷이 손실되면 재전송한다

이때, 패킷의 순서가 역전되지 않도록 후속 패킷이 대기한다. 즉, 먼저 보낸 패킷에서 손실이 발생하면 후속 패킷도 대기한다.

이것이 HTTP/3 가 TCP 를 버리고 QUIC 로 전환한 이유이다.

HTTP/3 (2022): QUIC

QUIC 프로토콜: UDP 위의 신뢰성

HTTP/3는 TCP 대신 QUIC(Quick UDP Internet Connections)을 사용한다.

QUIC은 구글이 개발한 차세대 통신 프로토콜로, UDP 위에 구축된 전송 프로토콜이다.

TLS 가 내장되어 있다.

QUIC이란 무엇입니까? HTTP/3를 어떻게 향상합니까? - 씨디네트웍스

TCP 는 운영체제 커널에 구현되어 있어 변경이 매우 어렵다.

또한 새로운 기능 추가 시 수년간의 표준화와 OS 업데이트가 필요하다.

UDP 는 단순한 데이터그램 전송만 제공하고, 그 위에 원하는대로 구현이 가능하다.

따라서 빠른 프로토콜 진화와 실험이 가능하다. 이것이 HTTP/3 에서 UDP 를 선택한 이유이고, 자연스레 TCP HOL Blocking 도 해결됐다.