HTTP/2는 하나의 연결에서 요청을 멀티플렉싱하고 헤더를 압축합니다. HTTP/3는 QUIC 위에서 동작하며 한 스트림의 손실이 다른 스트림 전달을 막는 문제를 줄이고 연결 이동을 지원할 수 있습니다. 새 프로토콜도 애플리케이션 처리, 큰 리소스, 렌더링을 제거하지는 않습니다. 실제 협상된 버전을 확인하고 중요한 사용자 경로를 측정해야 합니다.
HTTP/1.1의 한계를 구분합니다
HTTP 의미 체계는 메서드, 상태, 헤더, 리소스를 설명하고 전송 방식은 메시지가 이동하는 방법을 정합니다. HTTP/2나 HTTP/3로 바꿔도 GET의 애플리케이션 동작이나 응답의 캐시 가능성이 자동으로 바뀌지는 않습니다. 전송과 캐시 정책 변경을 별도로 진단해야 하는 이유입니다.
HTTP/1.1은 지속 연결을 지원하지만 일반적인 브라우저 사용에서는 한 연결에서 응답을 자유롭게 섞어 전달하지 못합니다. 파이프라이닝은 순서 제약이 있어 보편적인 브라우저 해결책이 되지 못했습니다. 브라우저는 구현별 제한 안에서 여러 연결을 사용하며 추가 연결에는 설정 비용과 자원 경쟁이 생깁니다.
이 때문에 파일 묶기와 여러 호스트로 분산하기가 사용됐습니다. 대기 시간을 줄이기도 했지만 큰 번들, DNS, 추가 연결도 만들었습니다. 최신 프로토콜은 이 절충을 바꾸지만 과거 최적화를 측정 없이 모두 제거하라는 뜻은 아닙니다.
서버 응답 시간 가이드로 연결 대기와 애플리케이션 대기를 나눕니다. HTML 생성이 대부분이라면 전송 업그레이드 후에도 가장 큰 지연은 남을 수 있습니다.
HTTP/2 멀티플렉싱의 변화를 이해합니다
HTTP/2는 메시지를 스트림의 바이너리 프레임으로 나타냅니다. 여러 스트림이 TCP 연결을 공유하므로 각 응답이 완전히 끝날 때까지 기다리지 않고 진행할 수 있습니다. HPACK은 반복되는 헤더 필드를 압축합니다.
멀티플렉싱은 무한한 대역폭이 아닙니다. 스트림은 용량을 경쟁하며 스케줄링과 흐름 제어에 영향을 받습니다. 선택 리소스를 모두 즉시 요청하면 핵심 이미지나 스타일시트의 용량을 빼앗을 수 있습니다. 워터폴의 연결 대기가 달라져도 발견 시점과 우선순위는 중요합니다.
HTTP/2는 TCP의 순서 있는 바이트 스트림을 유지합니다. 손실로 빈 구간이 생기면 TCP는 뒤의 바이트를 순서대로 전달하기 전에 이를 복구해야 하므로 다른 HTTP 스트림도 지연될 수 있습니다. 이는 HTTP/1.1 응답 순서와 다른 전송 계층의 선두 차단이며 HTTP/3가 도움이 되는 조건을 설명합니다.
서버 푸시는 HTTP/2 규격의 역사에 포함되지만 최신 브라우저의 일반적인 최적화로 의존하면 안 됩니다. 명확한 리소스 발견을 대신하지 않습니다. 실제 브라우저와 서버 기능을 확인하고 핵심 리소스에는 지원되는 로딩 방법을 사용합니다.
HTTP/3에 QUIC가 더하는 기능을 살핍니다
HTTP/3는 UDP 데이터그램을 사용하는 보안 멀티플렉싱 전송인 QUIC에 HTTP를 매핑합니다. QUIC는 신뢰할 수 있는 스트림, 손실 복구, 혼잡 제어를 제공합니다. UDP를 사용한다고 응답 바이트를 복구 없이 잃는 것은 아닙니다. 암호화는 연결 설정에 통합됩니다.
한 스트림의 손실이 HTTP/2의 TCP처럼 다른 스트림을 같은 방식으로 기다리게 하지는 않습니다. 그러나 공통 혼잡 제어, 네트워크 용량, 프로토콜 의존성은 남습니다. 따라서 모든 차단이 사라지거나 손실 있는 모든 네트워크에서 항상 빠르다는 표현은 부정확합니다.
QUIC 연결 ID는 엔드포인트 지원과 경로 검증에 따라 네트워크 경로가 바뀌어도 연결을 이어갈 수 있습니다. Wi-Fi에서 모바일로 전환하는 상황은 시험 대상이지 모든 기기에 대한 무중단 보장은 아닙니다. UDP를 차단하거나 제한하는 네트워크도 있으므로 대체 연결이 필요합니다.
연결 재개는 0-RTT라는 조기 데이터를 허용할 수 있습니다. 적합한 재개 연결에만 해당하며 모든 첫 방문은 아닙니다. 재전송 공격 위험에 대한 서버와 애플리케이션 보호가 필요하므로 계정 변경이나 결제에 무조건 활성화하지 않습니다. HTTP/3 적용에 모든 선택 기능이 필요한 것은 아닙니다.
프로토콜의 차이는 다음과 같습니다.
| 특성 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| 일반 브라우저 전송 | TCP, HTTPS는 TLS 사용 | TCP와 TLS | UDP 위 QUIC |
| 한 연결의 병렬 응답 | 응답 순서에 제약 | 멀티플렉싱 스트림 | QUIC 멀티플렉싱 스트림 |
| 헤더 압축 | HPACK과 QPACK 없음 | HPACK | QPACK |
| 손실 격리 | TCP 순서 적용 | TCP가 모든 스트림에 영향 가능 | 더 독립적인 스트림 전달 |
| 애플리케이션 병목 | 남음 | 남음 | 남음 |
브라우저가 실제 협상한 연결을 확인합니다
Chrome DevTools Network의 표 머리글 메뉴에서 Protocol 열을 켭니다. 새로고침하고 문서와 주요 리소스를 각각 확인합니다. h2, h3는 해당 요청의 연결을 나타냅니다. 같은 페이지의 서로 다른 원본은 다른 프로토콜을 쓸 수 있습니다.
CDN이 연결을 종료하면 이 열은 브라우저에서 엣지까지의 구간입니다. CDN과 원본 사이에는 다른 버전이 사용될 수 있습니다. 문서가 h3라고 원본도 HTTP/3를 지원하는 것은 아니며 원본이 구형이어도 방문자 구간의 모든 이득이 사라지지는 않습니다. CDN과 엣지 캐시 가이드에서 이 구분을 설명합니다.
브라우저는 Alt-Svc나 지원되는 DNS 방식으로 HTTP/3를 발견할 수 있습니다. 첫 요청과 이후 요청은 다를 수 있습니다. 기존 연결, 저장된 알림, 인증서, UDP 차단도 영향을 줍니다. 맥락 없이 반복 새로고침하기보다 새 연결로 시작했는지 기록합니다.
curl은 빌드별 기능을 먼저 확인합니다. 모든 설치가 HTTP/3를 지원하지는 않습니다.
curl --version
curl --http2 -sS -o /dev/null -w '%{http_version}\n' https://example.com/
curl --http3-only -sS -o /dev/null -w '%{http_version}\n' https://example.com/HTTP/3 전용 요청은 대체 연결을 의도적으로 제외하므로 지원이나 연결 문제를 드러낼 수 있습니다. 진단 시험이며 모든 브라우저 동작의 재현은 아닙니다. 옵션이 협상을 보장한다고 가정하기보다 성공 후 출력된 버전을 확인합니다.
제어할 수 있는 계층에서 활성화합니다
관리형 호스팅이나 CDN은 현재 문서와 관리 화면부터 확인합니다. 적용 호스트와 구간, 유효한 인증서, 원본 연결, HTTP/2 대체 연결을 검증합니다. 설정 스위치와 실제 h3 요청은 서로 다른 증거입니다.
mod_http2가 로드된 Apache HTTP Server 2.4는 Protocols를 지원합니다. 기존 TLS 가상 호스트에 다음 조각으로 HTTP/2와 HTTP/1.1 대체 연결을 제공할 수 있습니다.
Protocols h2 http/1.1TLS와 인증서 설정은 유지합니다. mod_http2에서 HTTP/3 지원을 추론하면 안 됩니다. 별도 기능이므로 설치 패키지와 프런트엔드를 확인한 뒤 종료 지점을 선택합니다.
Nginx의 독립 http2 on 지시문은 1.25.1부터 제공됩니다. HTTP/3는 해당 모듈과 호환 TLS 라이브러리가 필요하며 공식 문서는 모듈을 실험적이라고 설명합니다. 아래는 유효한 인증서와 필수 모듈이 있는 기존 TLS 서버 블록용입니다.
서로 다른 전송을 사용해 같은 포트 번호에서 TCP 기반 HTTPS와 QUIC를 활성화합니다.
listen 443 ssl;
listen 443 quic reuseport;
http2 on;
add_header Alt-Svc 'h3=":443"; ma=86400';여러 가상 호스트가 같은 주소를 쓸 때 특히 기존 리스너를 중복하지 말고 통합합니다. add_header 전에 상속을 검토합니다. 모든 관련 방화벽과 로드밸런서에서 UDP 443을 허용하고 TCP 443도 유지합니다. 광고 수명은 예시이며 QUIC 접근 가능성의 증거가 아닙니다.
nginx -t 후 외부 클라이언트에서 시험하고 확장합니다. 빌드 옵션, TLS, 조기 데이터 지원이 다르므로 설치 버전 문서를 사용합니다. 이 조각이나 문법 통과가 완전한 서버 보안 설정은 아닙니다.
샤딩과 스프라이트, 큰 번들을 다시 평가합니다
도메인 샤딩은 파일을 여러 호스트로 나눠 병렬 연결을 늘립니다. 최신 멀티플렉싱에서는 불필요한 DNS와 연결 비용을 더하고 재사용을 줄일 수 있습니다. 인증서, 캐시, 우선순위, 실제 페이지 효과를 확인한 뒤 합칩니다. 연결 병합이 가능한 경우도 있지만 임의의 호스트가 모두 비용이 없다는 뜻은 아닙니다.
이미지 스프라이트는 특정 디자인에 유용할 수 있으나 사용하지 않는 픽셀을 전송하고 갱신 때 무관한 내용을 무효화할 수 있습니다. 모든 JavaScript를 한 번들로 묶으면 요청은 줄어도 각 경로가 필요 없는 기능까지 다운로드하고 처리합니다.
반대로 모든 것을 작은 파일로 나누는 극단도 피합니다. 요청, 헤더, 압축, 의존성 조정 비용은 남습니다. 의미 있는 기능 경계를 사용하고 초기 로드와 재탐색을 비교합니다. 브라우저 캐시 가이드는 안정적인 해시 파일의 영향을 설명합니다.
한 번의 빠른 새로고침보다 넓게 측정합니다
대표 기기와 네트워크에서 리소스 버전, 캐시 상태, 서버 조건을 맞춥니다. 새 연결, 재개 연결, 재방문, HTTP/3가 불가능한 경로를 포함합니다. 의도한 설정이 아니라 각 실행에서 실제 협상한 버전을 기록합니다.
연결 설정, TTFB, 핵심 리소스 완료, 사용자에게 보이는 성능을 측정합니다. 원인을 구분하려면 CDN 라우팅, 압축, 캐시, 프로토콜을 동시에 바꾸지 않습니다. 따뜻한 캐시나 다른 엣지가 프로토콜 향상처럼 보일 수 있습니다.
성능 체크리스트에 설정과 대체 연결 검사를 적습니다. 서버 성능 모음과 HTTP/3 규격을 참고해 조사합니다. 실제 경로의 신뢰성이 유지되고 측정으로 이득이 확인된다면 이론보다 작은 개선이어도 적용할 수 있습니다.
