HTTP 3.0 (HTTP/3)

Table of Contents

HTTP/3란?

HTTP/3는 2022년 6월에 공식 발표된 최신 HTTP 프로토콜로, 기존 HTTP/2의 단점을 해결하고 웹 성능을 개선한 버전입니다. 가장 큰 변화는 기존 TCP 기반이 아닌 UDP 기반의 QUIC 프로토콜을 사용한다는 점입니다.

1. HTTP/3의 주요 특징

🔹 1) QUIC 프로토콜 기반 (TCP → UDP)

HTTP/1.1, HTTP/2는 TCP 기반이지만, HTTP/3는 UDP 기반 QUIC 프로토콜을 사용합니다.
QUIC은 TCP의 장점(신뢰성, 흐름 제어)을 가지면서도, 패킷 손실 시 지연을 줄이고 핸드셰이크 속도를 개선하여 더 빠른 연결을 제공합니다.

🔹 2) 0-RTT 핸드셰이크 (빠른 연결 수립)

기존 TCP에서는 연결을 설정할 때 3-way handshake가 필요했지만,
QUIC을 사용하는 HTTP/3는 0-RTT(Zero Round Trip Time) 핸드셰이크로 즉시 연결이 가능하여 속도가 빨라집니다.

🔹 3) 헤드 오브 라인 블로킹(Head-of-Line Blocking) 문제 해결

HTTP/2는 단일 TCP 스트림을 사용하여 하나의 패킷이 손실되면 전체 연결이 지연될 수 있었습니다.
HTTP/3에서는 각 요청이 개별적인 QUIC 스트림에서 처리되므로, 한 스트림에서 지연이 발생해도 다른 스트림에 영향을 주지 않습니다.

🔹 4) TLS 1.3 암호화 기본 적용

HTTP/3는 TLS 1.3을 기본적으로 사용하며, 암호화 과정이 TCP보다 빠릅니다.
기존 TCP에서는 TLS 핸드셰이크를 따로 진행해야 했지만, HTTP/3는 QUIC에 TLS가 내장되어 있어 보안성과 속도를 동시에 개선했습니다.

2. HTTP/3의 장점

✅ 더 빠른 웹 로딩 속도 – 초기 연결 시간이 짧고, 패킷 손실 시에도 빠르게 복구
✅ 끊김 없는 연결 – 네트워크가 변경되어도 (예: Wi-Fi → LTE 전환) 연결이 유지됨
✅ 더 강력한 보안 – TLS 1.3을 기본 적용하여 데이터 보호 강화
✅ 모바일 및 무선 네트워크에 최적화 – 패킷 손실이 많은 환경에서도 안정적

3. HTTP/3 지원 현황

웹 브라우저: Chrome, Edge, Firefox, Safari 등 주요 브라우저에서 지원
웹 서버: Nginx, Apache, Cloudflare, LiteSpeed 등에서 지원
CDN & 클라우드: Cloudflare, Google Cloud, AWS 등 주요 클라우드 플랫폼에서 HTTP/3 지원 확대

2024년 기준으로 전 세계 웹사이트의 약 30~40%가 HTTP/3를 지원하고 있으며, 점점 더 보급률이 높아지고 있습니다.

4. HTTP/3 사용 여부 확인하는 방법

1) 크롬 개발자 도구에서 확인

F12 (개발자 도구) → Network 탭
Protocol 열에서 h3가 표시되면 HTTP/3 사용 중

2) 온라인 툴 활용

HTTP/3 테스트 사이트에 URL 입력 후 HTTP/3 지원 여부 확인 가능

5. HTTP/2 vs. HTTP/3 비교

특징	HTTP/2 (2015)	HTTP/3 (2022)
전송 프로토콜	TCP	UDP (QUIC)
핸드셰이크	1-RTT	0-RTT (즉시 연결)
헤드 오브 라인 블로킹 문제	있음	없음 (각 스트림 독립 처리)
TLS 보안	TLS 1.2/1.3	TLS 1.3 기본 내장
모바일 환경	제한적 최적화	모바일 네트워크에서 강력한 성능 제공

6. 결론: HTTP/3, 도입할 가치가 있는가?

✅ 빠른 속도와 낮은 지연 시간이 필요한 서비스라면 HTTP/3 도입을 적극 고려해야 합니다.
✅ Cloudflare, Google, Facebook, YouTube 등 대형 서비스들은 이미 HTTP/3를 사용 중입니다.
✅ 다만, 모든 네트워크가 QUIC을 지원하지 않으므로 HTTP/2와 함께 제공하는 방식이 일반적입니다.

🚀 앞으로 HTTP/3는 점점 더 보편화될 것이며, 웹의 새로운 표준이 될 가능성이 높습니다!

7. HTTP 프로토콜 버전 비교 (HTTP/3 vs HTTP/2 vs HTTP/1.1 vs HTTP/1.0)

특징	HTTP/1.0 (1996)	HTTP/1.1 (1997)	HTTP/2 (2015)	HTTP/3 (2022)
전송 프로토콜	TCP	TCP	TCP	UDP (QUIC)
연결 방식	요청마다 새로운 연결	Persistent Connection (Keep-Alive)	하나의 TCP 연결에서 멀티플렉싱	QUIC을 사용한 멀티플렉싱
멀티플렉싱	❌ (요청마다 연결)	❌ (파이프라이닝 가능하지만 제한적)	✅ (단일 TCP 연결 내에서 여러 요청 처리)	✅ (각 스트림이 독립적)
헤드 오브 라인 블로킹 (HOL Blocking) 문제	존재	부분적 해결	TCP 기반으로 여전히 문제 있음	✅ 완벽 해결 (각 요청이 개별 스트림)
압축 지원	❌ 없음	❌ 없음	✅ HPACK 헤더 압축	✅ QPACK 헤더 압축
TLS 보안	❌ 없음	✅ 선택적 (TLS 1.2까지)	✅ 기본 지원 (TLS 1.2 이상)	✅ TLS 1.3 기본 내장
핸드셰이크 속도	느림 (3-way handshake 필요)	느림 (TLS 핸드셰이크 필요)	보통	빠름 (0-RTT 핸드셰이크 지원)
모바일 및 무선 환경 최적화	❌ 없음	❌ 없음	제한적	✅ QUIC 기반으로 강력한 성능 제공
도입된 연도	1996년	1997년	2015년	2022년
사용 현황 (2024년 기준)	거의 사용 안 함	일부 사용	✅ 많이 사용됨 (약 70%)	✅ 빠르게 증가 중 (약 30~40%)

🔹 HTTP/1.0 (1996)

각 요청마다 새로운 TCP 연결을 생성 → 성능 저하 & 속도 느림
Keep-Alive 기능이 없어 다중 요청 시 비효율적
기본적으로 캐시, 압축, 멀티플렉싱 기능 없음

🔹 HTTP/1.1 (1997)

Keep-Alive로 Persistent Connection 지원 → 한 번 연결하면 여러 요청 가능
파이프라이닝(Pipelining) 추가 → 클라이언트가 여러 개의 요청을 동시에 보낼 수 있지만, 응답은 순차적으로 도착 (HOL Blocking 문제)
여전히 한 요청이 완료되기 전까지 다음 응답을 받을 수 없어서 느림

🔹 HTTP/2 (2015)

멀티플렉싱(Multiplexing) 도입 → 하나의 TCP 연결에서 여러 요청을 동시에 처리 가능
HPACK 헤더 압축으로 데이터 크기 감소
서버 푸시(Server Push) 지원 → 서버가 클라이언트 요청 전에 필요한 리소스를 미리 전송 가능
하지만 HOL Blocking 문제는 완벽히 해결되지 않음 → TCP 기반이므로 패킷 손실 시 전체 요청이 지연됨

🔹 HTTP/3 (2022)

TCP 대신 UDP 기반 QUIC 프로토콜 사용 → 연결 속도 개선 및 지연 시간 감소
0-RTT 핸드셰이크로 더 빠른 연결
헤드 오브 라인 블로킹(HOL Blocking) 문제 완전 해결 → 각 요청이 개별 스트림에서 처리됨
TLS 1.3 기본 내장 → 보안 강화
모바일 및 무선 환경에서 성능 최적화

🔹 결론: 어떤 버전을 사용해야 할까?

HTTP/1.1 → 여전히 일부 시스템에서 사용되지만, 속도와 성능이 떨어짐
HTTP/2 → 대부분의 웹사이트에서 사용 중 (70% 이상)
HTTP/3 → 빠르게 증가하는 중 (현재 30~40% 채택)

🚀 가능하면 HTTP/3를 도입하는 것이 가장 유리하지만, HTTP/2와 함께 지원하는 것이 현실적인 최적의 선택! 그렇다면 HTTP/3는 기본적으로 HEAD에 입력만 하면 사용이 가능한걸까요?

아닙니다. 아래 HTTP/3를 사용하기 위해 기능을 활성화 하는 방법을 알아보겠습니다.

8. HTTP/3 활성화 방법

🔹 1) 서버에서 HTTP/3 지원 설정

HTTP/3는 기존 TCP 기반이 아니라 UDP 기반의 QUIC 프로토콜을 사용하므로, 서버에서 QUIC을 활성화해야 합니다.

서버가 QUIC(UDP/443) 통신을 지원해야 함
서버와 클라이언트가 TLS 1.3을 사용해야 함

🔹 2) 클라이언트(브라우저)에서 HTTP/3 지원 확인

Chrome, Edge, Firefox, Safari 같은 최신 브라우저는 HTTP/3를 지원합니다.

크롬 개발자 도구 → Network 탭 → Protocol에서 h3가 표시되면 HTTP/3 사용 중

🔹 3) 서버 응답 헤더에 HTTP/3 광고 (Alt-Svc 사용)

서버가 HTTP/3를 지원하는 경우, 기존 HTTP/1.1 또는 HTTP/2 연결을 맺은 후 HTTP/3 사용을 알리는 Alt-Svc 헤더를 전송합니다.

Alt-Svc: h3=":443"; ma=86400

h3=":443" → HTTP/3를 443 포트에서 사용할 수 있다는 의미
ma=86400 → 24시간 동안 HTTP/3를 우선 사용하도록 클라이언트에게 알림

🔹 4) Nginx, Apache, Cloudflare 등에서 HTTP/3 설정

서버 환경에 따라 별도 설정이 필요합니다.

✅ Nginx에서 HTTP/3 활성화 (예제)

server {
    listen 443 ssl http2; # HTTP/2 지원
    listen 443 quic reuseport; # HTTP/3 (QUIC) 지원
    http3 on;
    ssl_certificate /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/privkey.pem;
    add_header Alt-Svc 'h3=":443"; ma=86400';
}

📌 listen 443 quic reuseport; → UDP 기반 QUIC을 활성화

9. HTTP/3 요청 헤더 예제 및 테스트 방법

클라이언트가 HTTP/3 요청을 보낼 때는 다음과 같은 헤더를 포함할 수 있습니다.

:authority: example.com
:method: GET
:path: /
:scheme: https
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
accept: text/html
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9

하지만, HTTP/3는 별도의 Upgrade 헤더 없이도 기본적으로 사용되며, 서버와 클라이언트가 지원하면 자동으로 연결이 맺어집니다.

✅ 크롬 개발자 도구에서 확인

F12 (개발자 도구) → Network 탭
Protocol 열을 추가 (Right Click → Select "Protocol" Column)
h3가 표시되면 HTTP/3 사용 중

✅ 온라인 HTTP/3 테스트 사이트

https://http3check.net/
https://www.cloudflare.com/ssl/encrypted-sni/

결론: HTTP/3 사용하려면?

🔸 헤더만 추가하는 것으로는 HTTP/3를 사용할 수 없음!
🔸 서버에서 QUIC(UDP/443) 활성화 + TLS 1.3 적용 + Alt-Svc 헤더 추가 필요
🔸 클라이언트(브라우저)도 HTTP/3를 지원해야 함
🔸 HTTP/3 지원이 없는 경우, 자동으로 HTTP/2 또는 HTTP/1.1로 연결됨

🚀 참고로 대부분 모든 서버는 1.1은 기본 지원이고, 2.0은 아팟지 서버의 경우 아래의 명령어를 통해 HTTP/2모듈을 활성화 해야 한다.

a2enmod http2

가능하면 HTTP/3지원 시 HTTP/2와 함께 지원하는 것이 가장 현실적인 접근법.

zerg96