HTTP/1.1, HTTP/2, HTTP/3의 차이는 무엇인가?

Question

IT Interview Practice · Accepted Answer

셋 다 같은 HTTP 의미론(method, header, status code)을 제공하지만, 바이트를 회선 위로 *어떻게* 옮기는지가 다르다 — 각 버전이 이전 버전의 병목을 고친다. 관통하는 주제는 하나의 멈춘 request가 다른 것들을 막는 **head-of-line (HOL) blocking 제거**다.

```text
HTTP/1.1  over TCP     one request at a time per connection
  conn ──[req A]──[req B]──[req C]──▶   B waits for A (HOL blocking at HTTP layer)

HTTP/2    over TCP     many streams multiplexed on ONE connection
  conn ══[A|B|C interleaved]══▶        but a lost TCP packet stalls ALL streams
                                       (HOL blocking moves down to TCP)

HTTP/3    over QUIC (UDP)   independent streams, per-stream delivery
  conn ══[A][B][C]══▶                  a lost packet stalls only its own stream
```

**HTTP/1.1**은 연결당 한 번에 하나의 request를 보낸다; 브라우저는 host당 ~6개의 병렬 연결을 열어 이를 우회하고, 텍스트 header는 압축 없이 전송된다. **HTTP/2**는 **multiplexing** — 단일 연결 위의 여러 동시 **stream** — 에 더해 binary framing, header 압축(HPACK), server push를 추가한다. 그러나 여전히 TCP 위에서 실행되므로, 단 하나의 유실된 패킷이 retransmit될 때까지 *모든* stream을 막는다: HOL blocking이 그저 HTTP 계층에서 TCP로 내려간 것이다.

**HTTP/3**는 **UDP** 위에 세워진 새로운 transport인 **QUIC** 위에서 실행함으로써 그것을 해결한다. QUIC은 stream을 스스로 구현하므로, 한 stream의 유실이 다른 stream을 막지 않는다. 그것은 또한 transport와 TLS handshake를 병합하고(1-RTT, 재개 시 종종 0-RTT) 더 빠른 연결 설정을 하며, 세션이 네트워크 변경(Wi-Fi → cellular)을 견디도록 **connection migration**을 지원한다.

## 왜 중요한가

이것은 인기 있는 미들급 질문인데, 답이 *문제 → 해결 → 새로운 문제 → 해결*의 이야기이기 때문이며, 이는 바로 뛰어난 엔지니어가 진화하는 시스템에 대해 추론하는 방식이다. 면접관이 찾는 핵심 통찰은 **두 계층에서의 head-of-line blocking**을 이해하는 것이다: HTTP/2는 애플리케이션 계층에서 그것을 해결했지만 여전히 TCP 아래 갇혀 있었고, HTTP/3는 작업을 끝내기 위해 transport 자체를 바꿔야 했다. 그것은 또한 실용적이다: 이를 아는 것은 연결 재사용, 여전히 domain을 shard할지, CDN에서 HTTP/3를 켜서 무엇을 얻는지에 대한 실제 결정을 안내한다.

왜 중요한가

관련 질문