HTTP/1.1 vs HTTP/2 vs HTTP/3 차이 완벽 정리 (2026) - 실무에서 뭘 써야 할까

 

HTTP/1.1 vs HTTP/2 vs HTTP/3 차이를 구조·속도·보안 관점에서 비교하고, Apache가 HTTP/3를 지원하지 않는 이유와 CDN으로 HTTP/3를 적용하는 실무 방법까지 2026년 기준으로 정리합니다. 프로토콜 버전보다 HTTPS 적용과 CDN 활용이 더 중요한 이유를 다룹니다.

 

 

"HTTP/1.1은 아직도 현역인가요?"
"HTTP/2로 바꾸면 진짜 빨라지긴 하나요?"
"HTTP/3는 도대체 뭐가 다른 거죠? 굳이 신경 써야 하나요?"
"Apache는 왜 HTTP/3가 안 된다는 거예요?"

 

 

서버를 직접 구성해 보거나 네트워크를 좀 깊게 파다 보면 반드시 한 번은 마주치는 질문들입니다. 저도 처음엔 "최신 버전 쓰면 무조건 좋은 거 아냐?" 싶었는데, 막상 실무에서 부딪혀 보니 그렇게 단순하지가 않더군요. 결론부터 말씀드리면, 프로토콜 버전 자체보다 HTTPS를 적용했는가, CDN을 앞에 뒀는가가 훨씬 더 중요한 선택입니다.

이 글에서는 세 버전의 탄생 배경과 구조적 차이를 짚고, 각 버전이 어떤 장점을 갖는지, 그리고 Apache가 HTTP/3를 지원하지 않는데도 실무에서 전혀 불편하지 않은 이유까지 풀어 보겠습니다. 서버 구성을 고민 중인 개발자, 내 사이트에 어떤 프로토콜을 써야 할지 헷갈리는 분이라면 끝까지 읽으시면 정리가 될 겁니다.

📋 목차

1. HTTP/1.1이 거의 30년을 버틴 이유
2. HTTP/1.1의 구조적 한계 - HOL 블로킹
3. HTTP/2 멀티플렉싱 - 연결 하나로 동시 처리
4. HTTP/2 헤더 압축과 우선순위, 그리고 사라진 서버 푸시
5. HTTP/2 이상을 써야 하는 진짜 이유 - 비밀번호 암호화
6. HTTP/3와 QUIC - TCP를 버리다
7. QUIC의 진짜 무기 - 스트림 독립성과 Connection Migration
8. HTTP/1.1 vs HTTP/2 vs HTTP/3 한눈에 비교
9. Apache는 왜 아직도 HTTP/3를 지원하지 않나
10. nginx·LiteSpeed·Caddy는 되는데 - 2026년 지원 현황
11. 실무 경험담 - CDN + HTTP/1.1이면 충분하다
12. 상황별 프로토콜 선택 가이드
13. 자주 묻는 질문 (FAQ)

1. HTTP/1.1이 거의 30년을 버틴 이유

HTTP/1.1은 1997년 RFC 2068로 처음 정의된 프로토콜입니다. 그 뒤로 여러 차례 개정을 거쳤지만, 큰 틀은 거의 30년 가까이 그대로 살아남았습니다. 단순히 오래돼서 관성으로 쓰는 게 아니라, 그 자체로 실질적인 장점이 있기 때문입니다.

 

 

💡 호환성이라는 무기

HTTP/1.1은 세상에 존재하는 거의 모든 웹 서버와 브라우저, HTTP 클라이언트에서 동작합니다. Apache, Nginx, IIS, LiteSpeed를 가리지 않고, 레거시 시스템부터 임베디드 장비, IoT 기기까지 통하지 않는 환경이 사실상 없습니다. HTTP/2나 HTTP/3가 아직 따라오지 못한 가장 강력한 무기죠.

 

 

두 번째는 Keep-Alive입니다. HTTP/1.0 시절엔 요청마다 TCP 연결을 새로 맺고 끊었습니다. HTTP/1.1에서 도입된 지속 연결은 TCP 연결 하나를 여러 요청에 재사용합니다. 핸드셰이크 오버헤드가 줄어드니, 소규모 요청이 많은 환경에서 체감 성능이 꽤 좋아집니다.

세 번째는 디버깅입니다. HTTP/1.1은 사람이 그냥 읽을 수 있는 텍스트 형식이라, curl이나 telnet, Wireshark 같은 도구로 요청과 응답을 바로 눈으로 확인할 수 있습니다. HTTP/2와 HTTP/3는 바이너리 프레임이라 패킷을 떠도 별도 디코딩이 필요하죠. 장애가 터졌을 때 1분이라도 빨리 원인을 봐야 하는 운영 환경에서, 이건 생각보다 큰 차이입니다.

 

 

GET /index.html HTTP/1.1
Host: example.com
User-Agent: curl/7.88.0
Accept: */*

 

 

마지막으로 진입 장벽이 낮습니다. HTTP/1.1은 TLS 없이 평문으로도 동작합니다. 내부망이나 로컬 개발 환경, 사설망 안쪽 마이크로서비스 통신에서는 인증서 발급 절차 없이 서버를 후딱 띄울 수 있습니다. HTTP/3가 TLS 1.3을 아예 내장하고 있는 것과 대비되는 부분이죠.

2. HTTP/1.1의 구조적 한계 - HOL 블로킹

이렇게 장점이 많은데도 HTTP/2가 나온 데는 이유가 있습니다. HTTP/1.1의 가장 큰 약점은 한 TCP 연결에서 요청을 순서대로 처리한다는 점입니다. 앞 요청이 끝나야 다음 요청을 보낼 수 있어요. 이걸 HOL(Head-of-Line) 블로킹이라고 부릅니다.

브라우저는 이 한계를 우회하려고 도메인당 6개쯤 TCP 연결을 동시에 열어 둡니다. 그래도 한계가 있죠. CSS, JS, 이미지가 수십 개씩 붙는 요즘 페이지에서는 이 6개 연결로도 줄이 막힙니다. 과거에 정적 리소스를 여러 서브도메인에 흩뿌리는 '도메인 샤딩' 같은 꼼수가 유행했던 것도 이 때문이었습니다. 지금 와서 보면 그 시절 우리가 했던 최적화가 사실은 프로토콜의 한계를 손으로 메우는 작업이었던 셈입니다.

3. HTTP/2 멀티플렉싱 - 연결 하나로 동시 처리

HTTP/2는 2015년 RFC 7540으로 표준화됐습니다. Google의 SPDY 실험에서 출발한 이 버전은 바로 그 HOL 블로킹을 정조준했습니다. 같은 URL, 같은 서버, 같은 네트워크에서 프로토콜만 HTTP/2로 바꿔도 페이지 로드가 눈에 띄게 빨라집니다.

핵심은 멀티플렉싱입니다. TCP 연결 하나 위에서 여러 요청과 응답을 동시에 스트림 단위로 주고받습니다. 연결을 6개씩 열 필요가 없으니 핸드셰이크 오버헤드도 같이 줄어듭니다. 도메인 샤딩 같은 꼼수도 더는 필요 없어졌고요.

 

 

HTTP/1.1: 요청1 끝 → 요청2 시작 → 요청2 끝 → 요청3 시작...
HTTP/2: 요청1 · 요청2 · 요청3 동시 전송, 응답도 동시 수신

 

4. HTTP/2 헤더 압축과 우선순위, 그리고 사라진 서버 푸시

HTTP/2의 두 번째 장점은 HPACK 헤더 압축입니다. HTTP/1.1은 매 요청마다 Cookie, User-Agent, Accept 같은 헤더를 텍스트로 반복 전송합니다. 쿠키가 많은 사이트면 헤더만 수 킬로바이트에 달하죠. HPACK은 한 번 보낸 헤더를 테이블에 저장해 두고, 다음 요청부터는 바뀐 부분만 보냅니다. 반복 헤더가 많은 환경일수록 절약 효과가 큽니다.

여기에 스트림마다 우선순위를 줄 수 있어서, 렌더링을 막는 CSS·JS를 먼저 받고 이미지나 폰트는 나중에 받도록 조정할 수 있습니다. 같은 대역폭에서도 화면이 더 빨리 그려지는 효과가 나죠.

 

 

📌 서버 푸시(Server Push)는 이제 잊으셔도 됩니다
HTTP/2를 설명하는 옛날 글들은 서버 푸시를 큰 장점으로 꼽습니다.

클라이언트가 요청하기 전에 서버가 CSS·JS를 미리 밀어 넣는 기능이었죠.

그런데 실제로는 캐시 처리가 까다롭고 대역폭만 낭비하는 경우가 많았습니다.

결국 Chrome 106(2022년)이 기본 비활성화했고,

2024년 10월 Firefox 132까지 지원을 빼면서 주요 브라우저에서 사실상 퇴장했습니다.

지금은 103 Early Hints가 그 자리를 대체합니다.

오래된 자료를 보고 서버 푸시를 설정하려 애쓸 필요는 없습니다.

 

5. HTTP/2 이상을 써야 하는 진짜 이유 - 비밀번호 암호화

성능 얘기를 길게 했지만, 사실 더 중요한 건 보안입니다. 바로 비밀번호와 개인정보의 암호화 전송이죠.

HTTPS 없이 평문 HTTP로 로그인 폼을 보내면, 같은 네트워크에 있는 누구나 Wireshark 같은 도구로 아이디와 비밀번호를 그대로 들여다볼 수 있습니다. 카페 와이파이, 회사 내부망, 공용 네트워크 어디서나 마찬가지예요. HTTPS(TLS)를 적용하면 이 페이로드 전체가 암호화돼서, 스니핑해도 랜덤 암호문만 보입니다.

그리고 현실적으로 모든 브라우저가 HTTP/2를 HTTPS에서만 구현합니다. 즉 HTTP/2 이상을 쓴다는 건 곧 SSL 인증서를 적용한다는 뜻이기도 합니다. 성능 때문에 HTTP/2를 켜려다 보안까지 자연스럽게 챙기게 되는 구조죠.

항목	HTTP (평문)	HTTPS (TLS 암호화)
비밀번호 전송	평문 노출 ❌	암호화 ✅
개인정보 보호	스니핑 가능 ❌	보호 ✅
HTTP/2 사용	브라우저 미지원 ❌	완전 지원 ✅
브라우저 표시	"안전하지 않음" 경고 ❌	자물쇠 아이콘 ✅
인증서 비용	해당 없음	Let's Encrypt 무료 ✅

Let's Encrypt 덕분에 SSL 인증서는 무료로 발급받을 수 있습니다. 비밀번호를 다루는 서비스라면 HTTPS는 선택이 아니라 기본이라고 보시면 됩니다.

반응형

6. HTTP/3와 QUIC - TCP를 버리다

HTTP/3는 2022년 RFC 9114로 표준화된 가장 최신 버전입니다. 가장 큰 변화는 기반 전송 프로토콜이 TCP에서 QUIC(Quick UDP Internet Connections)으로 바뀐 것입니다. 이름 그대로 UDP 위에서 동작하지만, 신뢰성과 순서 보장, 혼잡 제어는 QUIC이 자체적으로 구현합니다. "UDP인데 안정적이라고?" 싶지만, 그 안정성 로직을 TCP 대신 QUIC이 떠안았다고 보시면 됩니다.

첫 번째 이점은 빠른 연결 수립입니다. TCP는 연결할 때 3-way 핸드셰이크가 필요하고, HTTPS라면 TLS 핸드셰이크까지 더해집니다. QUIC은 이 과정을 통합해 첫 연결에서도 한 번의 왕복으로 처리하고, 한 번 접속했던 서버라면 0-RTT로 데이터를 바로 보냅니다. 지연이 큰 환경일수록 이 한두 번의 왕복 차이가 체감으로 다가옵니다.

 

 

📌 연결 수립 왕복 횟수 비교
HTTP/1.1 (HTTPS): TCP 3-way + TLS → 최소 2 RTT
HTTP/2 (HTTPS): TCP 3-way + TLS 1.3 → 최소 1 RTT
HTTP/3 (QUIC): 통합 핸드셰이크 → 첫 연결 1 RTT, 재연결 0 RTT

 

7. QUIC의 진짜 무기 - 스트림 독립성과 Connection Migration

QUIC의 진짜 매력은 따로 있습니다. 앞에서 HTTP/2가 멀티플렉싱으로 HOL 블로킹을 해결했다고 했는데, 그건 애플리케이션 레이어 얘기입니다. TCP 레이어의 HOL 블로킹은 HTTP/2에도 여전히 남아 있어요. TCP는 패킷이 하나라도 손실되면, 그 패킷이 재전송될 때까지 연결 전체가 대기합니다.

QUIC은 UDP 위에서 각 스트림을 독립적으로 관리합니다. 스트림 A에서 패킷이 빠져도 스트림 B, C는 멈추지 않고 계속 갑니다. 패킷 손실이 잦은 모바일·무선 환경에서 HTTP/2보다 확실히 안정적인 이유가 여기에 있습니다.

 

 

💡 Connection Migration - 와이파이에서 LTE로 갈아타도 안 끊긴다
TCP 연결은 IP와 포트의 조합으로 식별됩니다. 그래서 와이파이에서 LTE로 넘어가 IP가 바뀌면 연결이 끊기죠. QUIC은 Connection ID라는 별도 식별자로 연결을 관리해서, IP가 바뀌어도 연결이 그대로 이어집니다. 영상 스트리밍이나 실시간 통신에서 특히 빛을 발합니다.

 

 

그리고 HTTP/3는 TLS 1.3이 프로토콜 자체에 내장돼 있습니다. QUIC 없이는 HTTP/3가 성립하지 않고, 암호화 없는 연결도 불가능합니다. 보안이 옵션이 아니라 기본값인 셈이죠. YouTube나 Google 검색은 이미 QUIC을 기본으로 쓰고 있습니다.

8. HTTP/1.1 vs HTTP/2 vs HTTP/3 한눈에 비교

구분	HTTP/1.1	HTTP/2	HTTP/3
표준화	1997년 (RFC 2068)	2015년 (RFC 7540)	2022년 (RFC 9114)
전송 프로토콜	TCP	TCP	UDP (QUIC)
데이터 형식	텍스트	바이너리 프레임	바이너리 프레임
멀티플렉싱	❌	✅	✅ (스트림 독립)
헤더 압축	❌	✅ HPACK	✅ QPACK
TCP HOL 블로킹	있음	있음 (TCP 레이어)	없음 ✅
Connection Migration	❌	❌	✅
TLS	선택 (권장)	사실상 필수	내장 (필수)
Apache 지원	✅	✅ (mod_http2)	❌

9. Apache는 왜 아직도 HTTP/3를 지원하지 않나

nginx도 되고 Caddy도 되고 LiteSpeed도 되는데, Apache HTTP Server는 2026년 현재까지도 정식 릴리스에서 HTTP/3를 네이티브로 지원하지 않습니다. 버전 관리가 게을러서? 아닙니다. 구조적인 문제입니다.

Apache의 MPM(Multi-Processing Module) 구조는 처음부터 TCP 소켓 기반으로 설계됐습니다. 핵심 모듈들이 TCP 소켓 API를 직접 호출하도록 짜여 있죠. 그런데 HTTP/3는 TCP가 아니라 UDP 위의 QUIC을 씁니다. Apache에 HTTP/3를 넣으려면 네트워크 I/O 처리 방식, 즉 MPM 구조 자체를 다시 설계해야 합니다.

수십 년 쌓인 코드베이스의 뿌리를 건드리는 작업이라, 실험적 모듈 시도는 있어도 안정화까지는 시간이 걸리는 게 당연합니다. 개인적으로는 "안 하는 게 아니라 못 하는 거에 가깝다"고 봅니다. 그만큼 Apache가 TCP 위에서 단단하게 굳어 있다는 방증이기도 하고요.

10. nginx·LiteSpeed·Caddy는 되는데 - 2026년 지원 현황

여기서 흔히 도는 오해 하나를 짚고 넘어가겠습니다. "nginx는 유료 버전(Nginx Plus)에서만 HTTP/3가 된다"는 얘기인데, 이건 옛날 정보입니다.

 

 

💡 정정 - nginx 오픈소스도 HTTP/3 지원합니다

nginx는 1.25.0 버전(2023년)부터 오픈소스 공식 빌드에 HTTP/3를 포함했습니다.

무료입니다. 서버 블록에 listen 443 quic 지시어를 추가하고 UDP 443 포트를 열어 주면 됩니다(TLS 1.3 필수).

더 이상 유료 버전을 살 필요가 없어요.

 

 

정리하면 이렇습니다.

- nginx : 오픈소스 1.25.0부터 HTTP/3 지원 (무료)
- LiteSpeed / OpenLiteSpeed : 수년 전부터 기본 활성화. UDP 443만 열면 끝
- Caddy : 기본값으로 HTTP/3 지원
- Apache : 정식 릴리스 네이티브 미지원. 앞단에 nginx·LiteSpeed 리버스 프록시를 두거나 CDN으로 우회

그러니까 Apache를 쓴다고 HTTP/3를 포기해야 하는 게 아닙니다. 우회로가 멀쩡히 있고, 그게 오히려 더 편합니다. 바로 다음 섹션 얘기죠.

11. 실무 경험담 - CDN + HTTP/1.1이면 충분하다

여기서부터가 제가 가장 강조하고 싶은 부분입니다. 오리진 서버가 Apache라서 HTTP/1.1밖에 못 쓴다고 해도, CDN을 앞에 두면 클라이언트는 HTTP/3로 통신할 수 있습니다.

📱 클라이언트 (브라우저)
↓ HTTP/3 (QUIC) — 빠른 암호화 연결
☁️ CDN Edge (Cloudflare · CloudFront)
↓ HTTP/1.1 (TCP) — 내부망, 지연 극소
🖥️ 오리진 서버 (Apache)

구조는 단순합니다. 클라이언트는 가까운 CDN 엣지 서버와 HTTP/3로 빠르게 통신하고, CDN이 오리진 Apache에는 HTTP/1.1로 요청을 전달합니다. CDN과 오리진 사이는 전용 백본망이나 데이터센터 내부라 지연이 극히 짧아서, 오리진이 구버전이어도 엔드 유저 입장에선 HTTP/3의 혜택을 그대로 누립니다.

저는 블로그를 세 개 운영하면서 셋 다 앞에 Cloudflare 무료 플랜을 물려 두고 있습니다. 처음엔 "오리진 서버 설정을 한참 만져야 하나" 걱정했는데, 막상 해 보니 대시보드에서 토글 하나 켜는 걸로 HTTP/3가 붙더군요. 오리진은 손도 안 댔습니다. 색인이나 악성 트래픽으로 골치 썩을 때도 CDN 앞단이 1차 방어선 노릇을 해 줘서, 그 효용을 따지면 프로토콜 버전 고민은 사실 후순위였습니다.

 

 

📌 실무 구성 팁
Cloudflare는 대시보드에서 Speed → Optimization 메뉴의 HTTP/3 (with QUIC)를 켜면 즉시 적용됩니다.

AWS CloudFront도 배포 설정에서 HTTP/3를 활성화할 수 있고요. 둘 다 오리진 설정은 건드릴 필요가 없습니다.

 

 

Apache는 WordPress, PHP 생태계, .htaccess 기반 설정 같은 강력한 호환성을 가진 서버입니다. 멀쩡히 돌아가는 Apache를 HTTP/3 하나 때문에 nginx로 갈아엎는 건, 솔직히 대부분의 경우 과한 결정입니다. CDN 한 겹이면 마이그레이션 없이 성능과 보안을 다 챙길 수 있으니까요.

12. 상황별 프로토콜 선택 가이드

그래서 결국 뭘 써야 하느냐. 상황별로 정리해 보겠습니다.

- 비밀번호·개인정보를 다루는 서비스 → HTTPS(TLS)는 무조건 필수. 여기엔 타협이 없습니다.
- 일반 웹 서비스 → HTTP/2 + HTTPS가 현재의 표준이라고 보면 됩니다.
- 이미 CDN을 쓰고 있다 → HTTP/3는 설정 토글 한 번. 안 켤 이유가 없습니다.
- 소규모 사이트·블로그 → HTTP/1.1 + HTTPS + CDN 조합이면 차고 넘칩니다.
- 내부망·로컬 개발·사설 마이크로서비스 → HTTP/1.1 평문으로도 충분. 인증서 발급에 힘 뺄 필요 없습니다.

핵심은 프로토콜 버전 숫자가 높다고 정답이 아니라는 점입니다. 비밀번호를 다루면 HTTPS, 트래픽이 글로벌이거나 정적 리소스가 많으면 CDN. 이 두 가지를 먼저 챙기고 나면, HTTP/3는 그 위에 얹히는 보너스에 가깝습니다.

13. 자주 묻는 질문 (FAQ)

Q. HTTP/2를 쓰면 HTTP/1.1보다 얼마나 빨라지나요?

리소스가 많은 페이지(CSS·JS·이미지 수십 개)에서는 멀티플렉싱 효과로 로드 시간이 눈에 띄게 줄어드는 사례가 많습니다. 다만 리소스가 한두 개뿐인 단순 페이지나, 서버 응답 시간 자체가 병목인 경우엔 프로토콜만 바꿔서는 큰 효과를 보기 어렵습니다.

Q. 내 사이트가 HTTP/2를 지원하는지 어떻게 확인하나요?

Chrome 개발자 도구(F12) → Network 탭 → Protocol 열을 보세요. h2면 HTTP/2, h3면 HTTP/3, http/1.1이면 HTTP/1.1입니다. Protocol 열이 안 보이면 헤더를 우클릭해서 추가하면 됩니다.

Q. Apache에서 HTTP/2는 쓸 수 있나요?

가능합니다. Apache 2.4.17 이상에서 mod_http2 모듈을 활성화하면 됩니다. 단 SSL(HTTPS)이 설정돼 있어야 합니다. HTTP/3는 앞서 설명한 대로 정식 지원이 안 되니, CDN을 앞에 두는 방식을 권합니다.

Q. HTTP/3는 모든 브라우저에서 지원하나요?

2026년 현재 Chrome, Firefox, Safari, Edge 등 주요 브라우저는 모두 HTTP/3를 지원합니다. 관건은 브라우저가 아니라 서버 측이에요. Cloudflare나 CloudFront를 쓰면 별도 서버 구성 없이 HTTP/3를 제공할 수 있습니다.

Q. 소규모 서비스도 HTTP/3까지 신경 써야 하나요?

꼭 그럴 필요는 없습니다. HTTP/1.1 + HTTPS + CDN 조합이면 소규모 서비스는 충분합니다. 비밀번호를 다룬다면 HTTPS만 빠뜨리지 마세요. HTTP/3는 CDN을 이미 쓰고 있다면 옵션만 켜면 되니, 따로 큰 작업을 들일 일은 아닙니다.

Q. HTTP/3 도입했는데 일부 연결이 HTTP/2로 떨어집니다. 정상인가요?

정상입니다. QUIC은 UDP를 쓰는데, 일부 기업 방화벽이나 통신 환경에서 UDP 443이 막혀 있으면 브라우저가 자동으로 HTTP/2(TCP)로 폴백합니다. HTTP/3는 "되면 쓰고 안 되면 내려가는" 구조라, 폴백 자체가 설계의 일부입니다.

마무리

HTTP/1.1은 호환성과 단순함으로 거의 30년을 버텼고, 디버깅이 쉬워 운영 환경에서 여전히 현역입니다. HTTP/2는 멀티플렉싱과 헤더 압축으로 성능을 끌어올리며 지금의 표준이 됐고, HTTPS와 묶이면서 보안까지 끌고 왔습니다. HTTP/3는 QUIC으로 TCP의 한계를 넘어 모바일·고손실 환경에서 빛납니다.

그런데 제가 실무에서 내린 결론은 좀 다른 결입니다. 프로토콜 버전 경쟁에 매달리기보다, 비밀번호를 다루면 HTTPS, 트래픽을 빠르게 뿌리려면 CDN — 이 두 가지를 먼저 챙기는 게 훨씬 실질적입니다. Apache가 HTTP/3를 지원하든 안 하든, Cloudflare 앞단 한 겹이면 클라이언트는 HTTP/3를 누립니다. 멀쩡한 서버를 버전 숫자 하나 때문에 갈아엎는 건, 적어도 제 경험상으론 답이 아니었습니다.

물론 트래픽 규모가 어마어마하거나 오리진 단의 미세 최적화까지 짜내야 하는 서비스라면 얘기가 또 달라지겠죠. 정답은 결국 내 서비스의 규모와 트래픽 성격이 정해 줍니다. 이 글이 그 판단의 출발점이 됐으면 합니다.

용어집 - 헷갈리는 네트워크 용어 정리

본문에 나온 용어 중 처음 보면 막히기 쉬운 것들만 풀어서 정리했습니다. 위로 올라가 다시 읽기 귀찮을 때 여기서 빠르게 확인하세요.

용어	쉽게 풀어쓰면
TCP / UDP	데이터를 주고받는 두 가지 방식. TCP는 순서·도착을 꼼꼼히 보장하지만 느릴 수 있고, UDP는 일단 빠르게 보내는 방식. QUIC은 빠른 UDP 위에 TCP의 안정성을 다시 얹은 것.
핸드셰이크 (Handshake)	통신을 시작하기 전 서버와 "연결할까요? 좋아요" 하고 인사를 주고받는 과정. 인사 횟수가 많을수록 첫 연결이 느려진다.
RTT / 0-RTT	RTT(Round Trip Time)는 신호가 갔다가 돌아오는 한 번의 왕복 시간. 0-RTT는 그 왕복 없이 데이터를 바로 보내는 것으로, 재접속 시 체감 속도가 빨라진다.
HOL 블로킹	Head-of-Line Blocking. 줄 맨 앞 사람이 막히면 뒷사람 전부 못 가는 상황. 앞 요청 하나가 늦으면 뒤 요청들이 다 같이 대기하는 병목.
멀티플렉싱 (Multiplexing)	연결 하나로 여러 요청·응답을 동시에 주고받는 기술. 차선 하나에서 여러 대가 한꺼번에 달리는 셈.
스트림 (Stream)	연결 하나 안에서 독립적으로 흐르는 데이터의 한 줄기. HTTP/2·3는 여러 스트림을 동시에 다룬다.
Keep-Alive	한 번 맺은 연결을 끊지 않고 다음 요청에 재사용하는 것. 매번 새로 연결하는 수고를 던다.
QUIC	Quick UDP Internet Connections. HTTP/3의 토대가 되는 전송 프로토콜. UDP 위에서 동작하면서 신뢰성·암호화를 자체적으로 처리한다.
TLS / TLS 1.3	통신 내용을 암호화하는 보안 규약. HTTPS의 'S'가 바로 이것. 1.3은 가장 최신 버전으로 더 빠르고 안전하다.
HPACK / QPACK	반복되는 헤더를 압축해 대역폭을 아끼는 기술. HPACK은 HTTP/2, QPACK은 HTTP/3에서 사용한다.
Connection Migration	와이파이에서 LTE로 갈아타 IP가 바뀌어도 연결을 끊지 않고 이어 주는 QUIC의 기능. Connection ID라는 식별자로 연결을 추적한다.
서버 푸시 / 103 Early Hints	서버 푸시는 요청 전에 리소스를 미리 밀어 넣던 HTTP/2 기능(현재 퇴장). 103 Early Hints는 "이것들 미리 받아 두세요"라고 힌트만 주는 대체 방식.
도메인 샤딩	HTTP/1.1의 연결 수 한계를 우회하려고 리소스를 여러 서브도메인에 나눠 담던 옛날 기법. HTTP/2 멀티플렉싱 등장으로 더는 필요 없어졌다.
CDN / 오리진 / 엣지	CDN은 콘텐츠를 사용자 가까이에 뿌려 주는 분산 네트워크. 원본 서버를 '오리진', 사용자와 가까운 CDN 서버를 '엣지'라 부른다.
리버스 프록시	클라이언트 요청을 대신 받아 뒤쪽 서버로 전달하는 중간 서버. 앞단에서 HTTP/3를 받아 뒤 서버엔 HTTP/1.1로 넘기는 식으로 쓴다.
MPM (Apache)	Multi-Processing Module. Apache가 연결과 요청을 처리하는 핵심 구조. TCP 기반으로 설계돼 있어 HTTP/3(UDP) 적용이 어렵다.
폴백 (Fallback)	상위 방식이 안 되면 자동으로 하위 방식으로 내려가는 것. HTTP/3가 막히면 HTTP/2로 떨어지는 식으로 안전장치 역할을 한다.

📚 함께 보면 좋은 글

Apache Nginx Tomcat 차이 완벽 정리 - 웹서버 30년 변천사로 이해하기

꼭 외워야 할 TCP/UDP 포트 번호 모음 - 13년 차 개발자가 후배에게 외우라고 하는 포트들

DNS 레코드 타입 종류 총정리 — A·AAAA·CNAME·MX·TXT·NS, 실무에서 진짜 쓰는 6가지

크론(cron) 표현식 완벽 정리 - 0 0 * * * 의미부터 초 단위 실행, 실시간 큐 전환까지

HTTP 상태 코드 정리표 - 404보다 무서운 건 200이었습니다