🔵 HTTP/1.1 vs HTTP/2 vs HTTP3 차이

🔵 HTTP

 

HTTP는 웹에서 클라이언트와 서버가 데이터를 주고받기 위해 사용하는

요청-응답 기반의 애플리케이션 계층 프로토콜입니다.

무상태성(stateless)을 가지므로

각 요청이 서로 완전히 독립적으로 처리되고

서버가 클라이언트의 이전 상태를 유지하지 않습니다.

상태를 저장하지 않기 때문에 확장성이 뛰어나고 서버 부담이 적어지는 장점이 있습니다.

GET·POST·PUT·DELETE 같은 메서드를 통해 리소스를 표현하고 조작하며

헤더와 바디 구조로 다양한 형태의 데이터를 교환합니다.

기본적으로 TCP 위에서 동작하며

HTTP/2와 HTTP/3에서는 멀티플렉싱·헤더 압축·QUIC 같은 기술이 적용되어

더 빠르고 효율적인 통신을 제공합니다.

 

 

 

---

 

 

 

---

🔵 1. HTTP/1.1

1_ 기본 개념

HTTP/1.1은 1997년에 표준으로 채택된 이후

오랫동안 웹 전송의 주력 프로토콜로 사용되어 현재까지도 사용되고 있습니다.

2_ 특징 

(1) 요청-응답 모델

HTTP는 클라이언트가 요청을 보내면

서버가 그에 대한 응답을 반환하는 단방향, Request-Response 기반 통신 모델입니다.

클라이언트는 메서드·URI·헤더·바디로 구성된 요청 메시지를 보내고

서버는 상태코드·헤더·바디를 포함한 응답 메시지로 결과를 전달합니다.

 

 

(2) Keep-Alive

HTTP Keep-Alive는 요청마다 TCP 연결을 새로 만들지 않고

하나의 연결을 여러 요청에 재사용하도록 하는 기능입니다.

기본적으로 HTTP는 요청–응답 후 연결을 끊는 비연결적 특성을 갖지만

Keep-Alive를 사용하면 TCP 핸드셰이크 비용을 줄여

지연 시간(latency)을 감소시키고 성능을 크게 향상시킬 수 있습니다.

 

특히 여러 리소스(HTML, CSS, JS, 이미지 등)를 연속해서 요청하는 웹 환경에서는

매번 연결을 새로 만드는 오버헤드가 매우 크기 때문에

Keep-Alive는 네트워크 효율을 높이는 핵심 기술로 사용됩니다.

HTTP/2부터는 하나의 연결에서 멀티플렉싱이 가능해 Keep-Alive의 이점이 더 강화된 형태로 발전했습니다.

 

 

(3) 파이프라이닝 지원

HTTP 파이프라이닝은 하나의 TCP 연결에서 여러 요청을 순차 응답을 기다리지 않고 연속해서 보내는 방식입니다.
즉, 첫 번째 요청의 응답을 기다리지 않고 두 번째, 세 번째 요청을 미리 보내 성능을 높이려는 기술입니다.

 

하지만 서버는 요청을 받은 순서대로 응답을 보내야 하기 때문에

특정 요청이 지연되면 뒤의 응답까지 모두 막히는 HOL(Head-of-Line) Blocking 문제가 발생합니다.

브라우저 호환성 문제도 컸기 때문에 실제 웹 환경에서는 거의 사용되지 않았고, 대부분 비활성화되어 있습니다.

현재는 파이프라이닝의 단점을 해결한 HTTP/2의 멀티플렉싱 기술이 사실상 표준처럼 사용되고 있어

현대 웹에서는 파이프라이닝이 실질적으로 쓰이지 않습니다.

 

 

3_ 한계

(1) 연결 개수 제한

브라우저는 동일 도메인에 대해 동시에 열 수 있는 연결 수를 제한합니다.
따라서 리소스가 많은 페이지에서는 병목 현상이 발생할 수 있습니다.

 

(2) 헤드-오브-라인 블로킹(Head-of-Line Blocking, HOL)

하나의 요청이 지연되면, 그 뒤의 요청들까지 모두 함께 지연되는 현상입니다.

 

(3) 헤더 중복 전송

HTTP/1.1은 요청과 응답마다 같은 헤더 정보를 반복해서 전송하기 때문에
불필요한 오버헤드가 발생합니다.

 

(4) HTTP/1.0 은 서버와 클라이언트간에 Connection 을 지속하지 않음 

HTTP/1.0은 요청마다 연결을 새로 생성하고 바로 끊었습니다.
따라서 DNS 조회, TCP 3-way handshake, SSL/TLS handshake 같은
연결 단계가 요청마다 반복되어 지연이 크게 증가했습니다.

 

 

---

🔵 2. HTTP/2

1_ 기본 개념

HTTP/2는 HTTP/1.1의 성능 한계를 해결하기 위해 등장한 프로토콜입니다.

애플리케이션 레벨에서는 기존 방식과 동일하게 동작하지만,

내부 전송 구조는 텍스트 기반에서 이진 프레임(binary frame) 방식으로 재설계되었습니다.

 

이러한 구조 덕분에 요청과 응답을 더 유연하게 처리할 수 있고, 전송 효율도 크게 향상되었습니다.

 

2_ 주요 개선 내용

 

(1) 멀티플렉싱(Multiplexing)

- 하나의 TCP 연결 안에서 여러 요청과 응답을 동시에 처리할 수 있습니다.

- 이로 인해 특정 요청이 지연되어도 다른 요청이 함께 지연되는 현상이 줄어듭니다.

- HTTP/1.1의 대표적인 문제였던 헤드 오브 라인 블로킹(HOL) 을 크게 완화한 기능입니다.

 

 

 

 

(2) 헤더 압축

- 대부분의 요청에는 쿠키나 User-Agent처럼 반복되는 헤더값이 많습니다.

- HTTP/2는 이를 효율적으로 압축하는 방식(HPACK)을 사용하여

  불필요한 데이터 전송을 줄이고 속도를 높입니다.

 

 

 

 

 

 

(3) 서버 푸시(Server Push)

- 브라우저가 HTML을 요청했을 때 서버가 필요한 리소스(CSS, JS 등)를 미리 보내주는 기능입니다.

- 초기 로딩 시간을 줄일 수 있다는 장점이 있습니다.

 

 

3_ 한계

(1) TCP 기반의 구조적 한계

- HTTP/2는 여러 스트림을 동시에 처리할 수 있지만, 결국 하나의 TCP 연결 위에서 동작합니다.
- TCP는 패킷이 하나라도 손실되면 해당 패킷이 복구될 때까지 연결 전체가 지연되는 문제가 있어

  멀티플렉싱의 효과가 제한되는 경우가 생깁니다.

 

(2) 서버 푸시의 비효율성

서버 푸시는 필요하지 않은 리소스를 과도하게 보내거나 캐시와 충돌하는 경우가 많아,
실제 환경에서는 오히려 성능 저하로 이어져 대부분 비권장 기능이 되었습니다.

 

(3) 네트워크 장비 및 환경에 따른 호환성 문제

일부 프록시나 방화벽 등 네트워크 장비가 HTTP/2의 이진 프레임 방식을 완전히 지원하지 않아,
HTTP/1.1로 다운그레이드되거나 성능이 저하되는 경우가 있습니다.

 

 

---

🔵 2. HTTP/3

1_ 기본 개념

HTTP/3는 HTTP/2의 성능 문제 중 핵심이었던

TCP 기반의 구조적 한계를 해결하기 위해 등장한 프로토콜입니다.

HTTP/2는 멀티플렉싱을 지원하지만

TCP 특성상 패킷이 하나라도 손실되면 전체 스트림이 함께 지연되는 문제가 남아 있습니다.

 

이를 해결하기 위해 HTTP/3는 TCP 대신 UDP 기반의 QUIC 프로토콜 위에서 동작하도록 설계되었습니다.
QUIC은 연결 지연을 줄이고 패킷 손실에 유연한 구조를 제공하여, 더 안정적이고 빠른 통신이 가능합니다.

 

2_ 주요 기능

(1) QUIC 기반 전송

- QUIC은 UDP 위에 구현된 전송 계층 프로토콜입니다.

- 기존의 TCP에서는 연결을 맺기 위해 여러 단계의 핸드셰이크 과정이 필요했고,

   패킷이 손실되면 해당 패킷을 재전송할 때까지 전체 스트림이 함께 지연되는 문제가 있었습니다.

- QUIC은 이러한 부분을 개선하여 연결 지연과 전송 지연을 크게 줄여줍니다.

 

(2) 스트림 독립성 강화

- HTTP/3는 요청과 응답을 스트림(stream) 단위로 나누어 처리하며

  각 스트림이 서로 완전히 독립적으로 동작합니다.
- 따라서 특정 스트림에서 패킷이 일부 손실되더라도 해당 스트림만 잠시 지연되고,
  다른 스트림은 영향을 받지 않고 그대로 진행됩니다.

 

(3) 더 빠른 연결 복원력

- HTTP/3는 네트워크가 전환되더라도(예: LTE → Wi-Fi) 연결을 끊지 않고 유지하거나,
  끊어진 경우에도 매우 빠르게 복원할 수 있습니다.
- 이 덕분에 모바일 환경처럼 네트워크 변화가 잦은 상황에서도 안정적인 성능을 제공합니다.