HTTP/1.1 vs HTTP/2 vs HTTP/3 완전 정복 — `keep-alive`, `multiplexing`, `QUIC`까지
HTTP 버전, 왜 따로 알아야 하나요?
네트워크 계층 글까지 읽고 나면 이런 질문이 자연스럽게 남습니다.
- 어차피 API는
GET /users처럼 똑같은데, 왜HTTP/1.1,HTTP/2,HTTP/3를 구분해서 봐야 할까요? HTTP/2는 멀티플렉싱이라서 무조건 빠르다고 해도 될까요?HTTP/3는UDP위에서 동작한다는데, 그러면 신뢰성이 약해지는 걸까요?- 로드밸런서나 CDN이
HTTP/3를 지원한다는 말은 정확히 어디까지를 뜻할까요? - 브라우저에서 체감이 없는데도 서버는 굳이
HTTP/3를 켜야 할까요?
핵심은 이것입니다.
HTTP 버전 차이는 "API 의미"보다 "연결을 맺고, 데이터를 잘게 나누고, 손실을 복구하는 방식"의 차이에서 성능과 안정성을 바꿉니다
즉:
HTTP의semantics는 대체로 유지되지만- 그 메시지를 어떻게 전송하느냐 가 달라지고
- 그 차이가 지연 시간, 병렬 처리, 패킷 손실 대응, 모바일 네트워크 체감에 영향을 줍니다
이 글에서는 HTTP/1.1, HTTP/2, HTTP/3를 암기식 표가 아니라, 브라우저가 서버와 연결을 재사용하고 여러 요청을 동시에 보내는 방식이 어떻게 바뀌었는지 를 기준으로 정리하겠습니다.
기준: 이 글은 일반적인 브라우저-웹 서버-프록시/CDN 환경을 기준으로 설명합니다.
gRPC, CDNedge, 모바일 네트워크, TLS 종료 지점처럼 실무에서 자주 부딪히는 포인트도 함께 다룹니다.
먼저 선택 기준부터 보면
실무에서는 보통 아래 기준으로 보면 크게 틀리지 않습니다.
| 상황 | 먼저 눈여겨볼 버전 | 이유 |
|---|---|---|
| 레거시 프록시, 단순 API, 내부망 중심 | HTTP/1.1 |
호환성이 가장 넓고 운영 이해도가 높습니다 |
| 일반적인 브라우저 웹 서비스 | HTTP/2 |
다중 요청 병렬 처리와 헤더 압축 이점이 큽니다 |
모바일 네트워크, 패킷 손실, CDN edge 최적화 |
HTTP/3 |
TCP 레벨 HOL blocking 영향을 줄이고 재연결 체감이 더 좋을 수 있습니다 |
| 외부 공개 서비스에서 "기본 최적화" | HTTP/2 + 가능하면 HTTP/3 |
대부분 환경에서 무난하고, 하위 호환도 자연스럽습니다 |
비멱등 POST 재시도 정책이 민감함 |
HTTP/3의 0-RTT는 신중히 |
성능 이점과 replay 위험을 함께 봐야 합니다 |
가장 짧게 줄이면 이렇습니다.
HTTP/1.1은 단순하고 익숙하지만 병렬 전송에 약합니다HTTP/2는 대부분의 웹 서비스에서 가장 먼저 체감되는 개선을 줍니다HTTP/3는 특히 손실과 네트워크 전환이 잦은 환경에서 더 빛납니다
Phase 1. 먼저 분리해서 봐야 할 것 - HTTP의 의미와 전송 방식
가장 먼저 정리해야 할 오해가 있습니다.
HTTP 버전이 바뀐다고 해서
GET,POST, 상태 코드, 헤더라는 개념이 통째로 새로 생기는 것은 아닙니다
예를 들어 아래 요청의 의미 자체는 크게 달라지지 않습니다.
GET /posts/25 HTTP/1.1
Host: example.com
Accept: text/html
HTTP/2, HTTP/3에서도 여전히:
GET,POST,PUT,DELETE가 있고200,404,500같은 상태 코드가 있고Host,Content-Type,Cache-Control같은 헤더가 있고- 캐시, 쿠키, 인증 같은 상위 개념도 계속 유지됩니다
달라지는 핵심은 주로 아래입니다.
| 관점 | HTTP/1.1 |
HTTP/2 |
HTTP/3 |
|---|---|---|---|
| 메시지 표현 | 텍스트 기반 | 바이너리 프레이밍 | 바이너리 프레이밍 |
| 전송 계층 | TCP |
TCP |
QUIC over UDP |
| 다중 요청 처리 | 연결 여러 개에 의존 | 한 연결에서 다중 스트림 | 한 연결에서 다중 스트림 |
| 손실 전파 | 연결 단위로 큼 | TCP 레벨 영향 남음 | 스트림 단위로 더 잘 분리 |
| 연결 설정 | TCP + TLS | TCP + TLS | QUIC + TLS 1.3 통합 |
즉, "HTTP의 의미"보다 "연결을 얼마나 효율적으로 쓰는가" 가 버전 차이의 핵심입니다.
Phase 2. HTTP/1.1은 왜 느리다고 느껴질까?
HTTP/1.1 자체가 무조건 느린 것은 아닙니다. 다만 현대 웹 페이지처럼 작은 리소스를 많이 한꺼번에 가져오는 상황에서 구조적 한계가 잘 드러납니다.
1. 초창기에는 요청마다 연결 비용이 반복됐다
브라우저가 HTML, CSS, JS, 이미지, 폰트를 가져와야 한다고 가정해 보겠습니다.
연결 재사용이 없다면 요청마다 이런 비용이 반복됩니다.
DNS 조회
↓
TCP `handshake`
↓
TLS `handshake`
↓
HTTP 요청/응답
HTTPS에서는 특히 이 연결 설정 비용이 큽니다. MDN의 TTFB 설명도 브라우저가 첫 바이트를 받기 전 시간에 DNS lookup, TCP handshake, TLS handshake가 포함된다고 설명합니다.
2. 그래서 keep-alive가 중요해졌다
HTTP/1.1에서 가장 먼저 체감되는 개선은 persistent connection, 흔히 말하는 keep-alive입니다.
한 번 맺은 TCP 연결을 재사용하면:
- 같은
origin에 대한 후속 요청에서handshake비용을 줄일 수 있고 - 리소스 여러 개를 한 연결에서 순차적으로 요청할 수 있으며
- 특히 이미지, CSS, JS처럼 자잘한 요청이 많은 페이지에서 효과가 큽니다
하지만 여기에도 한계가 있습니다.
3. 한 연결 안에서는 결국 순서 대기가 생긴다
HTTP/1.1은 기본적으로 한 연결에서 요청/응답이 직렬적으로 흘러가기 쉽습니다.
예를 들어 첫 응답이 늦어지면 뒤 요청도 줄줄이 대기하게 됩니다.
Connection A
Request 1 -> 느린 응답
Request 2 -> 대기
Request 3 -> 대기
이 문제를 줄이려고 브라우저는 보통 같은 origin에 TCP 연결을 여러 개 열었습니다.
즉:
- 연결 1개는 직렬 처리 한계가 있고
- 이를 보완하려고 연결 수를 늘렸고
- 그 결과 서버 입장에서는 소켓 수, TLS 세션 수, 커널 자원 부담이 커졌습니다
4. pipelining은 왜 널리 안 쓰였을까?
이론적으로는 응답을 기다리지 않고 요청을 연달아 보내는 pipelining이 있었지만, 중간 프록시 호환성 문제와 응답 순서 제약 때문에 실무에서 널리 쓰이지 않았습니다.
결국 HTTP/1.1의 핵심 한계는 이것입니다.
연결 재사용은 되지만, "한 연결에서 여러 요청을 자연스럽게 동시에 흘리는 능력"은 약합니다
Phase 3. HTTP/2는 무엇을 바꿨을까?
HTTP/2가 가져온 가장 큰 변화는 한 TCP 연결 안에서 여러 요청/응답을 스트림 단위로 잘게 나눠 동시에 흘릴 수 있게 만든 것입니다.
1. 텍스트 대신 바이너리 프레임으로 나눴다
HTTP/1.1에서는 요청 메시지가 텍스트 줄 단위로 보였다면, HTTP/2에서는 내부적으로 프레임이라는 단위로 잘게 쪼개집니다.
이렇게 되면 브라우저는 하나의 연결 안에서:
- 요청 A 일부
- 요청 B 일부
- 요청 C 일부
를 번갈아 보낼 수 있습니다.
즉, 더 이상 "응답 하나 끝나야 다음 요청" 구조에 묶일 필요가 줄어듭니다.
2. multiplexing이 핵심 이점이다
예를 들어 브라우저가 CSS, JS, 이미지 여러 개를 동시에 가져올 때:
HTTP/1.1:
연결 여러 개를 열어서 병렬성 확보
HTTP/2:
연결 하나에서 여러 스트림을 동시에 흘림
이 변화로 얻는 이점은 분명합니다.
- 연결 수를 덜 늘려도 됩니다
- 같은
origin내 다중 리소스 로딩이 더 효율적입니다 - TLS 세션/소켓 관리 부담이 상대적으로 줄어듭니다
- 헤더를 압축(
HPACK)해 중복 헤더 비용도 줄일 수 있습니다
특히 쿠키나 공통 헤더가 큰 서비스에서 헤더 압축은 생각보다 유의미할 수 있습니다.
3. 그런데 왜 HTTP/2도 완전한 해답은 아닐까?
여기서 자주 생기는 오해가 있습니다.
HTTP/2는 애플리케이션 레벨HOL blocking을 줄였지만, TCP 위에 있는 한 전송 계층 수준의 병목은 여전히 남아 있습니다
하나의 TCP 연결 위에서 여러 스트림을 흘리더라도, 어떤 TCP 세그먼트가 유실되면 재전송과 순서 보장은 TCP가 처리합니다.
그러면 그 손실의 영향이 연결 전체에 퍼질 수 있습니다.
즉:
HTTP/2는 요청 간 인터리빙은 잘하지만- 패킷 손실이 있는 네트워크에서는 TCP 특성상 전체 스트림 체감이 흔들릴 수 있습니다
MDN도 HTTP/2가 HTTP/1.x의 HOL blocking을 해결했지만, TCP 레벨의 병목은 남아 있고, HTTP/3가 이를 QUIC으로 보완한다고 설명합니다.
4. Server Push는 왜 주인공이 아니게 됐을까?
HTTP/2를 이야기할 때 server push가 함께 나오곤 합니다. 다만 실전에서는:
- 브라우저 캐시 상태를 서버가 정확히 예측하기 어렵고
- 잘못 push하면 오히려 대역폭만 낭비하며
- 운영 복잡도 대비 이득이 제한적인 경우가 많았습니다
그래서 지금 HTTP/2의 핵심 가치는 보통:
multiplexingheader compression- 연결 수 감소
이 세 가지에 더 가깝습니다.
Phase 4. HTTP/3는 왜 UDP 위로 올라갔을까?
여기서부터가 가장 많이 헷갈리는 지점입니다.
HTTP/3는 단순히 "HTTP/2를 더 빠르게 튜닝한 버전"이 아닙니다. 전송 기반 자체를 TCP에서 QUIC으로 바꿨습니다.
1. HTTP/3는 QUIC 위에서 동작한다
구조를 단순하게 그리면 이렇습니다.
HTTP/1.1 -> HTTP over TCP
HTTP/2 -> HTTP over TCP
HTTP/3 -> HTTP over QUIC over UDP
여기서 오해하면 안 되는 점은:
UDP를 쓴다고 해서 무조건 비신뢰 전송으로 내려가는 것은 아니고QUIC이 그 위에서 순서, 손실 감지, 재전송, 흐름 제어, 스트림 개념을 직접 제공합니다
즉, HTTP/3는 "TCP를 버리고 무책임해진 HTTP"가 아니라, TCP가 맡던 기능 일부를 더 현대적인 형태로 사용자 공간 프로토콜로 옮긴 구조에 가깝습니다.
2. 왜 성능상 이점이 생길까?
핵심은 두 가지입니다.
첫째, 스트림 간 손실 전파를 더 잘 분리한다
HTTP/2는 논리적으로는 다중 스트림이지만, 실제 전송은 하나의 TCP 연결에 묶여 있습니다.
반면 HTTP/3의 QUIC은 스트림 단위 전송을 더 직접적으로 다룹니다. 어떤 패킷 손실이 발생해도 그 영향이 다른 스트림 전체를 동일하게 막지 않도록 설계되어 있습니다.
그래서:
- 패킷 손실이 있는 네트워크
- 지하철, 와이파이 전환, 셀룰러 이동
- 모바일 환경처럼 RTT와 손실률이 불안정한 상황
에서 차이가 더 잘 드러날 수 있습니다.
둘째, 연결 설정 지연을 줄일 수 있다
QUIC은 TLS 1.3을 통합적으로 사용합니다. 그래서 신규 연결이나 재연결에서 지연을 줄이기 유리합니다.
특히 세션 재개가 가능한 상황에서는 QUIC과 TLS 1.3 조합에서 0-RTT가 가능할 수 있습니다. 다만 이건 성능만 보고 켜면 안 됩니다.
왜냐하면:
- 재전송과
replay관점에서 주의가 필요하고 - 비멱등 요청은 같은 요청 재수행 위험을 더 엄격하게 봐야 하며
- 이 부분은 멱등성 글과 직접 연결됩니다
즉, HTTP/3는 QUIC 기반 연결 재개 이점이 장점이지만, 모든 POST가 자동으로 안전해지는 것은 아닙니다.
3. HTTP/3는 어떻게 발견될까?
브라우저는 보통 서버가 Alt-Svc로 "이 origin은 h3도 가능하다"는 신호를 광고하면, 이후 해당 origin에 대해 HTTP/3 연결을 시도합니다.
즉, 실무에서 HTTP/3 켰다는 말은 보통:
- 브라우저가 항상 첫 요청부터 바로
HTTP/3로 시작한다는 뜻이라기보다 - 먼저 다른 버전의 응답에서
Alt-Svc를 보거나 이미 학습한 대체 서비스 정보를 바탕으로 - 이후 동일
origin에 대해h3를 시도할 수 있게 만든다는 의미에 가깝습니다
여기서 ALPN도 같이 중요합니다. HTTP/2의 h2, HTTP/3의 h3 같은 식별자가 협상에 쓰이기 때문입니다.
Phase 5. 그래서 체감 성능은 언제 달라질까?
많은 경우 팀이 원하는 답은 이것입니다.
"그래서 우리 서비스에서 진짜 빨라지나요?"
정답은 "환경에 따라 다르다"이지만, 실무에서는 아래처럼 보면 됩니다.
HTTP/2 체감이 큰 경우
- 한 페이지에서 CSS, JS, 이미지, 폰트, API 요청이 많이 발생함
- 같은
origin으로 작은 요청이 많이 몰림 - 기존에 연결 수가 많아 소켓 관리와
handshake비용이 부담이었음 - 브라우저 중심 서비스라서 다중 리소스 로딩이 중요함
HTTP/3 체감이 큰 경우
- 모바일 사용자가 많음
- 네트워크 전환이 잦음
- 패킷 손실이나
jitter가 있는 환경에서 서비스 품질이 흔들림 - CDN
edge를 적극 사용하고 글로벌 사용자 비중이 큼
체감이 크지 않을 수 있는 경우
- 대부분 요청이 길고 무거운 서버 처리 시간에 묻힘
- 정적 파일보다 API 한두 개가 지연 시간을 지배함
- 내부망 트래픽이라 손실률이 낮고 RTT도 짧음
- 애초에 병목이 DB나 애플리케이션 로직에 있음
즉, 프로토콜 업그레이드는 중요하지만, DB 쿼리가 800ms인데 HTTP 버전만 바꿔서 20ms 줄이는 일이 항상 우선순위는 아닙니다.
Phase 6. 실무에서는 어디까지 지원하면 될까?
운영 관점에서는 보통 "브라우저 -> CDN/LB -> origin" 경로를 나눠서 봐야 합니다.
1. edge까지만 HTTP/3여도 체감은 좋아질 수 있다
예를 들어:
브라우저 -> CDN: HTTP/3
CDN -> origin: HTTP/1.1 또는 HTTP/2
여기서도 사용자 체감은 좋아질 수 있습니다. 특히 마지막 마일, 모바일 무선 구간, 국제망 구간에서는 edge까지의 프로토콜 차이가 더 크게 보일 수 있기 때문입니다.
즉, origin 서버가 직접 HTTP/3를 처리하지 않아도:
- CDN이
edge에서HTTP/3를 받고 - 내부적으로는
origin과 다른 프로토콜로 통신하는 구조가 - 충분히 실용적일 수 있습니다
2. 로드밸런서와 프록시의 실제 지원 범위를 봐야 한다
"우리 서비스는 HTTP/3 지원합니다"라고 말하기 전에 확인할 것은 보통 이 정도입니다.
- 브라우저와 맞닿는 CDN/LB가
h3를 광고하는가? - TLS 종료 지점이 어디인가?
Alt-Svc,ALPN협상이 실제로 보이는가?- 프록시 체인 중간에서 다운그레이드되는가?
- 로그와 모니터링에서 실제 프로토콜 버전을 확인할 수 있는가?
겉으로 HTTP/3 enabled라고 체크돼 있어도, 실제 트래픽 대부분이 HTTP/2로 끝나는 경우는 꽤 흔합니다.
3. gRPC나 양방향 통신은 별도로 봐야 한다
gRPC는 기본적으로 HTTP/2에 강하게 기대는 경우가 많습니다. 따라서 서비스 전반이 HTTP/3로 간다고 해도:
- 브라우저 정적 자산 배포
- 일반 REST/HTML 요청
- 내부 서비스 간
gRPC
는 동일한 전략으로 보지 않는 편이 낫습니다.
즉, 프로토콜 전략도 트래픽 성격별로 분리해서 보는 것이 맞습니다.
Phase 7. 장애 분석은 어떻게 달라질까?
네트워크 계층 글과 연결해서 보면, HTTP 버전 차이는 장애 분석 순서에도 영향을 줍니다.
HTTP/1.1 / HTTP/2에서 자주 보는 질문
- 연결 재사용이 제대로 되고 있는가?
- keep-alive timeout이 너무 짧지 않은가?
- 프록시가 연결을 자주 끊지 않는가?
HTTP/2인데도 연결 수가 비정상적으로 많지 않은가?- 패킷 손실 구간에서 TCP 재전송 때문에 전체 응답이 흔들리지 않는가?
HTTP/3에서 추가로 보는 질문
- 브라우저가 실제로
h3를 사용했는가? Alt-Svc캐시와 만료가 어떻게 동작하는가?- UDP 차단 또는 중간 장비 정책 때문에
fallback이 발생하는가? - 일부 지역/망에서만
HTTP/3handshake실패가 나는가?
즉, "HTTP/3 켰는데 별 차이 없다"는 말은 아래 셋 중 하나일 때가 많습니다.
- 실제로는
HTTP/2로fallback중이다 - 병목이 애플리케이션/DB 쪽이다
- 사용자 네트워크 특성상 프로토콜 차이가 크게 드러나지 않는다
핵심만 다시 정리하면
마지막으로 세 버전을 한 번 더 비교하면 이렇게 정리할 수 있습니다.
| 구분 | HTTP/1.1 |
HTTP/2 |
HTTP/3 |
|---|---|---|---|
| 강점 | 단순함, 넓은 호환성 | multiplexing, header compression |
손실 환경 대응, 더 나은 연결 설정 |
| 약점 | 병렬 처리 비효율, 연결 수 증가 | TCP 레벨 HOL 영향 잔존 | 운영 가시성, 장비/정책 지원 확인 필요 |
| 잘 맞는 곳 | 단순 서비스, 레거시 호환 | 대부분의 현대 웹 서비스 | 모바일/글로벌/손실 민감 환경 |
핵심 포인트는 다섯 가지입니다.
HTTP/1.1,HTTP/2,HTTP/3의 가장 큰 차이는 API 의미보다 전송 방식과 연결 관리 방식에 있습니다.HTTP/2의 핵심 가치는 **multiplexing과header compression**이며, 일반적인 웹 서비스에서 가장 먼저 체감되는 개선을 줍니다.HTTP/3는QUIC을 통해 TCP 레벨 HOL blocking 영향을 줄이고, 손실이 있는 환경에서 더 안정적인 체감을 줄 수 있습니다.QUIC과TLS 1.3기반의0-RTT는 성능 장점이 있지만, 비멱등 요청에서는replay위험을 함께 고려해야 합니다.- 실무에서는
origin만 볼 것이 아니라, 브라우저-프록시/CDN-edge-origin전체 경로에서 실제 어느 버전이 쓰이는지 확인해야 합니다.
결국 HTTP 버전 선택은 "최신 버전이 무조건 정답인가?"의 문제가 아니라, 우리 트래픽의 병목이 handshake인지, 병렬 요청인지, 패킷 손실인지, 운영 호환성인지 를 구분하는 문제에 가깝습니다.