HTTP/1.1·HTTP/2·HTTP/3의 가장 큰 차이는 웹 문법 자체보다 데이터를 나누고 전송하는 통신 구조에 있습니다. HTTP/1.1은 TCP 연결에서 순차적인 메시지를 주고받고, HTTP/2는 하나의 TCP 연결에서 여러 요청을 동시에 처리하며, HTTP/3는 QUIC을 통해 전송 계층의 지연 문제까지 줄이도록 설계됐습니다.
📌 핵심 5줄 요약
1. HTTP/1.1은 사람이 읽기 쉬운 텍스트 형식과 TCP 연결을 사용합니다.
2. HTTP/2는 바이너리 프레임, 헤더 압축, 멀티플렉싱으로 여러 요청을 한 연결에서 처리합니다.
3. HTTP/3는 QUIC 위에서 동작하며, QUIC은 UDP를 기반으로 TLS 1.3과 스트림 기능을 제공합니다.
4. HTTP/2도 멀티플렉싱을 지원하지만 TCP 패킷 손실이 연결 전체의 스트림에 영향을 줄 수 있습니다.
5. HTTP/3가 항상 빠른 것은 아니며 서버·브라우저·네트워크가 지원할 때 상황에 맞게 선택됩니다.
📌 목차
01 | HTTP는 무엇을 담당할까
02 | HTTP/1.1의 기본 통신 방식
03 | HTTP/1.1의 연결과 순차 처리
04 | HTTP/2가 바꾼 프레임 구조
05 | HTTP/2의 멀티플렉싱
06 | HTTP/2의 헤더 압축과 우선순위
07 | HTTP/3와 QUIC의 관계
08 | TCP와 UDP는 어떻게 다를까
09 | HOL 블로킹 차이
10 | 암호화와 연결 수립
11 | 세 버전 비교표
12 | 실제 웹페이지에서의 변화
13 | HTTP/3의 한계와 예외
14 | 사용자가 확인할 수 있는 방법
01 | HTTP는 무엇을 담당할까
HTTP는 브라우저와 서버가 웹 문서를 요청하고 응답하는 애플리케이션 계층 프로토콜입니다. 어떤 주소의 자원을 요청할지, 성공·실패 상태를 어떻게 표시할지, 본문과 헤더를 어떤 의미로 해석할지 정합니다.
HTTP/1.1·HTTP/2·HTTP/3는 GET, POST, 상태 코드, 쿠키, 캐시 같은 핵심 의미를 대체로 공유합니다. 따라서 HTTP/2나 HTTP/3로 바뀌어도 웹 개발자가 사용하는 URL과 상태 코드의 기본 개념이 완전히 달라지는 것은 아닙니다.
02 | HTTP/1.1의 기본 통신 방식
HTTP/1.1 메시지는 요청 또는 응답의 시작 줄, 헤더 필드, 빈 줄, 선택적인 본문으로 구성됩니다. 텍스트 기반이므로 네트워크 도구나 로그에서 구조를 확인하기 비교적 쉽습니다.
예를 들어 브라우저는 서버에 특정 경로의 문서를 요청하고, 서버는 상태 코드와 콘텐츠 유형, 본문을 응답합니다. 이 구조는 단순하고 호환성이 높아 오래된 서버와 장비에서도 널리 사용돼 왔습니다.
03 | HTTP/1.1의 연결과 순차 처리
HTTP/1.1은 지속 연결을 사용할 수 있지만, 하나의 연결에서 요청과 응답이 순서에 영향을 받기 쉽습니다. 앞선 응답이 늦어지면 뒤의 응답이 기다리는 현상이 발생할 수 있어 브라우저는 여러 TCP 연결을 열어 병렬 요청을 시도하기도 했습니다.
그러나 연결을 여러 개 만들면 연결 수립과 혼잡 제어가 반복되고, 서버와 네트워크 자원을 더 사용하게 됩니다. 웹페이지가 이미지·스크립트·스타일시트처럼 많은 파일로 구성될수록 이런 구조적 부담이 커질 수 있습니다.
04 | HTTP/2가 바꾼 프레임 구조
HTTP/2는 HTTP 메시지를 바이너리 프레임으로 나눠 전송합니다. 사람 눈에 바로 읽히는 텍스트 형식은 아니지만, 프레임 단위로 메시지를 정리하기 때문에 요청과 응답을 효율적으로 조합할 수 있습니다.
HTTP/2는 HTTP의 메서드, 상태 코드, URI 같은 의미를 바꾸기보다 이를 전달하는 표현과 전송 방식을 개선했습니다. 따라서 기존 웹 애플리케이션을 큰 폭으로 수정하지 않고도 서버와 클라이언트가 HTTP/2를 지원하도록 구성할 수 있습니다.
05 | HTTP/2의 멀티플렉싱
HTTP/2의 핵심 기능은 하나의 TCP 연결 안에서 여러 스트림을 동시에 처리하는 멀티플렉싱입니다. HTML 문서, CSS, 자바스크립트, 이미지 요청이 하나의 연결에 섞여 전달되더라도 각 요청과 응답을 스트림으로 구분할 수 있습니다.
이 방식은 HTTP/1.1처럼 요청마다 여러 연결을 만드는 필요성을 줄이고, 연결 수립 비용과 중복된 네트워크 처리를 낮추는 데 유리합니다. 다만 모든 지연 문제가 사라지는 것은 아닙니다. HTTP/2의 여러 스트림은 여전히 TCP 연결을 공유하기 때문입니다.
06 | HTTP/2의 헤더 압축과 우선순위
HTTP/2는 HPACK을 사용해 반복되는 헤더 정보를 효율적으로 표현합니다. 쿠키, 사용자 에이전트, 콘텐츠 협상처럼 여러 요청에서 반복되는 헤더가 많을 때 전송해야 하는 정보량을 줄이는 데 도움이 됩니다.
HTTP/2에는 요청 처리 우선순위와 관련된 기능도 정의돼 있습니다. 다만 실제 결과는 브라우저, 서버, 프록시, 콘텐츠 구성에 따라 달라지므로 HTTP/2를 사용한다고 모든 자원이 자동으로 같은 폭만큼 빨라지는 것은 아닙니다.
07 | HTTP/3와 QUIC의 관계
HTTP/3는 HTTP 의미를 QUIC 전송 프로토콜 위에 매핑한 규격입니다. QUIC은 UDP를 기반으로 하면서도 신뢰성 있는 전송, 스트림별 흐름 제어, 혼잡 제어, TLS 1.3 기반 보안 연결을 제공합니다.
즉 HTTP/3가 단순히 HTTP/2의 번호만 바꾼 버전은 아닙니다. HTTP/2가 주로 TCP 위에서 동작하는 프레이밍 계층을 추가했다면, HTTP/3는 스트림과 연결 수립 특성을 전송 계층인 QUIC과 결합한 구조입니다.
08 | TCP와 UDP는 어떻게 다를까
TCP는 데이터가 순서대로 도착하도록 관리하고, 손실된 데이터의 재전송을 처리하는 연결 지향 전송 프로토콜입니다. 이런 특성은 안정적이지만 하나의 TCP 연결에서 패킷이 손실되면 해당 연결의 데이터 처리가 영향을 받을 수 있습니다.
UDP는 TCP처럼 모든 전송 기능을 기본 제공하지 않는 비교적 단순한 데이터그램 방식입니다. QUIC은 UDP 위에 필요한 신뢰성, 암호화, 스트림, 혼잡 제어 기능을 직접 구성해 HTTP에 맞는 전송 방식을 제공합니다.
09 | HOL 블로킹 차이
HOL은 Head-of-Line의 약자로, 앞선 데이터가 처리되지 않아 뒤의 데이터도 대기하는 현상을 뜻합니다. HTTP/1.1에서는 요청과 응답 순서가 영향을 받아 애플리케이션 수준의 대기가 나타나기 쉽습니다.
HTTP/2는 스트림을 분리해 애플리케이션 수준의 대기를 줄였지만 TCP 패킷 손실이 발생하면 같은 연결의 여러 스트림이 함께 기다릴 수 있습니다. HTTP/3의 QUIC은 스트림별로 손실 복구를 처리하므로 한 스트림의 손실이 다른 스트림 전체를 멈추게 하는 문제를 줄이도록 설계됐습니다.
10 | 암호화와 연결 수립
HTTP 자체와 HTTPS는 구분해야 합니다. HTTPS는 HTTP를 TLS로 보호하는 사용 방식이며, HTTP/2는 일반적으로 TLS와 함께 사용됩니다. HTTP/3는 QUIC의 연결 과정에 TLS 1.3 이상을 사용하도록 규정합니다.
HTTP/3는 연결 수립 지연을 줄일 가능성이 있지만, 실제 연결 시간은 네트워크 왕복 시간, 서버 설정, 재연결 여부, 암호화 협상 등에 따라 달라집니다. 따라서 프로토콜 버전만으로 성능을 단정해서는 안 됩니다.
11 | 세 버전 비교표
| 구분 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| 주요 전송 기반 | TCP | TCP | QUIC over UDP |
| 표현 방식 | 텍스트 메시지 | 바이너리 프레임 | 바이너리 프레임 |
| 동시 처리 | 제한적·연결 분산 | 하나의 연결에서 멀티플렉싱 | QUIC 스트림 기반 멀티플렉싱 |
| 헤더 압축 | 기본 제공 없음 | HPACK | QPACK |
| 패킷 손실 영향 | 순차 처리 지연 가능 | TCP 연결 전체에 영향 가능 | 스트림별 복구로 영향 분리 |
| 핵심 목표 | 호환성과 단순성 | 효율적인 다중 요청 | 낮은 지연과 연결 안정성 개선 |
12 | 실제 웹페이지에서의 변화
사용자가 체감하는 변화는 페이지 구성과 네트워크 환경에 따라 다릅니다. 여러 정적 파일을 동시에 내려받는 페이지에서는 HTTP/2나 HTTP/3의 멀티플렉싱이 유리할 수 있습니다.
반대로 단순한 페이지, 서버 처리 시간이 긴 페이지, 데이터베이스가 병목인 서비스에서는 프로토콜을 바꿔도 전체 응답 시간이 크게 줄지 않을 수 있습니다. 웹 성능을 개선할 때는 프로토콜과 함께 서버 응답 시간, 이미지 용량, 캐시, 자바스크립트 실행 시간을 함께 확인해야 합니다.
13 | HTTP/3의 한계와 예외
HTTP/3는 UDP를 사용하므로 일부 방화벽, 기업 네트워크, 보안 장비가 UDP 트래픽을 제한하면 연결에 실패할 수 있습니다. HTTP/3 규격도 이런 연결 문제에 대비해 클라이언트가 TCP 기반 HTTP 버전을 시도할 수 있도록 설명합니다.
또한 HTTP/3를 지원하려면 웹 서버, CDN, 로드밸런서, 프록시 등 관련 구성 요소가 함께 지원해야 합니다. 지원되지 않는 환경에서는 HTTP/2 또는 HTTP/1.1로 자동 대체될 수 있으므로 HTTP/3를 활성화했다고 모든 접속이 HTTP/3가 되는 것은 아닙니다.
14 | 사용자가 확인할 수 있는 방법
브라우저의 개발자 도구에서 네트워크 요청 목록에 표시되는 프로토콜 열을 확인하면 현재 연결이 HTTP/1.1, HTTP/2, HTTP/3 중 무엇인지 파악할 수 있습니다. 브라우저와 운영체제에 따라 표시 위치와 명칭은 다를 수 있습니다.
웹사이트 운영자는 서버 로그, CDN 대시보드, 웹 성능 측정 도구에서 프로토콜별 응답 시간과 오류율을 비교할 수 있습니다. 단순히 HTTP/3 사용 여부만 보지 말고 첫 바이트까지의 시간, 전체 다운로드 시간, 연결 실패율을 함께 확인하는 것이 좋습니다.
☑ 체크리스트
□ HTTP 버전과 HTTPS를 같은 개념으로 보고 있지 않은지 확인합니다.
□ HTTP/2의 멀티플렉싱과 HTTP/3의 QUIC 스트림을 구분합니다.
□ HTTP/2도 TCP 패킷 손실의 영향을 받을 수 있다는 점을 기억합니다.
□ HTTP/3 도입 전 방화벽·프록시·CDN의 UDP 지원 여부를 확인합니다.
□ 프로토콜 변경 전 서버 처리 시간과 정적 파일 용량을 측정합니다.
□ 개발자 도구에서 실제 접속에 사용된 프로토콜을 확인합니다.
📖 자주하는 질문 Q&A
HTTP/2와 HTTP/3 중 무엇이 더 빠른가요?
일반적으로 HTTP/3는 패킷 손실이나 네트워크 전환이 있는 환경에서 유리할 가능성이 있지만, 항상 더 빠르다고 단정할 수는 없습니다. 서버 구성과 콘텐츠, 네트워크 품질을 함께 측정해야 합니다.
HTTP/3는 UDP라서 보안에 취약한가요?
UDP를 사용한다는 사실만으로 보안 수준이 결정되지는 않습니다. HTTP/3는 QUIC을 통해 TLS 1.3 이상을 사용하며, 연결의 기밀성과 무결성, 서버 인증을 제공하도록 설계됐습니다.
HTTP/1.1은 아직 사용할 수 있나요?
HTTP/1.1은 현재도 호환성 확보를 위한 기본적인 HTTP 버전으로 사용될 수 있습니다. 다만 서비스 환경에 따라 HTTP/2나 HTTP/3가 선택되며, 클라이언트와 서버가 협상한 버전이 실제 연결에 적용됩니다.
HTTP/2에서 서버 푸시는 지금도 중요한가요?
HTTP/2 규격에는 서버 푸시 관련 기능이 있었지만, 실제 브라우저와 서비스 환경에서는 활용 방식이 제한적이었습니다. 현재는 preload나 103 Early Hints 같은 대안이 함께 검토됩니다.
📝 마무리
HTTP/1.1·HTTP/2·HTTP/3는 같은 HTTP 의미를 공유하면서도 전송 구조가 다릅니다. HTTP/1.1은 단순성과 호환성, HTTP/2는 TCP 연결 안에서의 효율적인 다중 처리, HTTP/3는 QUIC 기반의 스트림 분리와 연결 지연 개선에 초점이 있습니다. 실제 성능은 프로토콜 버전만이 아니라 서버와 네트워크 환경을 함께 측정해 판단해야 합니다.