[4회차] HTTP는 왜 1.1에서 2, 3까지 진화했을까?

[github-actions[bot]]

🚀 발표 주제

HTTP는 왜 1.1에서 2, 3까지 진화했을까?

---

📅 발표일

2026-06-22

🙋 발표자

스타크

🗂️ 카테고리

🌐 Network

📚 발표 자료

업로드 예정

🎥 발표 영상

업로드 예정

---

🎯 핵심 개념 요약

HTTP 버전은 이전 버전의 병목을 해결해온 과정이다.

HTTP/1.1 — 연결 재사용, 그러나 HOL Blocking

• 연결을 매번 새로 만들던 1.0과 달리, 연결을 재사용(keep-alive)해 비용을 줄임
• 하지만 한 연결 안에서는 요청이 순서대로 처리돼서, 앞 응답이 막히면 뒤가 다 막히는 HOL(Head-of-Line) Blocking이 발생
• 브라우저는 우회책으로 같은 서버에 연결을 6개쯤 동시에 열어 병렬화 → 근본 해결이 아닌 우회

HTTP/2 — Frame & Multiplexing

• 요청/응답을 Frame 단위로 쪼개고, 하나의 연결에서 여러 요청을 Multiplexing으로 동시 처리
• HTTP 계층의 HOL Blocking은 해소
• 단, 여전히 TCP 위에서 동작 → TCP 계층의 HOL Blocking은 남음 (패킷 하나 손실되면 연결 전체가 대기)

HTTP/3 — QUIC over UDP

• TCP를 버리고 UDP 기반 QUIC 사용
• Stream 독립성: Stream A에서 패킷이 손실돼도 A만 재전송을 기다리고 B·C는 계속 진행 → TCP 계층 HOL Blocking 완화
• 연결 수립 개선: TLS 1.3을 통합해 handshake 왕복을 줄이고, 재방문 시 0-RTT로 첫 데이터를 바로 전송

🔗 미션과의 연결

백엔드 개발자는 보통 Controller·Service·Repository 위에서 일하지만, 그 아래 HTTP 계층을 알면:

• API 응답 지연의 원인을 네트워크 계층까지 내려가 파악할 수 있다
• Nginx·ALB·CDN의 HTTP/2·3 설정이 무슨 의미인지 이해하고 선택할 수 있다
• 성능을 "그냥 빠르다/느리다"가 아니라 "어떤 병목이 있고 어느 버전이 유리한지"로 판단할 수 있다

📚 참고 자료

• MDN Web Docs — Evolution of HTTP
• RFC 9110 (HTTP Semantics), RFC 9114 (HTTP/3), RFC 9000 (QUIC)
• Cloudflare Blog — HTTP/3 & QUIC 시리즈

---

🙋‍♀️ 질문

1. HTTP/1.1에서 브라우저는 같은 서버에 연결을 여러 개 열어 HOL Blocking에 대응했습니다. 이 방식이 어떻게 HOL Blocking을 완화하는지, 그리고 왜 "해결"이 아니라 "우회"라고 부르는지 설명해주세요.

2. HTTP/2는 Multiplexing으로 HTTP 계층의 HOL Blocking을 해결했지만, TCP 계층의 HOL Blocking은 여전히 남아있습니다. 왜 HTTP/2에서는 이 문제가 남게 되는지, 그리고 HTTP/3는 어떤 방식으로 이를 해결했는지 설명해주세요.

3. HTTP/3는 TCP가 아닌 UDP를 기반으로 만들어졌습니다. UDP는 신뢰성을 보장하지 않는데도 HTTP/3가 어떻게 안정적인 데이터 전송을 할 수 있을까요?

[2Jaeheon]

1. HTTP/1.1에서 브라우저는 같은 서버에 연결을 여러 개 열어 HOL Blocking에 대응했습니다. 이 방식이 어떻게 HOL Blocking을 완화하는지, 그리고 왜 "해결"이 아니라 "우회"라고 부르는지 설명해주세요.

HTTP/1.1에서 브라우저가 같은 서버에 여러 연결을 여는 이유는 요청을 한 줄에만 세우지 않기 위해서? 라고 생각합니다. 한 연결만 쓰면 앞 요청의 응답이 늦어질 때 뒤 요청들도 같이 기다려야 합니다. 근데 연결을 여러 개 열면 요청들이 여러 연결로 나뉘어서 처리되기 때문에, 한 연결에서 응답이 막혀도 다른 연결에서는 다른 요청이 계속 진행됩니다.

다만 이 방식은 HOL Blocking을 없앤 것은 아닙니다. 각각의 연결 안에서는 여전히 앞 응답이 막히면 뒤 응답이 영향을 받을 수 있습니다. 즉, 문제 자체를 해결한 것이 아니라 막히는 줄을 여러 개로 나눠서 영향 범위를 줄인 방식에 가깝습니다. 따라서 우회라고 말한 것 같습니다.

---

2. HTTP/2는 Multiplexing으로 HTTP 계층의 HOL Blocking을 해결했지만, TCP 계층의 HOL Blocking은 여전히 남아있습니다. 왜 HTTP/2에서는 이 문제가 남게 되는지, 그리고 HTTP/3는 어떤 방식으로 이를 해결했는지 설명해주세요.

HTTP/2는 요청과 응답을 frame 단위로 나누고, 여러 stream을 하나의 연결 안에서 섞어서 보낼 수 있습니다.
그래서 HTTP 입장에서는 한 응답이 끝날 때까지 다음 응답을 기다릴 필요가 줄어듭니다.

이 부분에서 HTTP 계층의 HOL Blocking은 많이 해결됩니다.

하지만 HTTP/2도 결국 TCP 위에서 동작합니다. TCP는 데이터를 순서대로 전달해야 하는 프로토콜이라서, 중간에 패킷 하나가 손실되면 그 뒤의 데이터가 이미 도착했더라도 애플리케이션에 바로 넘기지 못합니다.

HTTP/2의 여러 stream이 하나의 TCP 연결을 공유하기 때문에, TCP 계층에서 패킷 손실이 생기면 여러 stream이 같이 영향을 받을 수 있습니다.

HTTP/3는 이 문제를 줄이기 위해 TCP 대신 QUIC을 사용합니다. QUIC은 UDP 위에서 동작하면서 stream을 독립적으로 관리하기 때문에 하나의 stream에서 패킷 손실이 발생해도 그 stream만 재전송을 기다리고, 다른 stream은 계속 진행할 수 있습니다.

---

3. HTTP/3는 TCP가 아닌 UDP를 기반으로 만들어졌습니다. UDP는 신뢰성을 보장하지 않는데도 HTTP/3가 어떻게 안정적인 데이터 전송을 할 수 있을까요?

UDP는 기본적으로 신뢰성을 보장하지 않습니다. 패킷이 사라져도 다시 보내주지 않고, 순서도 보장하지 않습니다. HTTP/3는 UDP를 그대로 사용하는 것이 아니라, UDP 위에 QUIC이라는 프로토콜을 올려서 사용합니다. TCP가 하던 신뢰성 보장 기능 중 필요한 것들을 QUIC이 애플리케이션 계층에 더 가깝게 구현한 것? 으로 알고 있습니다.

[wontop02]

1. HTTP/1.1에서 브라우저는 같은 서버에 연결을 여러 개 열어 HOL Blocking에 대응했습니다. 이 방식이 어떻게 HOL Blocking을 완화하는지, 그리고 왜 "해결"이 아니라 "우회"라고 부르는지 설명해주세요.

HTTP/1.1은 HOL Blocking을 분산시키기 위해, 브라우저가 동일한 서버에 6개 정도의 연결을 열어 병렬화하는 방법을 사용합니다.
하지만 한 연결 안에서는 요청이 순서대로 처리되어, 앞 응답이 막히면 뒤의 응답이 모두 막히는 HOL Blocking이 발생하기 때문에 근본적인 해결이 아닌, 우회라고 부릅니다.

2. HTTP/2는 Multiplexing으로 HTTP 계층의 HOL Blocking을 해결했지만, TCP 계층의 HOL Blocking은 여전히 남아있습니다. 왜 HTTP/2에서는 이 문제가 남게 되는지, 그리고 HTTP/3는 어떤 방식으로 이를 해결했는지 설명해주세요.

Multiplexing은 TCP 위에서 동작하기 때문에, HTTP 계층의 HOL Blocking은 해결해도 TCP 계층의 HOL Blocking은 해결하지 못합니다. 즉, 패킷 하나가 손실되면 연결 전체가 대기하게 됩니다.
HTTP/3은 이 문제를 해결하기 위해 TCP 대신 UDP 기반의 QUIC를 사용해, 특정 패킷이 손실되어도 다른 패킷은 정상적으로 진행하도록 해결했습니다.

3. HTTP/3는 TCP가 아닌 UDP를 기반으로 만들어졌습니다. UDP는 신뢰성을 보장하지 않는데도 HTTP/3가 어떻게 안정적인 데이터 전송을 할 수 있을까요?

UDP 위에 QUIC라는 새로운 프로토콜을 얹어 신뢰성을 확보합니다. TCP가 처리하던 패킷 손실 감지, 재전송 등을 QUIC가 애플리케이션 계층에서 직접 구현해 통제합니다.

[Jiihyun]

HTTP/1.1에서 브라우저는 같은 서버에 연결을 여러 개 열어 HOL Blocking에 대응했습니다. 이 방식이 어떻게 HOL Blocking을 완화하는지, 그리고 왜 "해결"이 아니라 "우회"라고 부르는지 설명해주세요.

예전의 HTTP/1.1에서는 하나의 TCP 연결에서 요청을 순차적으로 처리했기 때문에, 앞선 요청의 응답이 지연되면 뒤따르는 요청도 함께 대기해야 하는 HOL Blocking 문제가 발생했습니다.
이를 완화하기 위해 브라우저는 동일한 서버와 여러 개의 TCP 연결을 생성하여 요청을 분산했습니다. 서로 다른 연결에 있는 요청들은 영향을 받지 않으므로 대기 시간이 줄어드는 효과가 있었습니다.
하지만 각 TCP 연결 내부에서는 여전히 요청이 순차적으로 처리되기 때문에 HOL Blocking 자체는 그대로 존재했습니다.
따라서 문제를 제거한 것이 아니라 여러 연결로 분산하여 영향을 줄인 것이므로, 이를 HOL Blocking을 해결한 것이 아니라 우회(Workaround)한 방식이라고 합니다.

HTTP/2는 Multiplexing으로 HTTP 계층의 HOL Blocking을 해결했지만, TCP 계층의 HOL Blocking은 여전히 남아있습니다. 왜 HTTP/2에서는 이 문제가 남게 되는지, 그리고 HTTP/3는 어떤 방식으로 이를 해결했는지 설명해주세요.

HTTP/2는 전송 계층으로 TCP를 그대로 사용하며, HTTP/2의 모든 스트림이 하나의 TCP 연결을 공유합니다.
TCP는 신뢰성과 순서 보장을 제공하는 프로토콜이기에, 전송 중 하나의 패킷이 손실되면 이후의 패킷이 먼저 도착했더라도 손실된 패킷이 재전송될 때까지 애플리케이션에 전달하지 않습니다.즉, 특정 스트림의 패킷 손실이 다른 스트림까지 영향을 주기에, TCP 계층의 HOL Blocking이 여전히 남아있다고 볼 수 있습니다.
이를 해결하기 위해 HTTP/3는 TCP 대신 QUIC을 사용합니다.
QUIC은 UDP 기반으로 동작하며, 각 스트림마다 독립적으로 순서와 재전송을 관리합니다. 따라서 Stream 1에서 패킷이 손실되더라도 Stream 2와 Stream 3은 영향을 받지 않고 계속 데이터를 주고받을 수 있습니다.

HTTP/3는 TCP가 아닌 UDP를 기반으로 만들어졌습니다. UDP는 신뢰성을 보장하지 않는데도 HTTP/3가 어떻게 안정적인 데이터 전송을 할 수 있을까요?

HTTP/3는 QUIC이라는 전송 프로토콜 위에서 동작하며, TCP가 제공하던 신뢰성 기능을 QUIC이 애플리케이션에서 직접 구현합니다.
예를 들어, 패킷이 손실되면 QUIC이 이를 감지하여 재전송하고, 패킷의 순서를 맞춰 전달하며, 흐름 제어와 혼잡 제어도 자체적으로 수행합니다.
즉, UDP는 단순히 데이터를 빠르게 전달하는 역할만 하고, 안정적인 데이터 전송은 QUIC이 담당합니다.
그래서 HTTP/3는 UDP를 사용하면서도 TCP 수준의 신뢰성을 제공할 수 있으며, 동시에 스트림별 독립적인 전송을 통해 TCP의 HOL Blocking 문제도 해결했습니다.

[Jihyun3478]

1. HTTP/1.1에서 브라우저는 같은 서버에 연결을 여러 개 열어 HOL Blocking에 대응했습니다. 이 방식이 어떻게 HOL Blocking을 완화하는지, 그리고 왜 "해결"이 아니라 "우회"라고 부르는지 설명해주세요.

HOL Blocking의 본질은 단일 큐의 순차 처리입니다. 다중 연결은 이 구조를 바꾼 게 아니라 큐를 여러 개 만든 것이라 생각합니다. 각 연결 내부에서는 여전히 동일한 문제가 존재합니다.

---

2. HTTP/2는 Multiplexing으로 HTTP 계층의 HOL Blocking을 해결했지만, TCP 계층의 HOL Blocking은 여전히 남아있습니다. 왜 HTTP/2에서는 이 문제가 남게 되는지, 그리고 HTTP/3는 어떤 방식으로 이를 해결했는지 설명해주세요.

TCP는 바이트 스트림의 순서 보장이 핵심입니다. 패킷 하나가 유실되면 이후 패킷을 버퍼에 쌓아두고 재전송을 기다립니다. HTTP/2의 스트림은 논리적 개념일 뿐, TCP 입장에서는 단일 바이트 스트림이라 패킷 하나 유실 → 전체 스트림 블로킹이 발생합니다.

HTTP/3는 TCP 대신 QUIC(UDP 기반) 을 사용합니다. QUIC은 스트림을 전송 계층에서 독립적으로 관리하므로, 특정 스트림의 패킷이 유실되어도 다른 스트림은 영향받지 않습니다.

---

3. HTTP/3는 TCP가 아닌 UDP를 기반으로 만들어졌습니다. UDP는 신뢰성을 보장하지 않는데도 HTTP/3가 어떻게 안정적인 데이터 전송을 할 수 있을까요?

UDP는 신뢰성을 제공하지 않지만, QUIC이 애플리케이션 계층에서 직접 구현합니다.

• 패킷 손실 감지 및 재전송
• 흐름 제어 / 혼잡 제어
• 연결 상태 관리 (Connection ID 기반)

TCP가 OS 커널에서 이를 처리했다면, QUIC은 이 모든 것을 UDP 위에서 직접 구현한 것입니다. 덕분에 OS에 종속되지 않고 더 빠르게 프로토콜을 개선할 수 있다는 장점도 있습니다.

[Soojin6943]

HTTP/1.1에서 브라우저는 같은 서버에 연결을 여러 개 열어 HOL Blocking에 대응했습니다. 이 방식이 어떻게 HOL Blocking을 완화하는지, 그리고 왜 "해결"이 아니라 "우회"라고 부르는지 설명해주세요.

하나의 커넥션에 느린 요청이 다른 커넥션에 영향을 주지 않지만, 해당 커넥션 내에서는 여전히 HOL Blocking 문제가 발생할 수 있습니다. 해당 방식은 문제를 해결한 것이 아닌 단지 다른 커넥션으로 요청을 분산시킨 것이기에 "우회"라고 부릅니다.

HTTP/2는 Multiplexing으로 HTTP 계층의 HOL Blocking을 해결했지만, TCP 계층의 HOL Blocking은 여전히 남아있습니다. 왜 HTTP/2에서는 이 문제가 남게 되는지, 그리고 HTTP/3는 어떤 방식으로 이를 해결했는지 설명해주세요.

TCP는 신뢰성을 보장하는 프로토콜이기에 중간 패킷이 손실되면 뒤의 패킷을 받아도 애플리케이션에 넘기지 않기 때문에 TCP 계층의 HOL Blocking 문제가 남게됩니다.
HTTP/3에서는 이 문제를 해결하기 위해 TCP를 버리고 QUIC를 사용합니다.QUIC는 stream마다 독립적으로 재전송합니다. 즉, 한 스트림이 다른 스트림을 막지 않습니다.

HTTP/3는 TCP가 아닌 UDP를 기반으로 만들어졌습니다. UDP는 신뢰성을 보장하지 않는데도 HTTP/3가 어떻게 안정적인 데이터 전송을 할 수 있을까요?

QUID를 사용하여 신뢰성을 구현했습니다.