HTTP/2·HTTP/3 적용 확인｜Protocol·Alt-Svc 30분 진단
서버에서 HTTP/3를 켰다는 안내만으로 실제 방문 요청이 HTTP/3를 사용한다고 단정할 수 없습니다. 브라우저는 서버 광고, 네트워크의 UDP 허용 여부, 연결 재사용과 캐시 상태에 따라 HTTP/2나 HTTP/1.1을 사용할 수 있습니다. 고정된 ‘몇 배 빠름’ 수치보다 동일한 URL의 프로토콜·연결 시간·전송량을 확인해야 합니다.
이 글은 Chrome DevTools와 curl로 h2·h3, Alt-Svc, fallback을 확인하고 한 계층씩 적용·원복하는 30분 점검 순서입니다.
10초 요약
- HTTP/2는 하나의 TCP 연결에서 여러 스트림을 다중화합니다.
- HTTP/3는 QUIC 위에서 동작하며 스트림 단위 손실 처리를 지원합니다.
- HTTP/3가 항상 더 빠른 것은 아니며 네트워크·서버·요청 구조에 따라 결과가 달라집니다.
- Chrome Network의 Protocol 열에서 실제 요청별
h2·h3를 확인합니다. - 첫 방문과 재방문, 캐시 HIT와 MISS를 나눠 측정합니다.
- UDP 경로가 막히면 TCP 기반 버전으로 전환되는지 확인합니다.
HTTP/1.1·HTTP/2·HTTP/3의 운영 차이
| 항목 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| 주요 전송 | TCP | TCP | QUIC·UDP |
| 병렬 요청 | 여러 연결을 사용하는 경우가 많음 | 한 연결의 여러 스트림 | 한 QUIC 연결의 독립 스트림 |
| 연결 보안 | HTTPS에서 TLS | 웹 브라우저는 보통 TLS와 사용 | QUIC에 TLS 1.3 통합 |
| 패킷 손실 영향 | 해당 TCP 연결이 대기 | TCP 손실로 활성 스트림이 함께 지연될 수 있음 | 손실된 QUIC 스트림과 다른 스트림이 독립적으로 진행 가능 |
| DevTools 표시 | http/1.1 | h2 | h3 |
| 운영 원칙 | 호환 경로 확인 | 안정적인 기본 경로 | 지원 경로에 추가하고 fallback 유지 |
HTTP/2와 HTTP/3는 HTTP 의미를 바꾸는 것이 아니라 전송과 프레이밍 방식을 개선합니다. 이미지 최적화, 느린 원본 응답, 과도한 JavaScript 실행 비용은 프로토콜만 바꿔 해결되지 않습니다.
1단계: Chrome에서 실제 Protocol 열 확인
- 시크릿 창에서 DevTools의 Network를 엽니다.
- 요청 표 머리글을 마우스 오른쪽 버튼으로 눌러 Protocol 열을 표시합니다.
- 캐시 사용 중지 상태로 페이지를 새로고침합니다.
- HTML·CSS·JavaScript·이미지의 Protocol 값을 각각 기록합니다.
- 창을 닫고 다시 접속해 첫 방문과 재방문 결과를 비교합니다.
같은 페이지에서도 외부 광고·분석·글꼴 도메인은 다른 프로토콜을 사용할 수 있습니다. 페이지 한 줄의 결과가 아니라 문제 URL별 Protocol, Domain, Remote address를 확인하세요.
2단계: 응답 헤더와 HTTP/3 광고 확인
curl -I --http2 https://example.com/
curl -I --http1.1 https://example.com/응답의 Alt-Svc에 h3가 광고되는지 확인합니다. 광고가 있어도 현재 요청이 곧바로 HTTP/3였다는 뜻은 아닙니다. 클라이언트가 정보를 저장한 다음 연결에서 사용하거나, UDP 연결이 실패해 이전 버전으로 돌아갈 수 있습니다.
curl의 HTTP/3 지원은 설치 빌드에 따라 다릅니다. 먼저 curl -V의 기능을 확인하고 지원되는 환경에서 다음과 같이 테스트합니다.
curl --http3 -I https://example.com/
curl --http3-only -I https://example.com/--http3는 HTTP/3 연결이 늦거나 실패하면 이전 버전도 시도할 수 있습니다. HTTP/3 자체 성공 여부를 분리할 때만 --http3-only 결과와 함께 봅니다.
3단계: 프로토콜보다 먼저 캐시 상태 분리
첫 번째 요청이 CDN MISS이고 두 번째 요청이 HIT라면 시간 차이를 프로토콜 효과로 볼 수 없습니다. HTML과 정적 파일의 Cache-Control, Age, CDN 상태 헤더를 기록하고 같은 상태끼리 비교하세요.
- 첫 방문과 재방문 결과를 분리합니다.
- CDN HIT와 MISS를 섞지 않습니다.
- 같은 지역·기기·네트워크에서 최소 세 번 측정합니다.
- 연결 시간, TTFB, 전송량과 전체 완료 시간을 함께 기록합니다.
- 외부 도메인은 별도 행으로 분리합니다.
CDN 설정과 원본을 분리하려면 Cloudflare SSL·캐시·원복 점검을 참고하세요. 원본 응답이 느리다면 워드프레스 TTFB 원인 진단으로 서버 시간을 먼저 줄입니다.
4단계: HTTP/3 fallback과 방화벽 확인
HTTP/3는 QUIC·UDP 경로를 사용합니다. 일부 회사망, 공유기, 보안 장비나 호스팅 정책이 UDP를 제한하면 브라우저가 HTTP/2로 전환할 수 있습니다. 이때 사이트가 실패해서는 안 되므로 HTTP/2 경로를 유지합니다.
| 증상 | 가능한 원인 | 확인 방법 |
|---|---|---|
| 항상 h2만 표시 | h3 미광고·UDP 차단·브라우저 재사용 | Alt-Svc, 다른 네트워크, 새 프로필 비교 |
| 첫 방문 h2, 다음 방문 h3 | HTTP/3 대체 서비스 광고 학습 | 첫 연결과 재연결을 따로 기록 |
| h3가 간헐적으로 실패 | UDP 경로·MTU·보안 장비 문제 | 모바일망과 유선망 비교, 서버 QUIC 로그 확인 |
| h3인데 체감 개선 없음 | 원본 TTFB·큰 JS·이미지·캐시 MISS | Waterfall에서 가장 긴 구간 확인 |
| 일부 리소스만 h2 | 외부 도메인 또는 별도 CDN | Domain과 Protocol 열 함께 확인 |
30분 적용과 원복 순서
- 0~5분: HTML·CSS·JS의 Protocol과 캐시 상태를 기록합니다.
- 5~10분: Alt-Svc와 CDN의 HTTP/3 지원 위치를 확인합니다.
- 10~18분: 테스트 도메인 또는 제한된 경로에서 HTTP/3를 활성화합니다.
- 18~23분: 첫 방문·재방문과 서로 다른 네트워크를 비교합니다.
- 23~27분: 로그인·업로드·다운로드·API 기능을 확인합니다.
- 27~30분: 오류가 있으면 HTTP/3 광고를 끄고 HTTP/2 경로로 원복합니다.
텍스트 전송량은 프로토콜과 별도로 압축 상태를 확인해야 합니다. Gzip·Brotli 응답 헤더 점검처럼 실제 Content-Encoding을 확인하세요. JavaScript 실행 비용은 JS 번들 Coverage 진단으로 분리합니다.
TIP
“HTTP/3 활성화”가 아니라 “모바일망 재방문에서 h3, CDN HIT, TTFB 180ms”처럼 조건과 결과를 함께 기록하세요. 같은 요청·캐시 상태·네트워크가 아니면 프로토콜 간 속도 비교 근거가 약합니다.
자주 묻는 질문
HTTP/3를 켜면 HTTP/2는 꺼야 하나요?
아닙니다. UDP 경로를 사용할 수 없는 방문자를 위해 TCP 기반 fallback을 유지해야 합니다. 활성화 후에도 서로 다른 네트워크에서 HTTP/2 전환과 기능 동작을 확인하세요.
Chrome에서 h3가 한 번도 보이지 않는 이유는 무엇인가요?
서버가 h3를 광고하지 않거나 UDP가 차단됐을 수 있고, 외부 리소스가 다른 도메인에 있을 수도 있습니다. Alt-Svc, Domain, Protocol과 다른 네트워크 결과를 함께 확인하세요.
공식 자료
마무리
HTTP 버전은 설정 화면이 아니라 실제 요청에서 확인합니다. Protocol과 캐시 상태를 기록하고 Alt-Svc·UDP 경로·fallback을 분리한 뒤 같은 조건으로 전후를 비교하세요. HTTP/3가 안정적으로 사용되고 오류 없이 시간이 줄었을 때 적용을 유지합니다.
댓글 0
첫 댓글을 남겨보세요.