지원 알림이 작동을 보장하지는 않습니다
서버는 Alt-Svc 응답 헤더로 HTTP/3 지원을 알리며, 클라이언트는 HTTP/1.1 또는 HTTP/2로 이 헤더를 받습니다. 헤더는 약속일 뿐입니다. HTTP/3는 UDP의 QUIC 위에서 실행되므로 UDP가 완전히 차단되어도 페이지가 정상적으로 로드될 수 있고, 브라우저가 아무런 알림 없이 계속 사용하는 프로토콜은 HTTP/2.
curl -sI https://server.example/ | grep -i alt-svc실제 전송 확인
QUIC으로 요청이 완료되어야 확인할 수 있는 것이 HTTP/3. HTTP/3 지원을 포함해 빌드한 curl을 사용하세요. 많은 시스템 패키지에는 이 지원이 없으며, 이 경우 옵션이 거부되는데 이는 서버 상태에 대해 아무것도 알려 주지 않습니다. 브라우저에서 개발자 도구를 열고 프로토콜 열을 확인하세요. 해당 요청은 h3로 표시됩니다. 첫 방문에는 브라우저가 HTTP/2를 사용할 수 있으므로 페이지를 다시 로드하세요.
curl -V | grep -i http3
curl -sS --http3-only -o /dev/null -w '%{http_version}\n' https://server.example/NGINX 설정 확인
NGINX에는 TCP 리스너와 함께 QUIC 리스너가 필요하며, 사용하는 버전과 빌드가 이를 지원해야 합니다. QUIC이 직접 사용하기 때문에 TLS 1.3이 필수입니다. 다시 로드하기 전에 설정을 확인하세요. Alt-Svc의 ma 값은 클라이언트가 이 약속을 기억하는 시간으로, 단위는 초입니다. 테스트 중에는 짧게 설정하세요.
listen 443 ssl;
listen 443 quic reuseport;
http2 on;
add_header Alt-Svc 'h3=":443"; ma=300' always;
nginx -V 2>&1 | grep -o with-http_v3_module
sudo nginx -t전체 경로에서 UDP 443 허용
가장 흔한 실패 원인은 TCP 443은 허용하지만 UDP 443은 허용하지 않는 방화벽입니다. 서버와 모든 외부 필터를 확인하세요. 소켓의 수신 대기 여부는 서버에서 확인할 수 있습니다. 일부 기업 및 공용 네트워크는 의도적으로 QUIC을 차단하므로, 한 네트워크에서 테스트에 실패했다고 서버에 문제가 있다고 단정할 수는 없습니다. 다른 네트워크에서 다시 테스트하세요.
sudo ss -lunp | grep ':443'
sudo ufw allow 443/udp
sudo tcpdump -ni any udp port 443새 프로토콜이 더 빠를까요?
HTTP/3는 패킷 손실이 있거나 네트워크가 바뀌는 연결에서 가장 도움이 됩니다. 패킷 하나가 손실되어도 다른 스트림이 지연되지 않기 때문입니다. 상태가 좋은 유선 연결에서는 차이가 작을 수 있고 서버의 CPU 사용량은 더 높을 수 있습니다. 성능 향상을 가정하지 말고 자신의 환경에서 측정하세요. UDP를 사용할 수 없는 클라이언트를 위해 HTTP/2도 계속 제공하세요.
CH-J Server Manager의 HTTP/3 테스트
Server Diagnostics에는 HTTP 클라이언트가 함께 제공되므로 테스트가 시스템 curl에 의존하지 않습니다. QUIC 전송이 완료된 후에만 HTTP/3가 확인되었다고 보고하며 Alt-Svc는 지원 알림으로만 취급합니다. UDP 시간 초과 시에는 원인이 사용자와 서버 사이의 네트워크에 있을 수 있으므로 서버 지원 여부가 아직 검증되지 않았다고 표시하며, 다른 프로토콜로의 폴백을 성공으로 간주하지 않습니다.