HTTP 1.1과 HTTP 2 그리고 HTTP 3 차이 완전 정리 연결 방식부터 멀티플렉싱 헤더 압축 HPACK QPACK TLS까지

🔌 HTTP/1.1의 연결 구조와 한계

HTTP/1.1은 우리가 아는 전통적인 웹 요청 방식의 기반입니다.
클라이언트가 요청을 보내고 서버가 응답을 돌려주는, 아주 단순한 왕복 구조죠.
텍스트 기반 프로토콜이라서 실제로 패킷을 캡처해 보면 사람이 직접 읽을 수 있을 정도로 헤더와 바디가 그대로 노출됩니다.
문제는 이 단순함이 성능 앞에서 발목을 잡기 시작했다는 점입니다.
요즘 웹 페이지는 이미지, JS, CSS, 폰트 등 수십~수백 개의 리소스를 동시에 불러와야 하는데, HTTP/1.1은 기본적으로 그런 상황을 잘 처리하도록 설계된 프로토콜이 아니었거든요.

우선 연결 방식부터 살펴볼 필요가 있습니다.
HTTP/1.0 시절에는 요청 하나당 TCP 연결 하나를 열고, 응답이 끝나면 바로 닫는 방식이 일반적이었습니다.
이 방식은 RTT(왕복 지연 시간)가 큰 환경에서 치명적으로 비효율적이었죠.
HTTP/1.1은 이 문제를 해결하기 위해 지속 연결(persistent connection), 흔히 keep-alive라고 부르는 동작을 기본값으로 채택했습니다.
즉 한 번 TCP를 열면 그 위에서 여러 요청과 응답을 연달아 처리할 수 있게 한 겁니다.
서버나 클라이언트가 굳이 Connection: close 를 선언하지 않는 이상, 같은 TCP 소켓을 재사용한다는 의미예요.
이 변화만으로도 매 요청마다 TCP 핸드셰이크를 반복하는 낭비는 크게 줄었습니다.

그 다음으로 등장한 게 파이프라이닝(pipelining)입니다.
파이프라이닝은 HTTP/1.1에서 여러 요청을 한꺼번에 밀어 넣을 수 있도록 한 기능입니다.
즉 첫 번째 요청에 대한 응답을 기다리는 동안, 두 번째, 세 번째 요청을 미리 보내둘 수 있게 해줍니다.
이론만 보면 꽤 좋아 보이죠.
대기 시간을 줄여서 페이지 로딩을 더 빠르게 만들 수 있으니까요.
하지만 현실에서는 잘 쓰이지 않았습니다.
왜냐면 서버와 중간 프록시들이 이를 일관되게 잘 처리하지 못했고, 특히 응답은 반드시 요청 순서대로 돌아와야 한다는 제약이 있었기 때문입니다.
결국 중요하지 않은 큰 리소스가 맨 앞에 걸려 있으면, 그 뒤에 있는 가벼운 리소스들도 줄줄이 대기하게 되는 상황이 발생합니다.
이를 헤드 오브 라인 블로킹(Head-of-line blocking)이라고 부릅니다.

헤드 오브 라인 블로킹은 단순히 “조금 느리다” 수준의 문제가 아닙니다.
브라우저 입장에서 보면 이미지를 30개 불러와야 하는데 첫 번째 이미지 응답이 지연되면, 뒤에 있는 29개의 응답도 같이 막히는 거예요.
왜냐면 HTTP/1.1 파이프라이닝에서는 응답이 항상 FIFO(먼저 온 요청 먼저 처리) 순서로 흘러오기 때문입니다.
그래서 실제 브라우저들은 파이프라이닝을 공격적으로 활용하기보다, 아예 여러 TCP 연결을 병렬로 여는 쪽을 선택했습니다.
즉 같은 도메인에 대해 6개 정도까지(브라우저마다 제한이 있음) TCP 커넥션을 동시에 열어버리고, 요청들을 적당히 분산해서 보내버리는 방식이 일반화됐습니다.
결국 이건 서버/클라우드 입장에서는 커넥션 수가 폭발적으로 늘어난다는 뜻이고, 모바일 네트워크처럼 불안정한 환경에서는 오버헤드가 큽니다.

정리하자면 HTTP/1.1은
지속 연결로 TCP 재사용이 가능하고,
이론적으로 파이프라이닝까지 허용하지만,
여전히 한 연결 안에서는 요청·응답 순서에 종속되는 직렬 처리 구조라는 태생적 한계를 갖고 있습니다.
이 구조 때문에 리소스가 많은 현대 웹 환경에서는 네트워크 레벨에서 불필요한 지연과 병목이 쉽게 발생합니다.
결국 이런 한계를 해결하기 위해 HTTP/2에서는 완전히 다른 접근, 즉 “하나의 연결 위에서 여러 스트림을 동시에 흘려보내자”라는 개념인 멀티플렉싱을 도입하게 됩니다.

• 🔁HTTP/1.1은 지속 연결을 기본 지원하여 같은 TCP 연결을 재사용한다.
• 📦파이프라이닝은 여러 요청을 연달아 보낼 수 있지만 응답 순서는 항상 FIFO라서 쉽게 막힌다.
• 🚧이 FIFO 구조 때문에 발생하는 병목을 헤드 오브 라인 블로킹이라고 부른다.
• 📡현실적으로는 브라우저가 커넥션을 여러 개 여는 꼼수로 병목을 완화했지만, 서버 자원 부담은 커졌다.

이렇게 보면 HTTP/1.1은 애초에 “웹 문서 몇 개 가져오는 시대”를 전제로 설계된 프로토콜이었다는 걸 알 수 있습니다.
요즘처럼 SPA 번들, 이미지 최적화 리소스, 실시간 데이터까지 한 화면에서 쓸어오는 시대에는 구조적으로 버거운 모델이라는 거죠.
그리고 이런 한계가 HTTP/2의 이진 프레이밍, 멀티플렉싱, 헤더 압축(HPACK) 같은 혁신으로 이어지게 됩니다.

🚇 HTTP/2의 스트림과 멀티플렉싱

HTTP/2는 웹 전송 구조를 근본적으로 바꿔놓은 버전입니다.
이전의 HTTP/1.1이 텍스트 기반이었다면, HTTP/2는 모든 요청과 응답을 이진 프레이밍(binary framing)이라는 구조로 바꿨습니다.
즉 클라이언트와 서버가 데이터를 주고받을 때 더 이상 사람이 읽을 수 있는 평문 형태가 아니라, 프레임 단위로 나누어진 바이너리 패킷을 주고받게 됩니다.
이 덕분에 네트워크가 데이터를 훨씬 더 효율적으로 처리할 수 있고, 무엇보다 새로운 핵심 개념인 멀티플렉싱(multiplexing)이 가능해졌습니다.

멀티플렉싱은 하나의 TCP 연결 위에서 여러 개의 요청과 응답 스트림을 동시에 흘려보내는 기술입니다.
HTTP/1.1에서는 요청 순서대로 응답이 와야 했지만, HTTP/2에서는 각각의 요청을 독립적인 스트림(stream)으로 관리하기 때문에, 한 요청의 응답이 지연돼도 다른 요청들이 영향을 받지 않습니다.
예를 들어 이미지, CSS, JS 파일을 동시에 받아올 때, 하나가 늦어지더라도 나머지는 정상적으로 처리됩니다.
이게 바로 HTTP/2가 페이지 로딩 속도를 획기적으로 개선시킨 핵심 원리입니다.

이 스트림 구조는 단순히 병렬 요청이 가능하다는 것 이상의 의미가 있습니다.
각 스트림에는 우선순위(priority)를 설정할 수 있어서, 브라우저가 중요 리소스(CSS나 초기 JS)를 먼저 받도록 조정할 수도 있죠.
또한 서버는 서버 푸시(Server Push)라는 기능을 통해, 클라이언트가 요청하지 않은 리소스라도 미리 보낼 수 있습니다.
예를 들어 HTML 문서를 요청하면, 서버가 이를 분석해서 필요한 CSS와 JS를 자동으로 함께 전송할 수 있는 거죠.
이로 인해 초기 로딩 시간을 단축할 수 있습니다.
다만 최근에는 HTTP/3나 브라우저 캐시 정책 변화로 인해 서버 푸시는 점점 권장되지 않는 추세이긴 합니다.

그럼에도 불구하고 HTTP/2의 가장 큰 한계는 여전히 TCP 기반이라는 점입니다.
TCP는 하나의 연결에서 패킷이 순서대로 도착해야만 데이터를 복원할 수 있는 구조라, 만약 어떤 패킷 하나가 손실되면 전체 데이터가 잠시 멈춰 버립니다.
이걸 전송 계층 레벨의 헤드 오브 라인 블로킹이라고 부르며, HTTP/2에서도 완전히 해결되지 못했습니다.
즉 애플리케이션 계층에서는 여러 스트림이 병렬로 움직이지만, TCP 레벨에서는 여전히 순서 보장을 위해 멈추는 구간이 생길 수 있다는 뜻입니다.

파이썬에서도 HTTP/2를 지원하는 라이브러리가 점점 늘어나고 있습니다.
대표적으로 hyper-h2 라이브러리는 순수 파이썬 구현으로 HTTP/2 프레이밍과 스트림 관리를 제공합니다.
또한 httpx는 h2 백엔드를 통해 HTTP/2 요청을 보낼 수 있고, 서버 측에서는 Hypercorn이나 Uvicorn + h2 구성을 통해 HTTP/2 서비스를 운영할 수 있습니다.
또한 대부분의 현대 웹 서버(Nginx, Apache, Caddy)는 TLS를 사용하면 자동으로 HTTP/2를 활성화합니다.

💬 HTTP/2는 ‘한 연결, 여러 스트림’ 구조로 바꾸어 브라우저의 병렬 요청 문제를 해결했지만, TCP의 특성 때문에 완벽한 병렬성을 구현하지는 못했습니다.

결국 HTTP/2는 HTTP/1.1의 성능 문제를 상당 부분 해결했지만, 여전히 전송 계층(TCP)의 한계를 벗어나지 못한 프로토콜입니다.
그래서 등장한 것이 HTTP/3입니다.
HTTP/3는 TCP를 완전히 버리고, UDP 기반의 QUIC(Quick UDP Internet Connections) 프로토콜을 바탕으로 설계되었습니다.
이로써 전송 계층부터 헤드 오브 라인 블로킹을 근본적으로 제거하고, TLS 보안을 기본 통합한 새로운 시대가 열리게 됩니다.

🚀 HTTP/3와 QUIC의 독립 스트림 구조

HTTP/3는 단순한 버전 업그레이드가 아닙니다.
TCP 기반에서 UDP 기반으로 완전히 갈아탄, 구조적인 혁신입니다.
이전 세대의 HTTP/2가 여전히 TCP의 흐름 제어와 순서 보장을 그대로 안고 있었다면, HTTP/3는 이를 벗어나기 위해 QUIC(Quick UDP Internet Connections)이라는 새로운 전송 계층 프로토콜을 사용합니다.
QUIC은 구글이 처음 설계했으며, 이후 IETF 표준화 과정을 거쳐 HTTP/3의 핵심 기반이 되었습니다.

가장 큰 차이는 TCP의 ‘순서 보장’에서 비롯된 지연을 없앴다는 점입니다.
TCP에서는 패킷 하나가 손실되면 나머지 패킷들도 재전송을 기다려야 해서, 전체 데이터 흐름이 잠시 멈춥니다.
이게 바로 전송 계층의 헤드 오브 라인 블로킹이죠.
QUIC은 UDP 위에서 구현되기 때문에 패킷 순서를 강제하지 않습니다.
각 스트림은 서로 독립적으로 동작하며, 한 스트림에서 손실이 생겨도 다른 스트림에는 영향을 주지 않습니다.
즉 HTTP/2의 멀티플렉싱 개념을 전송 계층 레벨로 완전히 끌어내린 셈입니다.

또 하나의 혁신은 TLS 1.3의 통합입니다.
기존 HTTP/1.1이나 HTTP/2는 TCP 연결 후 TLS 핸드셰이크를 추가로 수행해야 했지만, QUIC은 자체적으로 암호화를 포함하고 있습니다.
즉 핸드셰이크가 한 번에 처리되며, 연결 설정이 더 빠릅니다.
이 덕분에 초기 연결 지연(latency)이 현저히 줄어듭니다.
특히 모바일 환경이나 네트워크가 자주 변경되는 환경에서 유리하죠.
예를 들어 Wi-Fi에서 LTE로 전환될 때도 QUIC은 연결을 재사용하며 세션을 유지할 수 있습니다.

HTTP/3는 이러한 QUIC 위에서 HTTP 메시지를 전달하기 때문에, 구조적으로 다음과 같은 특징을 가집니다:

• ⚡TCP 대신 UDP를 사용하여 더 낮은 지연과 독립 스트림을 지원한다.
• 🔐TLS 1.3을 QUIC에 내장하여 보안 연결과 전송을 통합한다.
• 🚀핸드셰이크가 단축되어 연결 속도가 빠르다.
• 📡연결 복원 기능이 있어, 네트워크 전환 시에도 세션이 유지된다.

파이썬에서는 HTTP/3 지원이 비교적 새로운 영역이지만, 이미 관련 라이브러리가 활발히 개발 중입니다.
대표적으로 aioquic 라이브러리는 QUIC 및 HTTP/3 클라이언트·서버 구현을 모두 제공합니다.
또한 Hypercorn은 ASGI 서버 중 하나로, HTTP/3를 실험적으로 지원합니다.
이 덕분에 FastAPI나 Quart 같은 비동기 웹 프레임워크도 QUIC 기반 통신을 시험할 수 있습니다.

현재 주요 브라우저(Chrome, Firefox, Safari, Edge)는 이미 HTTP/3를 공식 지원 중이며, CDN 사업자(Cloudflare, Akamai, Fastly 등)도 대부분 QUIC를 활성화했습니다.
즉 클라이언트부터 서버, 인프라까지 전반적으로 HTTP/3 전환이 진행되고 있는 셈입니다.
이제 개발자 입장에서는 단순히 코드 한 줄로 요청을 보내는 것이 아니라, 어떤 프로토콜로 연결이 맺어지는지를 직접 고려해야 하는 시대가 되었다고 볼 수 있습니다.

📦 HPACK과 QPACK 헤더 압축 차이

HTTP/2와 HTTP/3의 큰 차이 중 하나는 바로 헤더 압축 방식입니다.
웹 요청에서 헤더는 생각보다 많은 데이터를 차지합니다.
쿠키, User-Agent, Authorization 같은 항목이 매 요청마다 반복되기 때문이죠.
그래서 HTTP/2에서는 이를 최적화하기 위해 HPACK이라는 압축 방식을 도입했습니다.

HPACK의 핵심 원리는 간단합니다.
헤더 이름과 값을 인덱스로 관리해서, 이미 한 번 보낸 헤더는 재전송하지 않고 참조만 하게 만드는 구조죠.
예를 들어 ‘Content-Type: text/html’이 이미 전송된 적 있다면, 그다음 요청에서는 단순히 “이전의 3번 인덱스 헤더를 다시 사용한다”는 식으로 줄여 보냅니다.
이를 통해 중복 헤더 전송을 크게 줄일 수 있습니다.
또한 HPACK은 허프만(Huffman) 코딩을 적용해 텍스트 데이터를 이진화하여 더 압축하기도 합니다.

하지만 HPACK은 HTTP/2의 구조적 특성과 강하게 묶여 있습니다.
즉 요청과 응답이 같은 TCP 연결 위에서 순차적으로 처리된다는 전제를 깔고 있기 때문에, 헤더 압축 상태를 클라이언트와 서버가 공유해야 합니다.
이게 문제인 이유는, QUIC 기반의 HTTP/3에서는 각 스트림이 완전히 독립적으로 동작하기 때문입니다.
스트림 간에 순서 보장이 없기 때문에 HPACK 방식은 그대로 쓸 수 없습니다.

그래서 HTTP/3에서는 HPACK을 개선한 QPACK이 도입되었습니다.
QPACK은 기본 원리는 HPACK과 비슷하지만, 스트림 간 의존성을 완전히 제거했습니다.
즉 각 스트림은 독립적으로 헤더를 압축하고 복원할 수 있어, 멀티플렉싱 환경에서도 블로킹 없이 작동합니다.
이 덕분에 QUIC 기반의 비동기 환경에서도 안전하게 헤더 압축이 가능합니다.

파이썬에서는 아직 QPACK을 직접 구현한 고수준 라이브러리는 많지 않지만, aioquic 내부에 QPACK 인코더/디코더가 포함되어 있습니다.
HTTP/3 클라이언트를 직접 구현하거나, 새로운 프록시 서버를 개발할 때 이를 활용할 수 있습니다.
반면 HTTP/2용 HPACK은 hyper-h2 패키지에 기본적으로 내장되어 있습니다.

💬 HPACK은 TCP 기반 멀티플렉싱을 위한 헤더 압축 기술, QPACK은 QUIC 기반 독립 스트림 환경을 위한 진화된 형태라고 볼 수 있습니다.

🛡️ TLS 의존성과 암호화 기본값

HTTP 프로토콜의 발전을 이해할 때 꼭 짚고 넘어가야 할 부분이 바로 TLS(Transport Layer Security)입니다.
HTTP/1.1 시절에는 보안 연결(HTTPS)이 옵션이었고, TLS는 단순히 “추가 계층”으로 동작했습니다.
즉, HTTP 위에 SSL/TLS를 얹어서 암호화를 수행하는 구조였죠.
하지만 HTTP/2부터는 사실상 TLS를 전제로 설계되었다고 해도 과언이 아닙니다.

HTTP/2는 명시적으로 TLS 1.2 이상을 요구하지는 않지만, 대부분의 브라우저와 서버 구현은 HTTPS를 통해서만 HTTP/2를 허용합니다.
그 이유는 단순히 데이터 암호화 때문만이 아니라, 프로토콜 협상 과정이 TLS에 포함되어 있기 때문입니다.
HTTP/2에서는 ALPN(Application-Layer Protocol Negotiation) 확장을 통해, TLS 핸드셰이크 중에 클라이언트와 서버가 “HTTP/2로 통신하자”는 합의를 합니다.
즉 HTTP/2의 존재 자체가 TLS 레이어에 의존한다고 볼 수 있습니다.

HTTP/3에서는 이 TLS 통합이 한 단계 더 진화합니다.
QUIC이 UDP 위에서 동작하기 때문에, 기존의 TLS 레이어를 그대로 쓸 수는 없습니다.
그래서 QUIC은 TLS 1.3을 내부적으로 통합했습니다.
즉 QUIC 자체가 암호화된 전송 프로토콜인 셈입니다.
이 구조 덕분에 별도의 Handshake 레이어 없이 1-RTT(혹은 0-RTT) 연결이 가능해졌고, 초기 연결 속도가 대폭 향상되었습니다.

파이썬 개발 환경에서도 TLS 설정은 점점 더 중요해지고 있습니다.
기존의 requests나 urllib3는 기본적으로 HTTPS 연결을 자동 처리하지만, HTTP/2 이상을 사용하려면 httpx나 aioquic처럼 최신 TLS/ALPN을 지원하는 라이브러리를 써야 합니다.
또한 Hypercorn 서버를 설정할 때는 TLS 인증서와 키를 명시해야 HTTP/2나 HTTP/3 모드로 동작할 수 있습니다.

💬 HTTP/2는 TLS 위에서 협상을 수행하고, HTTP/3는 TLS 1.3을 QUIC 내부에 통합함으로써 보안과 속도를 동시에 확보했습니다.

정리하자면, TLS는 이제 더 이상 선택사항이 아닙니다.
HTTP/1.1 시절에는 ‘보안 연결’의 개념이었다면, HTTP/2 이후부터는 ‘기본 연결 방식’이 되었습니다.
결국 보안은 성능과 분리된 문제가 아니라, 빠른 전송을 가능하게 하는 전제 조건이 된 셈이죠.
이 점이 바로 현대 HTTP 프로토콜의 패러다임 변화입니다.

❓ 파이썬에서 어떤 라이브러리를 써야 할까 (FAQ)